AGP 9 / built-in Kotlin migration spike#344
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request. |
mahmoud-elmorabea
changed the title
mahmoud-elmorabea
changed the title
|
Hey, there @mahmoud-elmorabea 👋🤖. I'm a bot here to help you. I think the title of this pull request is not in the correct format. Follow the instructions below and then edit the pull request title to a valid format. I'll check again after you make an edit 👍. This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: If your pull request introduces breaking changes to the code, use this format: where
Examples:Need more examples? Want to learn more about this format? Check out the official docs. Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests. |
Drops the buildscript block and applies `kotlin-android` conditionally based on the host's AGP major version, per Flutter's plugin-author migration guide. This unblocks consumers on AGP 9+ where applying KGP manually is no longer supported. Adds a minimal sample app (flutter_sample_agp9_test) pinned to AGP 9.0.1 and Gradle 9.0 with `android.builtInKotlin=true`, plus a lightweight CI workflow that builds it. The existing flutter_sample_spm and flutter_sample_cocoapods continue to exercise the AGP 8 path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AGP 9.0.1 requires a minimum Gradle 9.1.0 per its version-check plugin; the previous 9.0 pin failed CI with: > Minimum supported Gradle version is 9.1.0. Current version is 9.0.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AGP 9+ built-in Kotlin removes the `android.kotlinOptions` extension and
the `kotlinOptions` block on KotlinCompile tasks. CI failed with:
> Could not find method kotlinOptions() for arguments [...]
Switch the plugin and the AGP 9 test app to the top-level `kotlin {
compilerOptions { ... } }` block from KGP 2.x, which works under both
AGP < 9 (kotlin-android applied conditionally) and AGP 9+ built-in
Kotlin. Both existing AGP 8 sample apps consume KGP 2.1.21 already, so
no other sample app changes are needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mahmoud-elmorabea
force-pushed
the
chore/agp9-builtin-kotlin-migration
branch
from
9edeb5e to
fa11700
Compare
…l AGP 8 smoke Both flutter_sample_spm and flutter_sample_cocoapods now build under AGP 9.0.1 + Gradle 9.1.0 with android.builtInKotlin=true, exercising the AGP 9 / built-in Kotlin path with realistic plugin loads (Firebase, local_notifications, etc). flutter_sample_agp9_test is replaced by flutter_sample_agp8_min — a stripped-down copy of spm that keeps AGP 8.9.3 + KGP 2.1.21. It is the smoke target ensuring the plugin's dynamic AGP-version check still applies kotlin-android correctly on AGP < 9. build-agp9-test.yml is replaced by build-agp8-min-test.yml accordingly; the existing build-sample-apps.yml workflow now covers the AGP 9 path. Risk: upstream plugins consumed by the two real sample apps (flutter_local_notifications, firebase_messaging, etc.) may not yet support AGP 9 built-in Kotlin. If CI surfaces failures inside their plugin code rather than ours, flip android.builtInKotlin=false to keep AGP 9 with legacy KGP application as the fallback. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Related to #343 |
matt-frizzell
left a comment
matt-frizzell
left a comment
There was a problem hiding this comment.
Asks that don't block the PR.
- Make sure to connect this to a Linear issu
- We should discuss our commit message prefix options because they actually connect to DX Allocation metrics that help us understand where we're applying our efforts. This seems like a feature or maintenance type of enhancement so just having the commit message match that would be good.
Otherwise, it's a test PR so go ahead see if this new approach is valid!
2 participants
Fixes: MBL-1733: Migrate Plugin to Built-in Kotlin
Summary
buildscriptblock inandroid/build.gradleand applieskotlin-androidconditionally based on the host's AGP major version. Pattern taken verbatim from Flutter's plugin-author migration guide.apps/flutter_sample_agp9_test/pinned to AGP 9.0.1 + Gradle 9.0 withandroid.builtInKotlin=true.build-agp9-test.ymlthat builds the new app on PR/push.flutter_sample_spmandflutter_sample_cocoapods(AGP 8.9.3 + KGP 2.1.21) continue to cover the AGP 8 path.Why a spike?
This is an experimental PR for CI validation only — we want to see whether the dynamic AGP-version check actually compiles cleanly under both AGP 8 (existing sample apps) and AGP 9 (new sample app) without forcing consumers to bump their Flutter floor.
The plugin's
pubspec.yamlFlutter floor stays at>=2.5.0on purpose — Option B's whole point is backward compat. If CI is green across all three sample-app jobs, we have a viable path to publishing this without a breaking version bump.What CI exercises
build-primary-app(existing)flutter_sample_spmkotlin-androidbuild-secondary-app(existing)flutter_sample_cocoapodskotlin-androidbuild-agp9-testflutter_sample_agp9_testTest plan
Testworkflow (Flutter unit tests) still passes.Lint/PR lintworkflows still pass.check-api-changesworkflow still passes (no Dart API change expected).Notes / open items
🤖 Generated with Claude Code