Google Play target API level 36: the 31 August 2026 deadline, the extension to 1 November, and how to upgrade

From 31 August 2026, Google Play requires new apps and app updates to target Android 16 (API level 36) or higher. If you need longer, there is an extension route to 1 November 2026. This is a hard upload gate, not a review judgement: Play Console refuses the bundle before a human sees it.

Verbatim from Google's policy page: "New apps and app updates must target Android 16 (API level 36) or higher".

How it is worded

You will not get a policy email for this. You get an error in Play Console when you upload, or when you try to roll out a release:

"Your app currently targets API level 35 and must target at least API level 36 to ensure it is built on the latest APIs optimized for security and performance."

If your app is already live and below the bar, you may instead see a policy warning on the Policy status page in Play Console rather than an upload block, because live apps and new uploads are handled by two different rules.

What it means, precisely

Three separate rules, and developers routinely conflate them.

New apps and updates. From 31 August 2026, anything you upload needs targetSdk 36 or higher. Below that, the upload fails. This is the rule that stops you shipping.

Existing apps already published. Google's wording: "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". So an app frozen at API 34 does not vanish. It stops being offered to new users on newer Android versions. Existing installs keep working, and existing users keep getting your app.

Form factors have their own levels. Wear OS and Android Automotive OS apps "must target Android 15 (API level 35) or higher". Android TV and Android XR apps "must target Android 14 (API level 34) or higher". Lower than the phone requirement, and a Wear module needs checking separately.

Note what the requirement is not. compileSdk is a build setting Play does not check, though you need it at 36 to compile against the new APIs. minSdk is untouched: raising your target does not drop old devices. Targeting 36 means "this app has been tested against Android 16 behaviour changes and opts in to them".

The extension

Google's wording: "You will be able to request an extension to 1 November 2026 if you need more time to update your app".

The extension is requested from the Policy status page in Play Console, through the details page of the warning or issue raised against your app. Only non-compliant apps receive the warning, which means the form appears when you have a problem, not before.

Two practical points. An extension buys nine weeks, not a reprieve, and it is per app. With a catalogue, that is a form each.

Why it catches people

• You have not shipped in a year. The requirement moves annually, so a project that was compliant when you last released is now two levels behind.
• React Native, Flutter or Expo pins your target. It comes from the framework's Android template or the Gradle plugin version, not your own configuration. Upgrading the framework is the real task.
• A library breaks at 36. Behaviour changes bite dependencies before your code, and an old advertising, payments or WebView SDK is the usual blocker.
• You raised targetSdk and did not test the behaviour changes, so the build uploads and then crashes for users, which is worse than the block.
• The Wear or TV module was forgotten, with its own manifest and its own requirement, or someone set the target in a product flavour and release differs from debug.

How to upgrade

1. Find out what you actually target. targetSdk (or targetSdkVersion) in android.defaultConfig, checked in the release flavour, not just the default block. Confirm against the uploaded bundle in Play Console, which shows the target level per release.
2. Read the Android 16 behaviour changes list before changing the number. Google splits them into changes affecting all apps and changes affecting apps that target 36. Only the second list is your problem now, and it is short enough to read in an afternoon.
3. Raise compileSdk to 36 first, keeping the target where it is. Compile, fix deprecations, ship if you want. This separates build breakage from runtime behaviour changes, which halves the debugging.
4. Update the framework or plugin if you are not on bare Android. For Expo, an SDK upgrade; for React Native and Flutter, a version bump that carries the Android template. Do this before touching anything by hand, because hand edits get overwritten.
5. Update dependencies with native code, in particular anything touching WebView, notifications, background work, media playback, ads or billing.
6. Then raise targetSdk to 36 and run the app on an Android 16 device or emulator image. Not the emulator you already have. A new one.
7. Test the areas Android has historically changed under the target flag: foreground services and background execution, notification permissions, exact alarms, storage and media access, intent resolution, and edge-to-edge insets handling.
8. Check the form factor modules, each against its own required level.
9. Upload to an internal testing track first. It enforces the same gate, so an internal release proves the bundle is acceptable without touching production.
10. If you will not make 31 August, request the extension now rather than at month end, and treat 1 November as the real date.

Appeal, or upgrade?

There is nothing to appeal. This is not a policy enforcement, it produces no strike, and no reviewer is involved. It is a build requirement enforced by the upload pipeline, and the only routes through are raising the target level or taking the extension.

One decision worth making deliberately: if your app is live, in maintenance, and you cannot get it upgraded in time, the consequence of the existing-apps rule is limited and specific. New users on newer Android versions stop seeing it. Existing users are unaffected. That may be acceptable for a few weeks while you do the work properly, and it beats shipping an untested target level bump that crashes on launch.

Check the dates against Google's live policy page before planning around them. Target API level deadlines have moved before, and a page you read in August is not a source in October.

AppSubmit reads the target API level out of the bundle you are about to upload and compares it against Play's current requirement for every form factor in the project, so the failure happens on your machine rather than in the console. The upgrade is a Gradle change and a test pass, and no tool can do that part for you.