Google Play's API 36 deadline has passed — what actually breaks when you upgrade

Disclosure: I work at ZoopCoder, an Indian dev shop, and we sell a paid fixed-price version of this upgrade. Everything below is from Google's own published documentation and is linked so you can check it. There are no fees in this post paid to us except the one clearly marked at the end — treat this as a commercially interested source and verify the dates yourself.

If you have an Android app in production and you have not shipped an update since August, there is a decent chance Play Console will refuse your next upload with this:

Your app must target Android 16 (API level 36) or higher.

That is not a bug and it is not your build tooling. It is Google Play's annual target API level requirement, and this year's step took effect on 31 August 2026.

Here is exactly what the rule says, what it blocks, how much time you have left, and — the part most posts skip — what actually breaks when you raise the number.

The rule, in Google's words

From Meet Google Play's target API level requirement:

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.

So:

Form factor	Minimum target API level
Phones / tablets / foldables	36 (Android 16)
Wear OS	35 (Android 15)
Android Automotive OS	35 (Android 15)
Android TV	34 (Android 14)
Android XR	34 (Android 14)

Two things people get wrong about this:

1. It applies to updates, not just new apps. A five-year-old app with a million installs cannot ship a one-line crash fix until its targetSdk goes to 36. The block is on the upload itself, in Play Console, before review.
2. There is a second, softer rule for apps you never touch again. Existing apps must target API 35 or higher "to remain available to new users on devices running Android OS higher than your app's target API level." An app left on API 34 doesn't vanish — it just quietly stops being installable by new users on current phones, which looks identical to your install rate dying for no reason.

The documented exception is narrow: "permanently private apps that are restricted to users in a specific organization and intended for internal distribution only."

You can buy time, once, until 1 November 2026

Also straight from that page:

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 is the whole reprieve. It is a one-off form inside Play Console, it moves your date to 1 November 2026, and it does not renew. If you are reading this and you're blocked, filing that is the first thing to do — then do the work, because the extension is not a plan.

What actually breaks (this is the real work)

Bumping targetSdk from 35 to 36 is one line. Everything after that line is the job. Four changes catch almost everybody, all documented in Behavior changes: Apps targeting Android 16:

1. The edge-to-edge opt-out is gone

Android 15 enforced edge-to-edge for apps targeting API 35, but you could escape with R.attr#windowOptOutEdgeToEdgeEnforcement = true. For apps targeting API 36, that attribute is deprecated and disabled on Android 16 devices — you cannot opt out any more.

Practical effect: your content now draws under the status bar and the navigation bar. Buttons end up under the gesture pill; headers end up under the clock. Nothing crashes, so CI stays green and the bug arrives via a screenshot from a user.

The fix is to apply window insets properly (Compose / Views) rather than to hunt for a new opt-out flag. There isn't one.

2. Predictive back is on by default — and onBackPressed is never called

This is the nastiest one, and it is the reason I am writing this post:

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 your app intercepts the back key at all, that interception silently stops running. The single most common casualty is the WebView wrapper pattern — the classic

@Override
public void onBackPressed() {
    if (webView.canGoBack()) webView.goBack();
    else super.onBackPressed();
}

— which is in a very large share of India's small-business apps. After the upgrade, back exits the app instead of going back a page, and it does so from the first screen the user ever presses back on.

Two options: migrate to the supported back navigation APIs, or set android:enableOnBackInvokedCallback="false" on <application> or the specific <activity> as a temporary opt-out while you migrate. Google's own wording for that flag is "temporarily opt out", and it is worth treating that word as load-bearing.

3. Orientation and aspect-ratio locks stop being honoured on big screens

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

If you shipped screenOrientation="portrait" and assumed it would hold, it won't on a tablet, a foldable's inner screen, or desktop windowing. There is a per-activity manifest opt-out (PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY) and an application-level one, but the direction of travel is obvious and the escape hatches are explicitly transitional.

4. elegantTextHeight is deprecated and ignored — and this one is an India problem

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

Six of those ten scripts are Indian. If your app ships Tamil, Telugu, Kannada, Malayalam, Odia or Gujarati strings, your line heights move and tightly-packed layouts clip. Nobody in your QA group is going to catch that unless somebody is explicitly told to look at the regional-language build.

While you are in there: the 16 KB page size deadline

Different rule, same neighbourhood, and worth doing in the same sitting. From Support 16 KB page sizes:

To ensure your app works correctly on the latest versions of Android, all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. 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.

The good news, also from that page:

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices.

So this only bites if you (or a dependency — think older video, ML, crypto, PDF or game SDKs) ship native .so files. Check your AAB's lib/arm64-v8a/ contents before you assume you're clear, because "a library I depend on has NDK code" is a much more common answer than "I wrote NDK code".

What this costs

Honest version: if it's a healthy modern project with maintained dependencies, this is a half-day for someone who has done it before, and you should just do it yourself using the links above. Nothing in this post is secret.

It gets expensive when the project is old: an unmaintained Gradle plugin, an AGP version that won't compile against API 36, a dependency that was abandoned three years ago, a Cordova shell. Then you are not doing a one-line bump, you are doing an archaeology project.

If you'd rather hand it over, ZoopCoder does this as a fixed-price job: target API 36 upgrade — ₹2,999, 2-4 working days, which covers the tooling update, the four behaviour changes above, a 16 KB check on native libraries, and a signed AAB. We quote separately (and say so up front) if the project turns out to need a rewrite rather than an upgrade — that is the honest failure mode of a fixed price on legacy code.

The wider point, which is worth more than the service: an Android app is not a thing you finish. Google and Apple move their requirements on their own calendar, not yours, and an app nobody touches for two years eventually fails a store requirement without anything about it having "broken". We put a yearly number on that in what website and app maintenance actually costs in India.

Do the extension form today if you're blocked. Then do the upgrade before 1 November.