Google Play's target API level 36 deadline is 31 August 2026

From 31 August 2026, Google Play will not accept a new app or an app update unless it targets Android 16 (API level 36) or higher. That is two weeks from today. If you have not looked at your targetSdk value recently, look now, because the failure happens at upload time and there is nothing to negotiate with.

Google's wording, from the target API level requirements page:

Starting August 31 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher.

There is an extension route, and it is worth knowing about before you panic.

If you need more time to update your app, you'll be able to request an extension to November 1, 2026. You'll be able to access your app's extension forms in Play Console later this year.

That sentence is still written in the future tense on Google's own page. Check whether the form exists in your console before you plan around it.

Two different rules, two different consequences

Most coverage of this deadline collapses two separate requirements into one. They are not the same, and confusing them will either scare you unnecessarily or leave you exposed.

The submission rule is the one with the 31 August date. On and after that date, an upload that targets below API 36 is refused. Your existing published app is untouched. You simply cannot ship a change to it.

The availability rule is about who can install what you have already published. Google's text:

Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level. Apps that target Android 14 (API level 34) or lower, including Android 13 (API level 33) or lower for Wear OS, Android TV, and Android XR, and Android 12 (API level 31) or lower for Android Automotive OS, will only be available on devices running Android OS that are the same or lower than your app's target API level.

Read that carefully, because it is the quieter problem. An app stuck at API 34 does not get removed. It stops appearing for new users on newer devices, which looks exactly like your install rate falling off for no reason. Existing users keep the app.

The only stated exception is narrow:

Permanently private apps that are restricted to users in a specific organization and intended for internal distribution only.

How to check your current target, in about a minute

Check the artifact, not your memory of the code. A Gradle property can be overridden by a build variant, a manifest entry, or a plugin, and the only value that matters is the one baked into the bundle you upload.

In the source, for a native Android project. Look for targetSdk in app/build.gradle or app/build.gradle.kts, inside defaultConfig. Google notes that the value can also live in the manifest as the android:targetSdkVersion attribute of the <uses-sdk> element, and that a Gradle entry can override it. Check both.

In the built artifact, which is the answer that counts. For an APK:

aapt2 dump badging app-release.apk | grep targetSdk

For an app bundle:

bundletool dump manifest --bundle=app-release.aab \
  --xpath=/manifest/uses-sdk/@android:targetSdkVersion

In Play Console. Open the app, then Release, then App bundle explorer, and read the target SDK version recorded against the artifact you last shipped. This is also the fastest way to check an app you inherited and cannot build locally.

If you use Expo or React Native. The value is set by the expo-build-properties config plugin, or by the Expo SDK's own default if you have not set it. A bare workflow project reads from android/app/build.gradle after prebuild, and edits to app.json will not reach it. Build the bundle and run bundletool dump manifest on it, because that is the only check that survives the prebuild step.

If you use Flutter. android/app/build.gradle carries either a literal targetSdk or a reference to the Flutter plugin's default. Again, dump the manifest from the built bundle rather than trusting the reference.

What actually breaks when you bump to 36

Raising the number is one line. The behaviour changes that switch on when you raise it are the work. These apply specifically to apps targeting Android 16, and each is worth ten minutes of testing before you ship.

Edge-to-edge becomes mandatory. Google's text: "For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge." If you were opting out, your content will now run under the status and navigation bars. Fix the insets.

Predictive back is on by default. "For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore." If you intercept back to show a confirmation dialog, that code has stopped running. Migrate to OnBackInvokedCallback. There is a temporary opt-out via android:enableOnBackInvokedCallback="false".

Orientation and resizability locks stop working on large screens. "For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp." That covers screenOrientation, resizableActivity="false", minAspectRatio, maxAspectRatio and setRequestedOrientation(). A portrait-only phone app will be asked to fill a tablet or foldable window. There is a per-activity opt-out property, android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY, and Google describes it as temporary.

Body sensor permissions are split up. "As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead." If you read heart rate, you now request READ_HEART_RATE. This one fails at runtime, quietly, on a code path you may not test.

elegantTextHeight is ignored. Layouts with tight line heights in Arabic, Thai, Tamil or Telugu will shift.

The full list is on the Android 16 behaviour changes page, split into changes that affect all apps and changes that only affect apps targeting 36. Read the targeting-36 section. It is short.

The order I would do this in, with two weeks left

  1. Dump the manifest from your last uploaded bundle and write down the actual number. Guessing here wastes a day.
  2. If you are already at 36, you are done. Check your Wear OS, TV or Automotive builds separately, because they have different floors.
  3. Bump targetSdk to 36, build, and install on a device or emulator running Android 16. Do not read the diff, run the app.
  4. Walk the back button, the top and bottom of every scrolling screen, rotation on a tablet or foldable window, and any sensor permission flow. Those four cover most of what changes.
  5. Upload to an internal testing track first. The upload check is the same check, so a rejected upload tells you the target level is wrong before you have staked a release on it.
  6. If step 3 uncovers real work, go and look for the extension form in Play Console rather than shipping something broken to hit a date.

One more date, so you only do this once

While you are in the build file: from 1 February 2027, app updates targeting Android 15 (API level 35) or higher must support 16 KB memory page sizes on 64-bit devices. Google's wording is "Starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates."

This only bites if your app ships native code, directly or through an SDK. A pure Kotlin or Java app is already compliant. If you are rebuilding everything for API 36 anyway, checking your NDK libraries now is much cheaper than rediscovering it in January.

AppSubmit reads the target API level out of the bundle you are about to ship and blocks the upload if it is below the current floor, which is the same bundletool dump manifest check described above. You can run that command yourself in ten seconds, and before 31 August, you should.

Sources

Last reviewed 2026-08-17. Apple and Google change their rules without notice, so check anything decision-critical against their live documentation.