Google Play target API level requirement: what does your bundle target?

Last reviewed 24 July 2026.

The current floor and the yearly schedule

Google's rule is mechanical: your app must target an API level within one year of the latest major Android release. A new Android major ships each autumn, so around 31 August each year the required floor bumps up by one. It applies to new apps and to every update of an existing app — you cannot push a new build that targets below the floor.

Existing apps that you don't update are given a longer runway, but they eventually must comply to stay available to newer devices. Here is the schedule as it stands:

targetSdkVersion vs minSdkVersion vs compileSdkVersion

Developers routinely conflate these three, and only one of them is what Play enforces. They are set independently in build.gradle:

You can (and often do) keep a low minSdkVersion for reach while targeting the latest API level to satisfy Play — the two are unrelated. Raising targetSdkVersion means you must handle the new version's behaviour changes; it does not drop old-device support (that is minSdkVersion).

The exact Play Console error

When an .aab targets below the floor, the Play Console blocks the release with a message in this 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.

It is a release-blocking error, not a warning — the bundle will not upload. The two numbers in the message are your current target and the required floor; the fix is to raise targetSdkVersion to the required level in build.gradle and rebuild.

How to read targetSdkVersion from an .aab / .apk without Android Studio

You don't need a full Android Studio build to check what a bundle targets. The value is in the manifest — but the manifest inside a built artifact is binary-encoded (AXML in an APK, protobuf in an AAB), so `unzip` + `cat` won't work. Use the command-line SDK tools instead.

For an .apk

# aapt (or aapt2) decodes the binary manifest
aapt dump badging app.apk | grep -o "targetSdkVersion:'[0-9]*'"
#  -> targetSdkVersion:'35'

# or apkanalyzer (ships with the Android SDK cmdline-tools)
apkanalyzer manifest target-sdk app.apk
#  -> 35

For an .aab (App Bundle)

# bundletool reads the protobuf manifest via XPath
java -jar bundletool.jar dump manifest --bundle=app.aab \
  --xpath=/manifest/uses-sdk/@android:targetSdkVersion
#  -> 35

aapt, aapt2 and apkanalyzer live in the Android SDK's build-tools / cmdline-tools; bundletool is a standalone jar from Google. None of them build or run the app — they just decode the manifest, so the check takes a second on any machine with a JDK.

The one-year extension path

If you genuinely can't meet the 31 August deadline, Google offers a one-time extension you request from the Play Console — it pushes your deadline to 1 November of the same year. It is meant for real technical blockers, not routine slippage:

• You request it per app in the Play Console before the deadline passes — there is a dedicated flow when your app is flagged as non-compliant.
• It buys roughly two extra months (to 1 November), not another year.
• It applies to keeping an existing app available; it does not let you push new updates that target below the floor in the meantime.
• It is intended for legitimate cases (a dependency not yet compatible, a large migration). Google can decline requests that look like avoidance.

The extension is a stay of execution, not a fix — the only durable answer is to raise targetSdkVersion and handle the new version's behaviour changes.

FAQ

Related: Why Google Play rejects apps · Android app submission checklist

Sources

• Google Play Console Help — Target API level requirements for Google Play apps
• Android Developers — Meet Google Play's target API level requirement
• Android Developers — bundletool (reading the manifest)
• Android Developers — aapt2 / apkanalyzer