Google Play Target API 36 Rule (2026): Dates, Extension, Fix

From August 31, 2026, Google Play requires every new app and every app update for phones and tablets to target Android 16 (API level 36) or higher before it can be submitted. Google states the rule in a single line: "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." If your build still targets API 35 or lower, Play Console will not accept the release — and a release your console will not accept never reaches your closed testers. Developers who need more time can request an extension to November 1, 2026. This article covers what the deadline actually does, how the extension works, what changes in your code when you move to API 36, and why the timing collides head-on with the 14-day closed test that new personal accounts must run.

What Google requires from August 31, 2026

Google publishes two target API deadlines side by side on its Target API level requirements for Google Play apps page. The first governs what you may upload. The second governs what stays discoverable. They are not the same rule, and merging them is the most common mistake in write-ups of this policy.

Google's own table gives the dates in two rows: Android 16 (API level 36) applies to new apps and to app updates from August 31, 2026, and Android 15 (API level 35) applied to both from August 31, 2025. One exemption exists in the same document: permanently private apps restricted to users in a specific organization and intended for internal distribution only. If you are publishing publicly, that exemption does not apply to you.

The cadence is deliberate. Google requires a target API level within roughly one year of the latest major Android release, which is why the date lands on 31 August every year. API 34 was the floor from August 2024, API 35 from August 2025, and API 36 from August 2026. Nothing about this deadline arrived without warning, and it was announced long before it took effect.

What happens if your build misses the deadline

Two different consequences follow, and only one of them is visible during a launch.

Submission is blocked. For an app that is not yet published, or for any update to a published app, a bundle targeting below API 36 cannot be submitted. The failure shows up at upload time on the release page rather than days later in review, so it does not delay review — it prevents the release from entering review at all. There is no partial submission, no "submit anyway" path, and no way to waive it from outside Play Console.

Discovery shrinks. For an existing app you never update, the separate availability rule applies: Google says 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." Your current users keep the app and can reinstall it. New users on newer phones do not see it as installable. Nothing is removed from the store; the audience quietly narrows with every phone that updates.

Neither consequence affects the 12-tester requirement itself. The closed testing rule is unchanged: Google requires personal developer accounts created after November 13, 2023 to run "a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before they can apply for production access. The target API rule decides whether the build you are testing can be uploaded at all. See Google Play 12 Testers Requirement (2026): What Counts for the testing side of the gate.

Can you get an extension to November 1, 2026?

Yes, and it is the only extension Google has published. On the requirements page, next to the August 31, 2026 date, Google writes: "*Developers will be able to request an extension to November 1, 2026." The availability section repeats it and explains the delivery mechanism: "Impacted apps will receive an extension request form link via their Notifications."

Three details decide whether the extension helps you:

• It is per app, not per account. The form reaches apps Google has identified as impacted, so a developer with several apps may see a link for one and not another.
• It buys two months, not a reprieve. November 1, 2026 is the last date Google has published. There is no second extension behind it.
• You may have to look for it. Google's documentation says the form arrives via Notifications and, in a second sentence, that extension forms will be accessible "in Play Console later this year." Developers report finding the request under the Policy status page, attached to the target API warning itself. If no target API issue is listed for your app, there is nothing to extend.

The honest summary: if you are mid-test and your build targets API 35, request the extension first and migrate in parallel. Chasing a migration while the 14-day clock runs is how two weeks of testing gets thrown away.

Why this collides with your 14-day closed test

For a new personal developer account, the target API deadline does not land in isolation. It lands in the middle of a fortnight during which you are expected to keep 12 testers opted in, keep them using the app, and keep shipping fixes.

Google's production access process makes that explicit. Its help page names two reasons a developer may be required to continue testing: "having fewer than 12 opted-in testers or insufficient tester engagement during the testing period." A build you cannot upload is a build you cannot fix, and an unfixed crash is precisely what an engagement review sees when it looks at your test.

Our own campaign data — 1,500+ closed testing campaigns run on OnTesters — is consistent with that reading:

• 89% approval rate when an app shipped two or more updates during the test, against 53% approval when it shipped none.
• 97% approval when testers stayed active for 10 or more days of the 14, against 41% when they were active for only 5–7 days.
• 72% first-attempt approval across all campaigns, rising to 91% on the second attempt once the rejection reason had been fixed and the application resubmitted.

None of those numbers is a Google statistic, and Google publishes no approval rate of its own. They are our campaigns, not the policy. What they show is that the developers who get through are the ones who keep iterating during the window — which is only possible if every upload in that window actually succeeds.

The schedule pressure is real. We match testers in under 24 hours, and the 14-day count starts from the moment your testers are opted in continuously for the preceding period, not from the moment you finish fixing your build. A rejected upload on day 6 does not pause anyone's clock. The practical rule is simple: verify your target API level and your release build before you invite the first tester, not after. Related: How Long Does Google Play Closed Testing Take?

What actually changes in your app when you target API 36

Raising targetSdkVersion to 36 is one line in build.gradle, and it is not the migration. Targeting a level opts your app into that level's behaviour changes, and Android 16 ships three that visibly affect ordinary apps.

Edge-to-edge can no longer be opted out of. Android 15 enforced edge-to-edge for apps targeting API 35 but allowed an escape hatch through R.attr#windowOptOutEdgeToEdgeEnforcement. Google's Android 16 behaviour changes page states that for apps targeting API 36 the attribute "is deprecated and disabled, and your app can't opt-out of going edge-to-edge." Content that previously sat below the status bar now draws behind it, so screens need proper insets handling.

Predictive back is on by default. For apps targeting API 36 on an Android 16 device, Google enables the predictive back system animations by default and stops calling onBackPressed entirely. If you intercept the back event, you migrate to the supported back navigation APIs or temporarily set android:enableOnBackInvokedCallback to false.

16 KB page size support is now in scope. This requirement arrived earlier and is easily missed: Google's Android Developers Blog announced that from November 1, 2025, all new apps and updates submitted to Play targeting Android 15+ must support 16 KB memory page sizes. Since API 36 sits above that line, targeting 36 puts you inside the rule. Pure Java or Kotlin apps with no native code generally already comply; apps shipping .so files — often through an ad, analytics, maps or payments SDK rather than your own code — need libraries built for 16 KB alignment. Google's compatibility documentation sets a hard stop of February 1, 2027 for updates that still do not support it. Check your bundle in Play Console's app bundle explorer before you assume you are clear.

The cheapest way to find all three is to build against API 36 and run the app on an Android 16 device or emulator before you upload. Testing only on an Android 14 phone will not surface any of them.

Target API level is not minSdkVersion

These two numbers get conflated constantly, and the confusion goes in both directions — some developers fear the migration drops their users, others think raising the target is optional because their min SDK is low.

minSdkVersion decides which devices can install your app at all. targetSdkVersion decides which set of platform rules your app runs under and, since August 31, 2026, whether Play accepts your upload. Raising the target to 36 does not remove a single supported device: an app with minSdk 24 still installs on an Android 8 phone after the migration.

This matters for who can test your app. OnTesters runs campaigns across Samsung, Pixel, Xiaomi and OnePlus devices spanning Android 11 to 15 in more than 80 countries, and every one of those devices installs an API 36-targeting build as long as the min SDK allows it. The honest limitation on our side: our fleet does not currently include Android 16 handsets, so Android-16-only behaviour should still be checked on an Android 16 device or emulator before you submit. That is exactly the check that catches the edge-to-edge and predictive back changes described above.

The three SDK numbers in a Gradle file are worth keeping straight, because only one of them is what Play checks:

Before you invite a single tester, build the release bundle and read minSdkVersion and targetSdkVersion back out of the merged manifest in Android Studio's bundle analyser. Play processes the merged result, not the value you meant to set, and a release that fails here costs you the same days as any other failed upload.

Checklist before your next upload to the closed track

1. Open build.gradle and confirm targetSdk is 36 (or 35 or lower with an extension request already approved through to November 1, 2026).
2. Build and run the app on an Android 16 device or emulator; fix layout insets and back-navigation regressions.
3. Check the app bundle explorer in Play Console for 16 KB page size warnings if the bundle contains native libraries.
4. Confirm the same build installs and runs on an older device inside your min SDK range — the migration must not narrow your tester pool.
5. Upload to the closed track and watch the release reach your testers before you consider the day done, because the 14-day window does not wait for a failed upload.

If an upload fails after testers have already opted in, you have not lost the opt-ins — you have lost days, and days are what the engagement record is made of. Do not pause the closed track and do not clear the tester list while you fix it. Google requires the window to be continuous, and a paused track is the clearest way to break that continuity; push the corrected build to the same track instead, and the existing opt-ins carry on.

What resets the window and what does not — a tester opting out, a count dipping below 12, a new build arriving mid-test — is set out in Google Play 14-Day Closed Testing: What Resets. And if the record is already thin when you apply, see More Testing Required on Google Play: What It Means for what that decision looks like and how to recover.

Frequently Asked Questions

What target API level does Google Play require in 2026?

From August 31, 2026, new apps and app updates for phones and tablets must target Android 16 (API level 36) or higher to be submitted to Google Play. Wear OS and Android Automotive OS apps must target API 35, and Android TV and Android XR apps must target API 34. Existing apps must target API 35 or higher to remain available to new users on devices running a newer Android version.

Was the deadline extended past August 31, 2026?

Google allows a single extension to November 1, 2026, requested through a form linked from the impacted app's Play Console notifications. There is no published extension beyond November 1, 2026.

Does the target API level rule change the 12 testers requirement?

No. The closed testing rule is separate and unchanged: personal developer accounts created after November 13, 2023 need at least 12 testers opted in continuously for at least 14 days before applying for production access. The target API rule decides whether your build can be submitted to the closed track in the first place.

Will raising targetSdk to 36 stop older devices from installing my app?

No. Installation floors are set by minSdkVersion, not by the target API level. An app targeting API 36 with a min SDK of 24 still installs on devices running Android 8 and above, so your existing tester pool on Android 11–15 is unaffected.

What breaks when an app targets Android 16?

Three changes account for most of the work: the edge-to-edge opt-out is deprecated and disabled, predictive back animations are enabled by default with onBackPressed no longer called, and targeting API 35 or higher brings the 16 KB page size requirement into play for apps containing native code.

Can I run my closed test while I migrate to API 36?

You can, but only if the build already on the closed track uploads and installs. Google counts continuous opt-in over 14 days and separately asks about tester engagement when you apply, so a stalled migration that stops you shipping fixes weakens the record you will be reviewed on. Migrate first, then start the clock.

Sources

Google Play Console Help — Target API level requirements for Google Play apps (August 31, 2026 deadline, per-form-factor levels, extension to November 1, 2026, app availability rules). Google Play Console Help — App testing requirements for new personal developer accounts (12 testers, 14 continuous days, reasons for continued testing). Google Play Console Help — Set up an open, closed, or internal test (which track the requirement lives on). Android Developers — Behavior changes: Apps targeting Android 16 or higher (edge-to-edge opt-out removed, predictive back defaults). Android Developers — Meet Google Play's target API level requirement and the target SDK migration guide. Android Developers Blog — Prepare your apps for Google Play's 16 KB page size compatibility requirement.

Two things worth stating plainly about those sources. Google publishes the numeric conditions — 12 testers, 14 continuous days, the API 36 floor, the November 1, 2026 extension — but it publishes no approval rate for production access, no numerical threshold for tester engagement, and no target API waiver beyond the single extension. Where this article describes what Play Console does rather than what Google has written in a help page, it is labelled as developer-reported behaviour rather than policy. Every link above was checked on 2 October 2026. OnTesters campaign figures (1,500+ closed testing campaigns) are our own measurements, not Google statistics.