Versions and updates

Flutter, Gradle, the Android Gradle Plugin (AGP), Kotlin and the JDK have to fit together. If they don’t, the build fails with a message that rarely gives away the reason. The Build Station checks this combination, suggests changes as a diff and, if you like, keeps Flutter up to date itself.

Analysis before the build

When you select a project, flutter analyze runs in the background. The result appears in the Build tab above the preset selection and answers a single question: Is anything currently preventing the build?

• Red: There are findings of type error. The build will very likely fail. When you click Build starten (start build), the Station asks first and shows the first errors in plain language.
• Yellow or grey: only warnings and lints. No build fails on those, so they’re deliberately not a blocker.

Expanded, the line shows each finding with file and line, errors first. The arrow icon checks again.

For very large projects you can switch the analysis off under Einstellungen › flutter analyze beim Projektwechsel (Settings › flutter analyze on project switch). It then says Analyse noch nicht gelaufen (analysis hasn’t run yet) with the Jetzt prüfen (check now) button.

Updating dependencies

The pub upgrade button at the top of the Build tab runs fvm flutter pub upgrade in the project and shows the output live. Afterwards the analysis restarts automatically, because new package versions can change the picture.

pubspec.lock is rewritten in the process, but not committed. No entry appears in the history either, because no artifact is built.

If pub upgrade should be a fixed part of a preset, it’s also available as a pre-step. The build is then no longer reproducible against the same package versions, though, see Presets.

The “Versionen” dialog

Versionen (Versions) in the Build tab opens the Versionen und Kompatibilität (versions and compatibility) dialog. It shows what the project specifies and what’s actually used to build:

Flutter (.fvmrc)            3.38.10
Flutter (fvm_config.json)   3.27.1      veraltetes Format von fvm 2
Gradle                      8.11.1      android/gradle/wrapper/gradle-wrapper.properties:5
Android-Gradle-Plugin       8.9.1       android/settings.gradle:21
Kotlin                      2.1.20      android/settings.gradle:22
JDK für Gradle              25+36       flutter doctor · /Library/Java/…/temurin-25.jdk/…
Installierte JDKs           25, 21, 17

The Station determines which JDK Gradle uses via flutter doctor -v. Flutter itself decides between flutter config --jdk-dir, Android Studio’s JDK, JAVA_HOME and the PATH. An org.gradle.java.home in gradle.properties beats everything.

What is checked

Finding	Suggestion
JDK too new for Gradle	flutter config --jdk-dir=… pointing to an installed JDK 17 or 21, otherwise brew install openjdk@17. For JDKs up to 24, alternatively Gradle 8.14.3
JDK too old for AGP (AGP 8 needs 17)	as above
Gradle too old for AGP	wrapper to the AGP’s minimum version
fvm_config.json differs from .fvmrc	align the old file with .fvmrc
project on AGP 8 and Gradle 8	upgrade to Gradle 9.1+, AGP 9.0.1, Kotlin 2.2.10 and the transition flags in gradle.properties, in one step

An example of why this helps: Gradle 8.11.1 on JDK 25 only reports Unsupported class file major version 69. What it means is that JDK 25 is too new, because Gradle 8.11 only runs up to JDK 23.

File changes appear as a diff and are only written after you confirm, exactly the lines shown. If a file has changed since the check, it’s left untouched. Commands run through the queue after you confirm; afterwards you click Neu prüfen (check again).

The jump to Gradle 9 only works together with AGP 9, and AGP 9 only builds Flutter from version 3.44. If your project is below that, the dialog gives that as the reason and offers no button. Then Flutter has to be raised first.

Whatever can be detected without flutter doctor, such as Gradle versus AGP or fvm, also appears as a line in the Build tab without the dialog, with Prüfen … (check) as the way in.

Flutter updates

In the same dialog, the Flutter-Updates section compares the version from .fvmrc with the official release list and offers:

Offer	Example at 3.38.5	What comes along
Hotfix of your own release line	3.38.10	only .fvmrc
the two newest release lines, each with its newest hotfix	3.47.7, 3.44.9	plus AGP, Gradle and Kotlin, as far as the target version requires them

A hotfix only brings bug fixes. A jump across release lines can bring breaking changes, which is why there’s a link to the Release Notes next to it.

Under Muss mit angehoben werden (must be raised too) are the values without which Flutter aborts the build. They end up in the diff. Values below the recommendation, where Flutter only warns, are shown as a note alongside.

Auf … aktualisieren (update to …) or Auf … umstellen (switch to …) writes the changes, including an old fvm_config.json and the Flutter version in the project settings if the same one was set there. The Station then queues fvm install and pub get. Nothing is committed. If needed, do that with Commit & Push in the Build tab.

Applying hotfixes automatically

The Hotfixes automatisch übernehmen (apply hotfixes automatically) switch applies per project. When it’s on, the Station raises .fvmrc to the newest hotfix without asking when you open the project in the Build tab, and queues fvm install.

• Never during a build of this project.
• Never if that would require changing more than the fvm files.
• New release lines remain a conscious decision.

If there’s a newer version that doesn’t come automatically, it shows up as a line in the Build tab, with Versionen … as the way into the dialog.

If the Flutter version in the project settings differs from .fvmrc, the Build tab shows a warning. The build uses the version from the project settings. The Station deliberately doesn’t run fvm use automatically.

Checking packages

Pakete prüfen (flutter pub outdated) (check packages) in the Versionen dialog shows:

• discontinued packages with their successor
• plugins with their own Kotlin Gradle Plugin, including indirectly included ones
• new major versions of direct dependencies, with Anheben … (raise)

The suggestions are the same as after a failed build, just earlier. See When a build fails.

Raising the Android API level

Google Play only accepts updates with a current targetSdk; for 2026 that’s 36 (Android 16). If a project is below that, the Build tab shows a line with Umstellen … (switch).

The assistant first shows what’s in the project:

android/app/build.gradle.kts
compileSdk       35
targetSdk        35
minSdk           23        bleibt unverändert
Gradle-Plugin    8.7.3
Gradle           8.10.2

Then the changes as a diff, each one can be deselected:

− compileSdk = 35
+ compileSdk = 36

• Both Gradle notations are understood, compileSdk = 36 and compileSdkVersion 36. Indentation and style are preserved.
• If there’s flutter.compileSdkVersion instead of a number, the assistant suggests entering the value explicitly. Then the level no longer depends on which Flutter version happens to be building.
• Expressions it doesn’t understand, such as from a version catalog, it leaves alone and says so.
• minSdk is never touched.
• A Gradle plugin that’s too old is a warning, not a blocker.

After the change, clean up once before the next build, otherwise Gradle remembers the old level.

Changing the number is the small part. Under Danach prüfen (check afterwards) you’ll find what changes for the app with Android 16: enforced edge-to-edge, ignored orientation locks on large screens, stricter background limits. Only a test run on a device will find that. The Station doesn’t claim to check it.