Target API Level 36 bei Google Play: Verlängerung bis 1.11.2026 und Fix für Expo, Flutter, React Native

Die Anforderung zum Target API Level 36 bei Google Play bedeutet: Ein Release, das auf eine Version unter Android 16 abzielt, kann nicht veröffentlicht werden. Stand Oktober 2026 lehnt Play jede neue App und jedes Update mit niedrigerem Ziellevel ab, oft mit der Meldung Target SDK of artifact is too low. Apps mit einer Richtlinienwarnung konnten mehr Zeit beantragen, doch die Verlängerung endet am 1. November 2026. Dieser Leitfaden zeigt, was die Verlängerung noch bringt, wie Sie Expo, Flutter und React Native auf API 36 umstellen und was danach typischerweise kaputtgeht.

Was blockiert die Anforderung zum Target API Level 36 konkret?

Sie blockiert Einreichungen. Seit dem 31. August 2026 können Sie eine neue Smartphone-App oder ein Update nur hochladen, wenn es auf API 36 abzielt. Bereits veröffentlichte Apps, die auf API 35 oder höher abzielen, bleiben vollständig verfügbar, auch für neue Nutzer.

Laut Googles Anforderungen an das Target API Level müssen „neue Apps und App-Updates auf Android 16 (API Level 36) oder höher abzielen, um bei Google Play eingereicht werden zu können“. Die Anforderungen unterscheiden sich je nach Geräteformat, und die einzige vollständige Ausnahme gilt für dauerhaft private Apps, die nur intern in einer Organisation verteilt werden.

Eine bestehende App unter diesen Levels „ist nur noch auf Geräten verfügbar, deren Android-Version gleich oder niedriger als das Target API Level der App ist“. Wer sie bereits installiert hat, kann sie weiter wie gewohnt nutzen. Auf einem neueren Smartphone erfährt man dagegen, dass die App „für eine ältere Android-Version entwickelt wurde“.

Können Sie die Verlängerung vor dem 1. November 2026 noch bekommen?

Nur wenn Play Ihrer App eine Richtlinienwarnung geschickt hat und das Antragsformular dort noch angezeigt wird. Selbst dann gilt die Verlängerung höchstens bis zum 1. November 2026. Sie verschafft also ein paar zusätzliche Tage für einen fast fertigen Fix, aber keinen neuen Zeitplan.

Google gibt an, betroffenen Apps „einen Link zum Formular für den Verlängerungsantrag über die Benachrichtigungen“ zu senden, und das Formular sei „über die Detailseite der Warnung oder des Problems auf der Seite ‚Richtlinienstatus‘ verfügbar“. Apps, die die Anforderung bereits erfüllen, zeigt Google kein Formular an.

1. Öffnen Sie die Play Console und wählen Sie die App aus.
2. Suchen Sie im Posteingang oder in den Benachrichtigungen nach der Meldung zum Target API Level. Falls vorhanden, folgen Sie dem Link.
3. Falls nicht, öffnen Sie „Richtlinienstatus“, rufen die Warnung oder das Problem zum Target API Level auf und suchen auf der Detailseite nach dem Formular für den Verlängerungsantrag.
4. Füllen Sie das Formular für jede betroffene App aus. Jede App hat ihre eigene Warnung.
5. Ob die Verlängerung gewährt wird oder nicht: Planen Sie, vor dem 1. November 2026 einen API-36-Build hochzuladen. Nach diesem Datum erfordern Updates API 36.

Wie stellen Sie Expo, Flutter und React Native auf API 36 um?

Der sauberste Weg ist ein Upgrade auf eine Framework-Version, die bereits auf API 36 abzielt: Expo SDK 54, React Native 0.81 oder Flutter 3.38. Wenn ein Upgrade noch nicht möglich ist, können Sie die Zahl von Hand erhöhen, müssen sich dann aber selbst um die Verhaltensänderungen von Android 16 kümmern.

Expo. Laut Changelog zu SDK 54 zielen SDK 54 und React Native 0.81 „jetzt auf Android 16 ab“. Führen Sie das Upgrade mit npx expo install expo@^54.0.0 --fix durch, starten Sie npx expo-doctor@latest und, falls Sie Continuous Native Generation nutzen: „Löschen Sie die Verzeichnisse android und ios, wenn Sie sie für eine frühere SDK-Version erzeugt haben.“ Unter SDK 53 können Sie versuchen, targetSdkVersion: 36 über das Plugin expo-build-properties zu setzen. React Native 0.79 verarbeitet die Zurück-Aktion aber noch über onBackPressed, lesen Sie also den nächsten Abschnitt, bevor Sie das ausliefern.

Flutter. Die Release Notes zu Flutter 3.38 nennen als Standardwerte flutter.compileSdkVersion (API 36) und flutter.targetSdkVersion (API 36) und „empfehlen dringend, in Ihren Build-Dateien die vom Flutter SDK bereitgestellten API-Level-Variablen zu verwenden“. Version 3.38 benötigt außerdem mindestens Java 17. Ist targetSdk = 35 in Ihrem App-Modul fest eingetragen, ändert das Flutter-Upgrade daran nichts, prüfen Sie also die Datei.

Bare React Native. Setzen Sie compileSdkVersion und targetSdkVersion in android/build.gradle auf 36. Ab 0.81 sind Sie damit weitgehend fertig. Bei älteren Versionen ergänzen Sie zusätzlich android:enableOnBackInvokedCallback="false" im Element <application> der AndroidManifest.xml. Ohne diese Einstellung umgehen Hardware-Zurück-Taste und Zurück-Geste Ihre JavaScript-Navigation.

Was geht kaputt, wenn eine App auf Android 16 abzielt?

Am häufigsten brechen Zurück-Navigation und Layouts für große Bildschirme. Mit API 36 als Ziel ruft Android onBackPressed nicht mehr auf, lässt kein Opt-out aus Edge-to-Edge mehr zu und ignoriert Ausrichtungs- und Größenänderungssperren auf Displays mit mindestens 600dp Breite.

Die für plattformübergreifende Apps wichtigsten Änderungen aus Googles Verhaltensänderungen in Android 16:

• Predictive Back: „onBackPressed wird nicht aufgerufen und KeyEvent.KEYCODE_BACK wird nicht mehr ausgelöst.“ Die Einstellung android:enableOnBackInvokedCallback="false" ist ein vorübergehendes Opt-out.
• Edge-to-Edge: windowOptOutEdgeToEdgeEnforcement ist „veraltet und deaktiviert“, sodass ein Header oder ein Button am unteren Rand unter der Statusleiste oder der Gestenleiste landen kann.
• Große Bildschirme: Auf Displays ab 600dp Breite werden screenOrientation, resizableActivity und Seitenverhältnisgrenzen ignoriert, was reine Hochformat-Layouts strecken kann. Spiele sind ausgenommen. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY ist ein vorübergehendes Opt-out, das „nicht mehr greift, wenn auf API Level 37 abgezielt wird“.
• Text: elegantTextHeight wird ignoriert, was die Zeilenhöhe bei Arabisch, Thai, Tamil und mehreren anderen Schriften verändern kann.
• Gesundheitssensoren: BODY_SENSORS wird durch granulare Gesundheitsberechtigungen wie READ_HEART_RATE ersetzt.

Auf welche Probleme sind andere Entwickler beim Umstieg auf API 36 gestoßen?

Die bisherigen öffentlichen Berichte zeigen zwei Arten von Problemen: ein Verhalten der Zurück-Taste, das sich ohne jede Fehlermeldung ändert, und Bibliotheken, durch die das Ziellevel des bei Play ankommenden Bundles von dem in den Projektdateien abweicht.

Audius (React Native 0.79). In Pull Request #14635 berichtet das Audius-Team, dass Google Play beide Uploads der Android-Version 1.5.186 mit Target SDK of artifact is too low abgelehnt hat. Sie hoben compileSdk und targetSdk von 35 auf 36 an, setzten die Build Tools auf 36.0.0 und ergänzten android.suppressUnsupportedCompileSdk=36, weil „RN 0.79 AGP 8.8 festschreibt“. Außerdem setzten sie enableOnBackInvokedCallback="false", da die Zurück-Aktion sonst „React Navigation umgehen würde“. Ein späterer PR entfernte dieses Opt-out nach dem Umstieg auf React Native 0.81, das selbst einen OnBackPressedCallback registriert.

Eine Flutter-3.35.2-App. In Flutter-Issue #174516 setzte ein Entwickler targetSdk 36 in Gradle und im Manifest, doch die Play Console meldete weiterhin "Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version." Das Entfernen der alten Bibliothek com.google.android.play:core:1.10.3 führte zu R8-Fehlern „Missing classes“. Deren Behebung führte zu "You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles." Akzeptiert wurde das Bundle schließlich, nachdem ProGuard-Keep-Regeln hinzugefügt, minSdk explizit gesetzt und Sprach-, Dichte- und ABI-Splits deaktiviert wurden, auf Kosten eines größeren Downloads.

Die gemeinsame Lehre: Die Zahl in Gradle zu ändern, reicht nicht. Audius musste Laufzeitverhalten korrigieren, der Flutter-Entwickler eine Abhängigkeit, die veränderte, was Play aus dem Bundle ausliest. Prüfen Sie das gebaute Artefakt und testen Sie auf einem Android-16-Gerät, nicht nur die Konfigurationsdatei.

Wie prüfen Sie einen API-36-Build vor dem Upload?

Lesen Sie das Ziellevel direkt aus dem Release-Bundle aus, laden Sie das Bundle dann in einen internen oder geschlossenen Test-Track und testen Sie unter Android 16 Zurück-Navigation, Insets und ein Tablet-Layout. Eine Ablehnung oder ein Fehler in Produktion kostet weit mehr Zeit als diese Prüfungen.

Praxisbeispiel: eine Expo-SDK-53-App, die auf API 35 abzielt und noch ein Update braucht.

1. Führen Sie npx expo install expo@^54.0.0 --fix und anschließend npx expo-doctor@latest aus und beheben Sie alles, was gemeldet wird.
2. Nutzt das Projekt Continuous Native Generation, löschen Sie die alten Ordner android und ios und bauen Sie neu. Andernfalls übernehmen Sie die nativen Upgrade-Änderungen von Hand.
3. Bauen Sie das Release-AAB, zum Beispiel mit eas build -p android --profile production.
4. Bestätigen Sie das Ziel mit bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. Die Ausgabe sollte 36 lauten.
5. Laden Sie den Build in den internen Test hoch. Drücken Sie auf einem Android-16-Smartphone auf jedem verschachtelten Bildschirm „Zurück“, prüfen Sie, dass Header und Buttons am unteren Rand nicht unter den Systemleisten verschwinden, und drehen Sie ein Tablet oder einen größenveränderbaren Emulator.
6. Stufen Sie den Build in die Produktion hoch, mit Versionshinweisen, die die Android-16-Korrekturen erwähnen.

Für schnellere Tests nutzen Sie das Tester-Setup aus unserem Leitfaden zu geschlossenen Tests bei Google Play und übernehmen Formulierungen für den Update-Text aus unseren Beispielen für Versionshinweise. Wenn Sie das Release lieber abgeben möchten: Unser Service für die App-Store-Einreichung deckt Play Console und App Store Connect für $599 für beide Stores ab. Die Gebühren für Entwicklerkonten kommen separat hinzu.