Opinions on AGP 8 and compileSDK 35: What Are the Risks for the Flutter Ecosystem?

Help General
1

Hi everyone,

I have questions regarding the relationship between compileSDK 35 and AGP 8.

Here are my main concerns:

  • Is it true that using compileSDK 35 effectively requires an upgrade to AGP 8 to fully support all the new features and requirements?

  • If my project relies on third-party plugins (e.g., flutter_app_badger) that haven’t updated their build files to accommodate AGP 8 (like adding the required namespace), does that block me from upgrading? What workarounds have you tried or considered (e.g., forking/patching dependencies)?

  • In your opinion, what risks does this situation pose for the Flutter ecosystem? Could these AGP changes and potential dependency issues slow down adoption of newer SDKs or introduce issues for dependency updates?

Any insights or advice on how to navigate these changes would be greatly appreciated!

Thanks in advance for your help.

1 Like
2

In my case I typically just go with my own fork and suggest PR with the change – typically it’s just a namespace change, removal of V1 embedding references etc. What I’ve noticed is that there were few plugins that preemptively updated to compileSdkVersion 35 but it’s not really required right now (Target API level requirements for Google Play apps - Play Console Help). Hence plugins right now should target SDK 34.

Btw, is there any issue with using Flutter with AGP 8? I’m using gradle 8 and AGP 8.1.4 just fine.

Edit, you can have a look at minimum SDK requirements here

screenshot_20250326_114645
screenshot_20250326_114645890×354 20.8 KB

3

This is great to hear Dominik. Thanks for the answer. I am blocked to test it because some dependencies do not have namespace. Probably forking is the way to go.

4

for me, awesome_notifications broke, didn’t have time to deal with forking it and fixing it, I used flutter_local_notifications instead.