Google Play Target API 36 Deadline: What Changes on August 31, 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 in August: 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 anything Google has not actually documented is labelled rather than filled in with a confident guess.

The rule in one sentence

Starting August 31, 2026, an ordinary phone, tablet, foldable or Android Auto app must 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 August 31 is your problem 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 deadline lands in the middle of your window. The safe move is to get the API 36 build into the same closed track before August 31, 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 before the date, 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. Build and test API 36 before the deadline, not on it

   Treat the migration as its own task with its own test pass. Discovering an edge-to-edge layout break on August 30 is a very different day from discovering it on August 10.

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

   It buys until November 1, 2026 and it is requested per impacted app. 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 you could not finish by August 31 has to be finished by November 1.

   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.

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.

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: everyone raising their target level this month is rebuilding anyway, which is when the page size check 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 in August 2026 is being asked to do two unrelated hard things in the same window: 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 this month

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. Google updates these pages without notice, so check the primary sources above before acting on any date. This post is scheduled for re-verification immediately after August 31 and again after November 1, 2026.