Published November 2, 2026

Android Studio Draws a Three-Year Line on AGP Versions: What It Means for Flutter Builds

Buried in the Android Studio release notes is a policy change that will affect more Flutter projects than any single feature in Rabbit 2. Android Studio now applies a time based compatibility rule to the Android Gradle Plugin. Each Studio version supports AGP releases published within the previous three years, and anything older is no longer supported in newer Studio versions.

The wording is direct: if a project's AGP version falls outside that window, Android Studio will require an update before it will work with the project. There is no compatibility mode to fall back on. The escape hatch is to keep using an older Android Studio build for that project.

The Window Moves One Step Per Release

The published table traces the drift clearly. Android Studio Rabbit 2 at 2026.2.2 supports AGP 7.1 through 9.5. Rabbit 1 at 2026.2.1 supported 7.1 through 9.4. Quail 4 and Quail 3 stopped at 9.4 and 9.3 respectively, Quail 2 at 9.3, Quail 1 at 9.2, and Panda 4 at 9.2.

The lower bound is the part that matters. It has been 7.1 for the last several releases because three years ago AGP had not yet moved past that floor. As older AGP releases age out, the floor will climb, and each time it does, a set of projects that had no reason to upgrade will be forced to.

  • Rabbit 2 (2026.2.2): AGP 7.1 through 9.5
  • Rabbit 1 (2026.2.1): AGP 7.1 through 9.4
  • Quail 4 (2026.1.4): AGP 7.1 through 9.4
  • Panda 3 (2025.3.3): AGP 7.0 through 9.1

A second clock runs alongside it for cloud features. Gemini in Android Studio, Play Vitals, and Firebase Crashlytics are available only on the latest stable channel and on major versions released in the previous ten months. Support for Panda 1 is already deprecated and will be disabled entirely at the next major release. So even a team that pins an older Studio deliberately loses services long before the IDE stops opening projects.

Where Flutter Projects Sit on This Scale

Flutter generates the Android host project, and the AGP version lives in the Gradle files under `android/`, declared in the plugin block alongside the Kotlin plugin. Flutter templates set a specific version, and `flutter upgrade` can move it. Many teams never touch it after the first `flutter create`, which is exactly the pattern this policy targets.

Flutter projects also age differently from native Android projects. A Flutter app can sit on an older SDK for a year while shipping Dart changes, because Dart upgrades are frequent and Android host project upgrades are rare. The Android folder becomes a time capsule: an AGP version, a Gradle wrapper version, a Java compatibility level, and a Kotlin plugin version, all frozen at the moment the project was generated.

When that time capsule ages past the three year line, the sequence looks like this: Android Studio opens the project, reports the AGP version as unsupported, and blocks the sync. The fix is to raise AGP, which usually demands a newer Gradle wrapper, which in turn demands a newer JDK for the build. Compile SDK and target SDK requirements then follow, since API level support is tied to AGP versions as well. Google publishes minimums for that: API level 37 requires at least AGP 9.1.1, API 36.1 requires 8.13.0, and API 36 requires 8.9.1.

  • Check the AGP version in `android/settings.gradle.kts` before upgrading the IDE
  • Bump the Gradle wrapper in `android/gradle/wrapper/gradle-wrapper.properties` in the same commit
  • Confirm the JDK used by Gradle matches what the new AGP requires, locally and in CI
  • Rebuild and run instrumented tests on a physical device, since AGP upgrades change packaging behaviour

The Honest Tradeoff

The upside of the policy is predictable: Google stops carrying compatibility code for toolchains nobody should be using, and the supported matrix becomes a rolling window instead of a growing list. The downside is that the upgrade becomes non-optional at a moment the team does not choose.

The practical response is to move AGP forward on a schedule rather than in a panic. A Flutter team that bumps AGP once a year, alongside a Flutter upgrade, stays well inside the window and never meets the hard stop. A team that treats the Android folder as untouchable will meet it eventually, in the middle of a release, with a Gradle and JDK migration attached.

Three years is a generous window for a build tool. It is also shorter than the lifespan of many production Flutter apps, which is the part worth internalising. The AGP version in a project is now a dated dependency like any other, and it deserves a line in the upgrade checklist next to the Flutter SDK version.