Ziel-API-Level bei Google Play: worauf zielt Ihr Bundle?
Google Play erzwingt eine harte Untergrenze für targetSdkVersion, und sie steigt jedes Jahr. Unterhalb der Grenze blockiert die Play Console den Upload rundweg — das ist keine Einschätzung eines Prüfers, das ist ein Tor. Diese Seite nennt die aktuelle Schwelle, den Jahresfahrplan und wie Sie auslesen, worauf Ihr .aab oder .apk tatsächlich zielt, bevor Sie es auf die harte Tour erfahren.
Zuletzt geprüft am 24. Juli 2026.
Die aktuelle Grenze und der Jahresfahrplan
Googles Regel ist mechanisch: Ihre App muss ein API-Level anvisieren, das höchstens ein Jahr hinter dem letzten großen Android-Release liegt. Jeden Herbst erscheint ein neues Android-Major, also steigt die geforderte Grenze etwa am 31. August jedes Jahres um eins. Sie gilt für neue Apps und für jedes Update einer bestehenden App — Sie können keinen neuen Build hochladen, der unterhalb der Grenze zielt.
Bestehende Apps, die Sie nicht aktualisieren, bekommen mehr Anlauf, müssen die Vorgabe aber irgendwann erfüllen, um auf neueren Geräten verfügbar zu bleiben. So sieht der Fahrplan derzeit aus:
| Ab | Neue Apps und Updates müssen zielen auf | Bestehende Apps müssen zielen auf |
|---|---|---|
| 31. Aug. 2024 | API 34 (Android 14) | API 34, um auffindbar zu bleiben |
| 31. Aug. 2025 | API 35 (Android 15) | — |
| 31. Aug. 2026 | API 36 (Android 16) | API 35 (Android 15) oder höher |
targetSdkVersion vs. minSdkVersion vs. compileSdkVersion
Entwickler werfen diese drei regelmäßig durcheinander, und nur eines davon erzwingt Play. Sie werden unabhängig voneinander in der build.gradle gesetzt:
| Eigenschaft | Was sie steuert | Regel von Play? |
|---|---|---|
targetSdkVersion | Das API-Level, für das Ihre App erklärt, gebaut und getestet worden zu sein. Es schaltet die Verhaltensänderungen dieser Version scharf. Genau dieses erzwingt Play. | Ja — harte Untergrenze. |
minSdkVersion | Die älteste Android-Version, auf der die App installierbar ist. Niedriger = mehr alte Geräte, mehr Altlast-Pfade. | Nein. |
compileSdkVersion | Das API-Level, gegen das kompiliert wird — welche APIs der Compiler sieht. Meist gleich hoch wie target oder höher. | Nein, muss zum Bauen aber ≥ target sein. |
Sie können (und tun es oft) eine niedrige minSdkVersion für die Reichweite behalten und trotzdem das neueste API-Level anvisieren, um Play zufriedenzustellen — die beiden hängen nicht zusammen. Eine höhere targetSdkVersion bedeutet, dass Sie die Verhaltensänderungen der neuen Version behandeln müssen; sie kostet keine Unterstützung für alte Geräte (das ist minSdkVersion).
Die genaue Fehlermeldung der Play Console
Zielt ein .aab unterhalb der Grenze, blockiert die Play Console den Release mit einer Meldung dieser Form:
Your app currently targets API level 34 and must target at least API level 35 to ensure it is built on the latest APIs optimized for security and performance. To upload an app bundle it must target API level 35 or higher.
Das ist ein Fehler, der den Release blockiert, keine Warnung — das Bundle wird nicht hochgeladen. Die beiden Zahlen in der Meldung sind Ihr aktuelles Ziel und die geforderte Grenze; die Lösung ist, targetSdkVersion in der build.gradle auf das geforderte Level zu heben und neu zu bauen.
targetSdkVersion aus einem .aab / .apk auslesen, ohne Android Studio
Sie brauchen keinen kompletten Android-Studio-Build, um zu prüfen, worauf ein Bundle zielt. Der Wert steht im Manifest — das Manifest in einem gebauten Artefakt ist aber binär kodiert (AXML im APK, Protobuf im AAB), also helfen `unzip` und `cat` nicht. Nehmen Sie stattdessen die SDK-Kommandozeilenwerkzeuge.
Für ein .apk
# aapt (oder aapt2) dekodiert das binaere Manifest aapt dump badging app.apk | grep -o "targetSdkVersion:'[0-9]*'" # -> targetSdkVersion:'35' # oder apkanalyzer (liegt den Android-SDK-cmdline-tools bei) apkanalyzer manifest target-sdk app.apk # -> 35
Für ein .aab (App Bundle)
# bundletool liest das Protobuf-Manifest per XPath java -jar bundletool.jar dump manifest --bundle=app.aab \ --xpath=/manifest/uses-sdk/@android:targetSdkVersion # -> 35
aapt, aapt2 und apkanalyzer liegen in den build-tools / cmdline-tools des Android SDK; bundletool ist ein eigenständiges JAR von Google. Keines davon baut oder startet die App — sie dekodieren nur das Manifest, also dauert die Prüfung auf jedem Rechner mit JDK eine Sekunde.
Der Weg über die einjährige Verlängerung
Wenn Sie die Frist zum 31. August wirklich nicht halten können, bietet Google eine einmalige Verlängerung, die Sie in der Play Console beantragen — sie schiebt Ihre Frist auf den 1. November desselben Jahres. Sie ist für echte technische Blockaden gedacht, nicht für gewöhnlichen Verzug:
- Sie beantragen sie pro App in der Play Console, bevor die Frist verstreicht — es gibt einen eigenen Ablauf, sobald Ihre App als nicht konform markiert ist.
- Sie bringt rund zwei zusätzliche Monate (bis zum 1. November), kein weiteres Jahr.
- Sie gilt dafür, eine bestehende App verfügbar zu halten; sie erlaubt in der Zwischenzeit keine neuen Updates unterhalb der Grenze.
- Sie ist für berechtigte Fälle gedacht (eine noch nicht kompatible Abhängigkeit, eine große Migration). Google kann Anträge ablehnen, die nach Ausweichen aussehen.
Die Verlängerung ist ein Aufschub, keine Lösung — die einzige dauerhafte Antwort ist, targetSdkVersion zu heben und die Verhaltensänderungen der neuen Version zu behandeln.
Häufige Fragen
Welches Ziel-API-Level verlangt Google Play aktuell?
Im Zeitfenster 2025–2026 müssen neue Apps und Updates mindestens API-Level 35 (Android 15) anvisieren. Ab dem 31. August 2026 steigt die Grenze für neue Apps und Updates auf API 36 (Android 16), und bestehende Apps müssen mindestens API 35 anvisieren, um auf neueren Geräten verfügbar zu bleiben.
Verliere ich durch eine höhere targetSdkVersion alte Telefone?
Nein. Die Unterstützung alter Geräte steuert minSdkVersion, und die ist unabhängig. Sie können eine niedrige minSdkVersion behalten und trotzdem targetSdkVersion anheben, um Play zufriedenzustellen. Eine höhere Zielversion heißt allerdings, dass Sie die Verhaltensänderungen der neuen Android-Version behandeln müssen.
Die Play Console sagt, mein Ziel sei zu niedrig, aber Android Studio zeigt die richtige Zahl. Warum?
Prüfen Sie den Wert im tatsächlich gebauten Artefakt, nicht nur im Quellcode. Produkt-Flavors, ein Manifest-Override oder ein alter Build können eine niedrigere targetSdkVersion ausliefern, als Ihre build.gradle vermuten lässt. Lesen Sie sie mit bundletool oder aapt direkt aus dem .aab/.apk, um zu sehen, was Sie wirklich hochgeladen haben.
Bekomme ich mehr Zeit über den 31. August hinaus?
Ja — die Play Console bietet eine einmalige Verlängerung bis zum 1. November desselben Jahres für Apps, die die Frist nicht halten können. Sie ist für berechtigte technische Blockaden gedacht und hält nur die bestehende App verfügbar; Updates unterhalb der Grenze erlaubt sie nicht.
Ist die Ziel-API-Vorgabe dasselbe wie eine Ablehnung in der App-Prüfung?
Nein. Es ist ein automatisches Upload-Tor in der Play Console, das vor jeder Prüfung greift. Kein Prüfer ist beteiligt — das Bundle wird schlicht nicht hochgeladen, solange targetSdkVersion die Grenze nicht erreicht.
Passend dazu: Warum Google Play Apps ablehnt · Checkliste für die Android-Einreichung
Quellen
Prüfe deinen Build, bevor du einreichst
Lass deine .ipa oder .apk durch App Review Checker laufen und erkenne diese Probleme in Sekunden.
App prüfen