Abhängigkeiten mit pub upgrade aktualisieren, Analyse vor dem Build, Flutter-Hotfixes, Android-API-Level anheben und JDK, Gradle und AGP aufeinander abstimmen.

Flutter, Gradle, das Android-Gradle-Plugin (AGP), Kotlin und das JDK müssen zueinander passen. Tun sie es nicht, scheitert der Build mit einer Meldung, die selten den Grund verrät. Die Build Station prüft diese Kombination, schlägt Änderungen als Diff vor und hält Flutter auf Wunsch selbst aktuell.

Analyse vor dem Build

Wählst du ein Projekt aus, läuft im Hintergrund flutter analyze. Das Ergebnis steht im Tab Build über der Preset-Auswahl und beantwortet eine einzige Frage: Verhindert gerade etwas den Build?

Rot: Es gibt Befunde vom Typ error. Der Build scheitert sehr wahrscheinlich. Beim Klick auf Build starten fragt die Station nach und zeigt die ersten Fehler im Klartext.
Gelb oder grau: nur Warnungen und Lints. Daran scheitert kein Build, deshalb sind sie bewusst kein Blocker.

Aufgeklappt zeigt die Zeile jeden Befund mit Datei und Zeile, Fehler zuerst. Das Pfeilsymbol prüft erneut.

Bei sehr großen Projekten kannst du die Analyse unter Einstellungen › flutter analyze beim Projektwechsel abschalten. Dann steht dort Analyse noch nicht gelaufen mit dem Knopf Jetzt prüfen.

Abhängigkeiten aktualisieren

Der Knopf pub upgrade oben im Tab Build führt fvm flutter pub upgrade im Projekt aus und zeigt die Ausgabe live. Danach startet die Analyse automatisch neu, weil neue Paketversionen das Bild ändern können.

pubspec.lock wird dabei neu geschrieben, aber nicht committet. Es entsteht auch kein Eintrag im Verlauf, weil kein Artefakt gebaut wird.

Soll pub upgrade fest zu einem Preset gehören, gibt es ihn auch als Pre-Step. Dann ist der Build allerdings nicht mehr gegen dieselben Paketversionen reproduzierbar, siehe Presets.

Der Dialog „Versionen”

Versionen im Tab Build öffnet den Dialog Versionen und Kompatibilität. Er zeigt, was das Projekt festlegt und womit tatsächlich gebaut wird:

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

Welches JDK Gradle nutzt, ermittelt die Station über flutter doctor -v. Flutter entscheidet selbst zwischen flutter config --jdk-dir, dem JDK von Android Studio, JAVA_HOME und dem PATH. Ein org.gradle.java.home in gradle.properties schlägt alles.

Was geprüft wird

Befund	Vorschlag
JDK zu neu für Gradle	`flutter config --jdk-dir=…` auf ein installiertes JDK 17 oder 21, sonst `brew install openjdk@17`. Bei JDK bis 24 alternativ Gradle 8.14.3
JDK zu alt für AGP (AGP 8 braucht 17)	wie oben
Gradle zu alt für AGP	Wrapper auf die Mindestversion des AGP
`fvm_config.json` weicht von `.fvmrc` ab	alte Datei an `.fvmrc` angleichen
Projekt auf AGP 8 und Gradle 8	Upgrade auf Gradle 9.1+, AGP 9.0.1, Kotlin 2.2.10 und die Übergangsschalter in `gradle.properties`, in einem Schritt

Ein Beispiel dafür, warum das hilft: Gradle 8.11.1 auf JDK 25 meldet nur Unsupported class file major version 69. Gemeint ist, dass JDK 25 zu neu ist, weil Gradle 8.11 nur bis JDK 23 läuft.

Dateiänderungen erscheinen als Diff und werden erst nach Rückfrage geschrieben, genau die gezeigten Zeilen. Hat sich eine Datei seit der Prüfung geändert, bleibt sie unangetastet. Befehle laufen nach Rückfrage über die Warteschlange, danach klickst du Neu prüfen.

Der Sprung auf Gradle 9 geht nur zusammen mit AGP 9, und AGP 9 baut Flutter erst ab Version 3.44. Liegt dein Projekt darunter, nennt der Dialog das als Grund und bietet keinen Knopf an. Dann muss zuerst Flutter angehoben werden.

Was ohne flutter doctor erkennbar ist, etwa Gradle gegen AGP oder fvm, steht auch ohne Dialog als Zeile im Tab Build, mit Prüfen … als Weg hinein.

Flutter-Updates

Im selben Dialog vergleicht der Abschnitt Flutter-Updates die Version aus .fvmrc mit der offiziellen Release-Liste und bietet an:

Angebot	Beispiel bei 3.38.5	Was mitwandert
Hotfix der eigenen Release-Linie	3.38.10	nur `.fvmrc`
die zwei neuesten Release-Linien, jeweils mit neuestem Hotfix	3.47.7, 3.44.9	dazu AGP, Gradle und Kotlin, soweit die Ziel-Version sie verlangt

Ein Hotfix bringt nur Fehlerbehebungen. Ein Sprung über Release-Linien kann Breaking Changes bringen, deshalb steht ein Link auf die Release Notes daneben.

Unter Muss mit angehoben werden stehen die Werte, ohne die Flutter den Build abbricht. Sie landen im Diff. Werte unter der Empfehlung, bei denen Flutter nur warnt, stehen als Hinweis daneben.

Auf … aktualisieren bzw. Auf … umstellen schreibt die Änderungen, auch eine alte fvm_config.json und die Flutter-Version in den Projekt-Einstellungen, falls dort dieselbe stand. Danach reiht die Station fvm install und pub get ein. Committet wird nichts. Das erledigst du bei Bedarf mit Commit & Push im Tab Build.

Hotfixes automatisch übernehmen

Der Schalter Hotfixes automatisch übernehmen gilt je Projekt. Ist er an, hebt die Station beim Öffnen des Projekts im Tab Build die .fvmrc ohne Rückfrage auf den neuesten Hotfix und reiht fvm install ein.

Nie während eines Builds dieses Projekts.
Nie, wenn dafür mehr als die fvm-Dateien geändert werden müssten.
Neue Release-Linien bleiben eine bewusste Entscheidung.

Gibt es eine neuere Version, die nicht automatisch kommt, steht das als Zeile im Tab Build, mit Versionen … als Weg in den Dialog.

Weicht die Flutter-Version in den Projekt-Einstellungen von der .fvmrc ab, zeigt der Tab Build eine Warnung. Gebaut wird mit der Version aus den Projekt-Einstellungen. fvm use führt die Station bewusst nicht automatisch aus.

Pakete prüfen

Pakete prüfen (flutter pub outdated) im Dialog Versionen zeigt:

eingestellte Pakete mit ihrem Nachfolger
Plugins mit eigenem Kotlin Gradle Plugin, auch indirekt eingebundene
neue Hauptversionen der direkten Abhängigkeiten, mit Anheben …

Die Vorschläge sind dieselben wie nach einem gescheiterten Build, nur früher. Siehe Wenn ein Build scheitert.

Android-API-Level anheben

Google Play nimmt Updates nur mit einem aktuellen targetSdk an, für 2026 ist das 36 (Android 16). Liegt ein Projekt darunter, steht im Tab Build eine Zeile mit Umstellen ….

Der Assistent zeigt erst, was im Projekt steht:

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

Dann die Änderungen als Diff, einzeln abwählbar:

− compileSdk = 35
+ compileSdk = 36

Beide Gradle-Schreibweisen werden verstanden, compileSdk = 36 und compileSdkVersion 36. Einrückung und Stil bleiben erhalten.
Steht statt einer Zahl flutter.compileSdkVersion, schlägt der Assistent vor, den Wert fest einzutragen. Dann hängt das Level nicht mehr davon ab, welche Flutter-Version gerade baut.
Ausdrücke, die er nicht versteht, etwa aus einem Version-Catalog, rührt er nicht an und sagt das.
minSdk wird nie angefasst.
Ein zu altes Gradle-Plugin ist eine Warnung, kein Blocker.

Nach dem Ändern räumst du vor dem nächsten Build einmal auf, sonst merkt sich Gradle das alte Level.

Die Zahl umzustellen ist der kleine Teil. Unter Danach prüfen steht, was sich mit Android 16 für die App ändert: erzwungenes Edge-to-Edge, ignorierte Orientierungssperren auf großen Bildschirmen, strengere Hintergrund-Limits. Das findet nur ein Testlauf auf einem Gerät. Die Station behauptet nicht, es zu prüfen.

Versionen und Updates