Google Play Target API 36 Deadline: What Changes on August 31, 2026

What changes on November 1, 2026

November 1, 2026 ends Google's published target API extension period. It does not end your ability to submit a compliant update, and it does not change what an unchanged published app needs. Two situations get confused all the time:

Google Play Console Help, target API level requirements, and the developer.android.com target SDK guide, both read October 15, 2026.

Google raises the Play Store's target API floor once a year, and 2026 is the API 36 cycle. The number is not the confusing part. The confusing part is that "the target API level requirement" is really two rules wearing one name: one governs what you are allowed to upload, and a different, lower one governs who can still install what is already published. Nearly every page ranking for this question blurs the two, which is how developers end up rebuilding an app that did not need rebuilding, or shrugging off a Play Console warning that mattered.

This post separates them, gives you the per form factor numbers, and then answers the question our support inbox actually receives: what does this do to an app that is halfway through a 12-tester, 14-consecutive-day closed test? PrimeTestLab runs that testing side for developers, so we see the timing collision constantly, and the guidance in that section applies whether you use a service or recruit testers yourself. Every date and level below was checked against Google's own pages on August 9, 2026 and re-checked on October 15, 2026, and anything Google has not actually documented is labelled rather than filled in with a confident guess.

The rule in one sentence

Since August 31, 2026, an ordinary phone, tablet, foldable or Android Auto app has had to target Android 16, API level 36 or higher to be submitted to Google Play, whether it is a brand new app or an update to a published one. That single sentence covers most readers. The exceptions, and the separate lower floor for apps you are not touching, are what the rest of this post is about.

One name, two different rules

Google uses the phrase "target API level requirement" for two things that behave nothing alike. Keeping them apart is the single highest value thing you can do with this page.

So an app sitting quietly on API 35 with no planned updates is compliant on August 31 under rule 2, and becomes noncompliant the instant you try to ship anything under rule 1. That is not a contradiction, it is the design: Google raises the bar for what enters the store faster than it raises the bar for what stays in it.

The three words Google defines precisely

The policy leans on three terms, and each has a specific meaning that decides which rule you are under:

• New app: an app "not yet published on Google Play". First upload of a package name.
• Existing app: an app that is already published on Google Play.
• App update: a new version of an existing app submitted for review to replace the current one. An update is judged by the submission rule, not the availability rule.

Requirements by form factor

"Android app" is not one row. Phones, tablets, foldables and Android Auto go to API 36. Wear OS and Android Automotive OS stop at API 35. Android TV and Android XR stop at API 34. The floors for an app you are not updating are lower again, and the switch below flips between the two sets.

Android Auto is not Android Automotive OS

These two names cost developers real time every year. Android Auto projects an app from a phone onto the car's screen, so the app is a phone app and follows the phone rule: API 36. Android Automotive OS is the operating system running on the vehicle itself, and it is one of the named lower target exceptions: API 35. If you build a media or navigation app that ships to both, you need the higher of the two.

Are you affected? Answer three questions

Whether the target API rule is your problem right now depends on three things: what you are about to do, which form factor you ship, and what your current build actually targets. The tool below applies Google's published floors to that combination and tells you which of the two rules you are under.

If the verdict says you are clear, you still want the pre-deadline checklist at the end, because "my source sets target 36" and "the artifact Google evaluated declares 36" are not the same claim. The most common false sense of safety in this whole cycle is a developer reading their Gradle file instead of their uploaded bundle.

What actually happens if you miss August 31

Two different things, depending on which rule you are under. If you try to upload a build below the floor, the submission does not meet the requirement. If you simply leave a published app alone below the availability floor, it stops being discoverable and installable for new users on devices running a newer Android version than it targets. Neither outcome is deletion.

If you try to upload

Note what this consequence is attached to: the act of uploading. The calendar alone does not do anything to a build that is already live. This is why an app can be perfectly compliant on September 1 and blocked on September 2, purely because you decided to ship a bug fix.

If you leave a published app below the floor

This is the one competitors describe as "your app disappears", which is wrong in a way that matters. Google's wording is that the app will "stop being discoverable" for a specific group of users. Concretely:

• New users on newer devices lose access. If a user's device runs an Android version higher than your app's target, Google Play no longer shows or installs the app for them.
• New users on older devices are unaffected. A device running the same or a lower API level than the app targets can still receive it.
• Previous installers are unaffected. Anyone who already installed the app can still find it, reinstall it, and use it on supported Android versions.
• Deep links tell the truth. A user on an ineligible newer device who opens your Play Store link is told the app was "made for an older version of Android".

What does not happen

Every August this policy generates the same four fears in Google's support forums. None of them is what the target API level page describes.

Will targeting API 36 kill support for older phones?

No, not by itself. targetSdk declares the Android behaviour level your app is built and tested for. minSdk decides the oldest Android version it can install on. They are separate numbers, and raising the target to 36 does not itself raise the minimum: your app can keep supporting older Android versions down to that minimum, provided your code and any upgraded dependencies remain compatible.

This is the misunderstanding that generates the most alarm every cycle. A developer reads "must target Android 16", assumes it means "only runs on Android 16", and concludes Google has just deleted most of their addressable devices. Drag the minimum below and watch what actually changes.

The three numbers, and which one Google Play polices

What this means if your app is in closed testing right now

If you are a new personal developer account running the mandatory 12-tester, 14-consecutive-day closed test, the migration, or the end of an extension, can land in the middle of your window. The safe move is to get the API 36 build into the same closed track now, keep every tester opted in, and never let a deadline force you into changing tracks or restarting testers.

Google's target API page and Google's closed testing page are written by different teams for different purposes, and neither one addresses the other. That leaves a genuine gap, and the honest thing to do is show you exactly where the documented ground ends.

What is verified

• A qualifying new personal account "must run a closed test" with at least 12 testers opted in continuously for the last 14 days before it can apply for production access. This applies to personal accounts created after November 13, 2023. Verified
• Google's developer documentation says an uploaded APK must meet Play's target API requirements, and publishes no exception for testing tracks. That wording is track-agnostic, not testing-specific, so a new closed-track upload after the deadline should be planned for as needing API 36 — a strong inference, not a documented testing-track rule. Partial
• Google's own guidance encourages developers to keep updating the app in closed testing while fixing issues, and defines the qualifying period around tester opt-in continuity, not around one frozen artifact. Verified
• Internal testing is capped at 100 testers and does not substitute for the qualifying closed test. Verified

What Google has not documented

Because the answer is unknown, the correct strategy is not to predict it. It is to make the question irrelevant by having a compliant build in the track now, which is safe under either outcome and costs you nothing if the old artifact would have kept running anyway.

The sequence that is safe either way

1. Keep the same closed track and the same tester group

   Do not create a fresh track to hold the API 36 build and do not remove opted-in testers. The 14-day continuity Google counts is about testers staying opted in, so the enrollment is the asset you are protecting.

2. Treat the API 36 migration as its own task, with its own test pass

   Run the Android 16 checks before the upload, not after a rejection. Discovering an edge-to-edge layout break on the day you need to ship is a very different day from discovering it a week earlier.

3. Upload it to the existing closed track with a higher version code

   Every replacement bundle needs an incremented version code. Google defines the qualifying period around tester opt-in continuity and explicitly encourages developers to keep fixing issues during testing, but it does not publish an absolute guarantee covering every build-replacement scenario. Keep the same track and the same opted-in testers, and confirm the Play Console counter afterward. The full mechanics of updating mid test are worth reading if this is your first cycle.

4. Confirm the release actually reached testers

   A published release is not the same as a delivered one. Check that the closed release is live, that the version code is higher, and that testers on the opt-in list can see the update.

5. Recheck Policy status after processing

   Give the bundle time to process, then reopen the app's Policy status page. If the target API warning persists, work the triage list rather than deleting releases at random.

6. Request the extension only if the migration genuinely cannot land in time

   Google's published extension period ends on November 1, 2026, and it was requested per impacted app from that app's own notice. After that date the only route is a compliant build, so it is not a reason to pause the technical work.

How to request the November 1, 2026 extension

Impacted developers can request an extension that keeps distribution running until November 1, 2026. It is requested per app, from that app's policy warning in Play Console. Google does not describe it as automatic, guaranteed, or a permanent exemption, so keep migrating while the request is open.

Google Play Console · real screenshot Click to enlarge

1. Open the affected app in Play Console

   Extension access is app specific rather than account wide. If you publish several apps, expect to repeat this for each impacted one.

   Verified
2. Go to Policy status

   Only apps Google considers noncompliant are expected to carry the target API issue. If the app is already compliant, there is nothing here to extend and no form to find.

   Verified
3. Open the target API warning or issue details

   The issue title shown in the screenshot above is App must target Android 16 (API level 36) or higher. Wording can still vary by app and by rollout state, so treat that as what one real account saw rather than a guaranteed universal string.

   Verified
4. Follow the extension link in the issue, or in Notifications

   Google routes some impacted developers through the app notification rather than the issue panel. Check both before concluding the option does not exist for you.

   Verified
5. Submit the requested information

   Google does not publish the exact questions on its public help page, so treat any list of "the questions they ask" as unverified. Answer from your real migration plan.

   Partial
6. Treat November 1, 2026 as the hard stop

   The extension moves the date, it does not remove the requirement. Whatever a granted extension covered has to be finished by November 1, 2026; after that, a compliant API 36 artifact is the only way to submit an ordinary mobile update.

   Verified
7. Keep migrating while the request is open

   Nothing in Google's wording promises approval. Planning around a granted extension you have not received is the most expensive assumption available this cycle.

   Partial

One more distinction worth holding onto: Google attaches the extension footnote to the API 36 requirement, and its prose most often describes the extension as preserving distribution for an existing app. It does not walk through every new app, update and existing app permutation with equal precision. Before you assume an extension covers a particular upload you have planned, read what your app's own warning says it covers.

What about API 37 in 2027?

Google has announced that new apps and updates will be required to target API level 37 from August 2027. The current requirements table does not yet give an exact day or the 2027 form-factor exception matrix, so this post does not invent one. Android 17's own release schedule (platform stability targeted for March 2026, a major release in Q2 and a minor SDK release in Q4) is a different timeline from Play's targeting calendar; keep them separate. Partial: month announced, day not published

How to upgrade an app to API 36

Four steps: install the API 36 SDK, raise compileSdk and targetSdk to 36, update the dependencies that break when you do, and test the Android 16 behaviour changes. Changing the number is a one line edit. Proving the app still works is the actual migration.

My update was rejected for its target API level. What do I fix?

Start with the target API level of the uploaded version the issue names, then change the build that produced it. The generic migration steps below are the same; this is the order to do them in when Play Console has already said no.

1. Read the issue. Open the app's target API issue in Policy status and note the version code it names, the target it reports and the floor it asks for. Keep a screenshot of the actual text.

2. Inspect that artifact. In Test and release, Latest releases and bundles, open that version and read its target API level. Compare it with the branch, flavour or export that built it. The artifact is the evidence; the editor setting is not.

3. Fix the producer. If the artifact is below 36, install the API 36 platform and raise compileSdk and targetSdk, or take the framework or exporter route for your stack below. Leave minSdk alone unless tooling or dependencies force a separate change.

4. Test, then upload with a higher version code. Run the signed release build on Android 16 and on your oldest supported version, especially after a framework minimum change.

5. Read the new artifact back. Confirm its target in Play Console, confirm the release state, then reopen the policy issue after processing. If the warning still names an older version, check which track that version is still live on; do not delete a running closed test to clear it.

6. Still blocked with a correct artifact? Use the app's Help route with the issue text, version codes, track and artifact details. Do not assume an extension request has been granted; the scope comes from that app's own notice.

Google Play Console Help on viewing uploaded versions and on target API requirements, the Android SDK configuration guide, and developer reports of persistent warnings, all read October 15, 2026. The sequence is practical triage, not a measured cause ranking.

Step 1: install the Android 16 SDK

Open Android Studio, go to the SDK Manager, and install the Android SDK Platform for API level 36 along with the current 36.x.x build tools. Without the platform installed, raising compileSdk just produces a build error that looks unrelated to anything you did.

Step 2: raise the levels in your build

Pick your stack. The file path and the exact lines change, the destination does not: the manifest inside your uploaded bundle has to declare target 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Step 3: update dependencies and framework tooling

Raising the compile level is where old dependencies fail. Expect to touch the Android Gradle Plugin, Gradle itself, Kotlin, AndroidX libraries, Google Play services, and any ad or analytics SDK that ships native code. This post deliberately does not publish "the correct versions", because compatible versions move weekly and a hardcoded list here would be misleading within a fortnight. Take them from your framework's own current release notes on the day you migrate.

Step 4: build, upload, and verify the artifact

• Generate a signed Android App Bundle and increment the version code.
• Test the release artifact, not just a debug build. Minification and resource shrinking break things that debug builds hide.
• Upload to the intended track and confirm in Play Console that the artifact reports target API level 36.
• After processing, review every active track and reopen Policy status.

Android 16 behaviours to test before you ship API 36

Targeting API 36 switches on Android 16 behaviours for your app on Android 16 devices. The high-priority behaviours to test are edge-to-edge layout, predictive back, large-screen orientation freedom, health permissions, fixed-rate scheduling and text layout. Tick what applies below and you get the test list for your app rather than a generic one.

Edge-to-edge and predictive back: the widest blast radius

Edge-to-edge has a wide blast radius because it does not need your app to use any exotic API. On Android 16, an app targeting API 36 can no longer use the previous opt-out attribute, so content that assumed the system bars would leave room for it now runs underneath them. The symptom is cosmetic right up until the moment a primary button sits under the gesture bar and stops being tappable.

Predictive back carries a similarly wide blast radius. If your app registers legacy back handling, that path may simply not fire the way it used to once predictive back is enabled by default for target 36. Test back from every navigation depth you have: modals, WebViews, forms with unsaved state, and the last screen before exit.

What is not a universal target 36 break

What about the 16 KB page size requirement?

Different requirement, different date, same apps. The target API deadline is about the level your manifest declares. The 16 KB page size requirement is about whether your native libraries work on devices with 16 KB memory pages. Google's current guidance names February 1, 2027 as the date affected app updates without 16 KB support can no longer be released.

• Who it affects: Google's requirement applies to apps targeting API 35 or higher on 64-bit Google Play devices. Within that group, apps that package native .so libraries — directly or through an SDK — are the ones most likely to need explicit rebuild and alignment work. If your app is Kotlin or Java only, it is generally already compatible, but it is still worth testing rather than assuming.
• What it is not: it is not part of the August 31, 2026 target API deadline, and passing one does not pass the other.
• Why it lands together: raising a target level usually means rebuilding, and a rebuild is when an independent native-library page size problem surfaces. That timing is why the two get confused.

If your app bundles native libraries, treat the page size check as its own task with its own test pass rather than something you fold into the API 36 build at the last minute. The two changes touch different parts of the build, and debugging them at the same time is how a one-week migration becomes a three-week one.

You uploaded API 36 and the warning is still there

Usually one of three things: the bundle has not finished processing and Policy status has not refreshed, an older artifact is still sitting on another active track, or the artifact you uploaded does not actually declare 36 even though your project does. Work down the list, and do not start deleting releases.

The current issue title developers are reporting is Your app must target Android 16 (API level 36) or higher. Google has not published a canonical full error string for every upload flow, so treat exact wording you find online, including that one, as observed rather than official.

One habit fixes most of this permanently: after every upload, read the target API level back from the artifact in Play Console and write it down next to the version code. It takes ten seconds and it removes the entire category of "I am sure I fixed this" from your week.

The pre-deadline checklist

Fourteen items, in the order they actually happen. The last four are the ones people skip, and they are the ones that decide whether the warning clears.

Where PrimeTestLab fits into this deadline

To be clear about the boundary: we do not migrate your code. Raising targetSdk, updating dependencies and fixing Android 16 behaviour changes is your build, and this post is the whole of our contribution to it. What we do cover is the other half of the collision, the 12 real testers, opted in for 14 consecutive days that a new personal account needs before it can reach production at all.

The timing is the problem. A first-time publisher is being asked to do two unrelated hard things at once: ship an API 36 build, and hold a qualifying closed test together for two straight weeks. The build is a solvable engineering task. Recruiting twelve real humans who stay opted in for fourteen days, on real devices, is the part that quietly consumes a month.

Doing the closed test yourself versus handing it over

The order to do it in

If you are facing both problems at once, run them in parallel rather than in sequence. Start the closed test now, because its 14 days are wall-clock time you cannot compress, and do the API 36 migration alongside it. Push the compliant build into the same closed track when it is ready, with a higher version code and the same testers still opted in. That way the deadline and the testing window stop competing for the same fortnight.

Frequently asked questions

Bottom line

Policy snapshot verified August 9, 2026 and re-verified October 15, 2026 against Google's current target API, page size and closed testing pages. Google updates these pages without notice, so check the primary sources above before acting on any date. Next editorial recheck: after the extension period ends on November 1, 2026.