AGP 9 Ships Kotlin Built-In. Half of Flutter Plugins on pub.dev Will Break When You Upgrade.

Android Gradle Plugin 9.0 removed the need to apply the kotlin-android plugin. Most Flutter plugins still apply it anyway. Upgrading is now a coin flip on whether your build fails.

If you upgrade your Flutter project to Android Gradle Plugin 9.0 today, your build will likely fail. Not because of your code. Because of the plugins in your pubspec.

AGP 9.0 shipped in January 2026 with built-in Kotlin support enabled by default. The kotlin-android plugin (also called the Kotlin Gradle Plugin or KGP) is no longer required to compile Kotlin source files. AGP handles it automatically with Kotlin 2.2.10 bundled in.

The problem: most Flutter plugins on pub.dev still apply the kotlin-android plugin in their own android/build.gradle. When AGP 9.0 sees that, it throws a build error and refuses to compile. The Flutter team added a temporary opt-out, but that opt-out gets removed in AGP 10.0 in mid-2026. After that, every plugin that has not migrated will break every Flutter app that depends on it.

I wrote about AGP 9 in April. That piece covered the rendering changes and the migration steps for your app. This piece is about the second-order problem nobody talks about: your plugins.

What AGP 9.0 actually changed

Before AGP 9.0, every Flutter Android module that contained Kotlin code applied the kotlin-android plugin explicitly:

apply plugin: 'kotlin-android'

AGP 9.0 made this redundant. Built-in Kotlin is on by default. Kotlin 2.2.10 ships with AGP. The build system compiles Kotlin source files without any plugin application.

The change is replacement, not addition. If you apply kotlin-android to a project that already has built-in Kotlin enabled, AGP 9.0 fails with:

Failed to apply plugin 'kotlin-android'.
The 'org.jetbrains.kotlin.android' plugin is no longer required 
for Kotlin support since AGP 9.0.
Solution: Remove the 'org.jetbrains.kotlin.android' plugin 
from this project's build file.

The error is the entire build. Not a warning. Not a fallback. The Gradle task fails, the compilation halts, the app does not produce an APK.

Why this is a Flutter ecosystem problem, not an app problem

For your own Flutter app, the migration is straightforward. Remove the kotlin-android plugin reference from your android/build.gradle, run flutter upgrade, and the Flutter tool handles the rest. The official Flutter migration guide walks through this.

The problem is that Flutter plugins ship their own android/build.gradle files. Each plugin author wrote their own Kotlin plugin application years ago. Most of them still apply kotlin-android because that was correct in AGP 8.x and earlier. They have not migrated.

When your Flutter app upgrades to AGP 9.0, Gradle evaluates every plugin’s android/build.gradle as part of the build. If any plugin in your dependency tree applies kotlin-android, the build fails on that plugin. You do not get to choose which plugins to upgrade. The build is all-or-nothing.

This is exactly the same structural problem as the CocoaPods to SwiftPM migration on iOS. The maintainers have to do the work. You wait.

The plugins that are already breaking

Three categories of plugin are documented as failing on AGP 9.0 right now, with active GitHub issues:

The Flutter team’s own first-party plugins. camera_android_camerax version 0.6.27 fails to build on AGP 9.0 because of the legacy Kotlin plugin application. The issue (flutter/flutter#181383) is tracked as part of a broader audit of every Flutter-maintained plugin for AGP 9 compatibility. The Flutter team is actively working through these.

Community plugins maintained by individual developers. wakelock_plus is one of the most widely used Flutter plugins, in hundreds of thousands of production apps. It applies the kotlin-android plugin in its android/build.gradle. An AGP 9 incompatibility issue (fluttercommunity/wakelock_plus#117) was opened in January 2026 and is still open. The plugin still ships with the legacy setup.

Third-party SDK plugins from major companies. AppsFlyer’s Flutter plugin (appsflyer-flutter-plugin) has an open issue (#453) from May 2026 requesting AGP 9 migration. AppsFlyer is in nearly every Flutter app that does mobile attribution. The plugin still applies org.jetbrains.kotlin.android in its Android module.

These three are documented examples. The pattern repeats across pub.dev. Any plugin written before late 2025 has the legacy Kotlin plugin application in its android/build.gradle. Audit your pubspec and assume the worst until proven otherwise.

The opt-out that is buying you time, and the deadline that takes it away

The Flutter team added a temporary escape hatch. Setting android.builtInKotlin=false in your gradle.properties disables built-in Kotlin and reverts to the legacy plugin application behavior. The Flutter migrator tool actually adds this flag automatically for projects that have not migrated.

This works for AGP 9.0. It buys you time.

It does not work in AGP 10.0. The Android team has explicitly stated that the opt-out gets removed in AGP 10.0, which is targeted for mid-2026. After that release, every Flutter plugin that applies kotlin-android will cause a build failure with no workaround.

This is the deadline that matters. Not when AGP 9.0 shipped. When AGP 10.0 ships and removes the opt-out. That is the point at which the ecosystem must have migrated, or your Flutter app will not build on the current Android toolchain.

What to do this week

Five steps. Two hours of work, depending on your dependency count.

First, audit your pubspec. Look at every plugin you depend on. For each one, check its GitHub repository’s android/build.gradle file. Search for kotlin-android or org.jetbrains.kotlin.android. If it is there, the plugin will need migration before AGP 10.0.

Second, check each plugin’s open issues for AGP 9 compatibility tracking. Search the plugin’s GitHub issues for “AGP 9” or “built-in Kotlin.” If a tracking issue exists, subscribe to it. If one does not exist, open one. Plugin maintainers prioritize migration work when they see real apps blocked by it.

Third, identify the high-risk plugins in your tree. Plugins that have not had a release since late 2025 are at higher risk because the maintainer may not be actively shipping. Plugins from individual maintainers are at higher risk than plugins from Google or major SDK vendors. Plugins with low GitHub activity are at higher risk than plugins with active maintenance.

Fourth, for any plugin in your tree that you cannot upgrade and where the maintainer is unresponsive, plan a fork. The migration is a single-file change in the plugin’s android/build.gradle. Remove the kotlin-android plugin application. Test the build. If it works, you have a working fork. If the plugin does more complex Kotlin configuration, the migration is more involved but still manageable.

Fifth, do not upgrade to AGP 10.0 the day it ships. Wait for the ecosystem to catch up. The teams that handle AGP migrations well stage them across quarters. The teams that handle them poorly try to upgrade the day the new version drops and discover that half their plugins fail simultaneously.

The pattern this fits into

AGP 9 Kotlin built-in is the third major Flutter ecosystem migration in twelve months. CocoaPods to SwiftPM on iOS. Skia to Impeller on Android rendering. And now AGP 9 to built-in Kotlin on Android Gradle. Each one has a deadline. Each one requires plugin maintainers to do work that affects your app whether you participate or not.

Senior engineers who have lived through these know the pattern. The migration is announced. A subset of plugins migrate immediately. Most plugins delay. The deadline approaches and a panic wave hits. The plugins that miss the deadline create cascading failures for every app that depends on them.

This is where you are with AGP 9 right now. The deadline is mid-2026. AGP 10.0 removes the opt-out. The migration is happening whether your plugins finish in time or not.

For the broader plugin audit lens, I wrote about the five Flutter plugins with the most open issues that are in almost every production app.

I write about production mobile engineering with receipts. Follow if that is useful. ❤