Target API Level Error in Play Console: How to Fix It (2026)

Short answer: since 31 August 2026, Google Play prevents new apps and app updates that do not target Android 16 (API level 36) from being submitted, and an existing app targeting API 34 or lower stops being offered to new users on newer Android versions. The problem surfaces as a warning or issue on the Policy status page in Play Console, and Google says the extension form to 1 November 2026 is opened from the details page of that same warning. Before you change anything in Gradle, read the target of the build you actually uploaded: apkanalyzer manifest target-sdk app.apk prints it from the artifact itself. Below: the two separate compliance floors per form factor, where each error appears in the Console, how to verify your bundle, what the extension does and does not grant, and what changes in your app when you raise the target. Google's documentation checked 21 October 2026. If you are shipping a first app rather than an update, the surrounding launch steps are covered in our first Android app roadmap.

What Google requires from 31 August 2026

There are two different requirements with two different consequences, and most of the confusion in Play Console comes from mixing them up. The submission floor decides whether Google Play accepts a build at all. The availability floor decides whether your already-published app is still shown to people whose phones run a newer Android version than your app targets.

Google states the submission rule directly: "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play", with lower floors for Wear OS, Android Automotive OS, Android TV and Android XR (Target API level requirements for Google Play apps). The Policy Center version of the same rule is blunter about the consequence: apps that miss it "will be prevented from app submission in Play Console" (Google Play's Target API Level Policy).

The Policy Center article also gives the underlying formula, which makes the dates predictable rather than arbitrary: new apps and updates must target an API level "within one year of the latest major Android version release", while an existing app that is not updated must target an API level "within two years of the latest major Android version release" to stay visible to new users on newer devices.

Form factor	New apps and updates must target (submission floor)	Existing app must target to stay available to new users on newer Android (availability floor)
Phones, tablets, foldables, Android Auto	Android 16 (API 36)	Android 15 (API 35)
Wear OS	Android 15 (API 35)	Android 14 (API 34)
Android Automotive OS	Android 15 (API 35)	Android 12L (API 32)
Android TV	Android 14 (API 34)	Android 13 (API 33)
Android XR	Android 14 (API 34)	Android 14 (API 34)

Both columns come from Google's own tables and bullets on the target API level requirements page, read 21 October 2026. The dates behind the columns are not identical: the Android TV submission floor took effect on 31 August 2025, while the phone, Wear OS, Automotive and XR submission floors and every availability floor in the right-hand column arrived on 31 August 2026. Two practical consequences worth stating on their own:

• A live app sitting at API 35 is compliant today, but its next upload is not. Google's "What to do to comply" section says an existing app targeting Android 15 or higher "is compliant with this policy" for availability. The moment you submit an update, the submission floor of API 36 applies. You cannot ship an emergency hotfix at API 35 after the deadline.
• The extension is tied to availability, not to a lower target. Google describes it as a way "to continue getting distributed to all users on Google Play until November 1, 2026".

Permanently private apps restricted to a specific organisation for internal distribution are the one documented exception. The Android developers' version of the requirement carries the same dates and points back at the Play Console Help article (Meet Google Play's target API level requirement, last updated 1 October 2026).

Where the target API level issue appears in Play Console

Google's help file answers this precisely: "Only apps that are not compliant with the policy will receive a policy warning and notification in Play Console. The extension form is available through the details page of the warning or issue on the Policy status page in Play Console." In other words, a compliant app sees nothing, and everything you need — the wording of the issue and the extension form — lives inside one issue's details page, not in a separate settings screen.

None of this is an account problem. Google verifies developer accounts and developer identities on their own schedules, which we set out in our guides to the Play Console registration fee and verification time and to Google Play developer verification; a target API issue is about the artifact, and clearing it requires a new build rather than new paperwork.

There is a second surface. Pre-review checks run automatically whenever you change your app and appear on the Publishing overview page under "Changes not yet sent for review". Google documents that "You must fix critical issues before you can proceed with publication" while other issues can be deferred with Proceed anyway, which Play Console logs in the Activity log (Detect app issues early with pre-review checks). A target API problem that blocks a build is worth checking on this page next to Policy status, since Google runs these checks before submission rather than after review.

Where you see it	What it means	What to do
Policy status page, issue details	Your published app is below the availability floor for its form factor	Open the details page for the extension form, or upload a build at the required target
Publishing overview, critical pre-review issue	The build you are about to send for review is below the submission floor	Rebuild with the required targetSdkVersion and upload again; publication cannot proceed
Play Console notification	Google is telling the account owner directly that the app is affected	Open the notification, then the linked issue on Policy status
Submission rejected with no review started	Prevention happens at submission, not at review, per the Policy Center rule	Verify the artifact's target before uploading again
No warning anywhere	Google only warns apps that are non-compliant	Still verify your artifact before the next upload

How to verify the target of the bundle Play actually received

Your Gradle file is a statement of intent. Play Console enforces the artifact. Google's command-line tooling documents the exact check: apkanalyzer manifest target-sdk apk-file "Prints the target SDK version", alongside manifest min-sdk and manifest print, which prints the whole manifest in XML (apkanalyzer). It ships inside the Android SDK command-line tools, so no project setup is needed:

apkanalyzer manifest target-sdk release.aab
apkanalyzer manifest min-sdk release.aab

Prefer a GUI: drag the built .aab or .apk into Android Studio's editor to open APK Analyzer, which reconstructs the final AndroidManifest.xml from the artifact so you can read android:targetSdkVersion as Play will see it (Analyze your build with APK Analyzer). Both routes read the file you are about to upload, not the file you meant to build.

Developers in Google's Play Community report that the version details page inside Latest releases and bundles (the app bundle explorer) displays the Target SDK for a given artifact, and Google's help for that page documents inspecting each version's details, downloads and delivery output (Inspect app versions on the Latest releases and bundles page). Treat the console field as a convenience and the local read as the proof; the console field is community-reported rather than documented.

The gap between the two is where most failed submissions come from. Our reading of the pattern, not a Google statement:

• compileSdk was raised but targetSdk was not. They are separate manifest attributes, and only one of them is enforced.
• The bump landed on one branch or product flavor. Release builds are assembled from whatever the release pipeline points at, which is not always the branch you edited.
• CI uploaded a cached artifact built before the change was committed.
• The update was verified in the project, never in the file. Opening the artifact takes seconds and removes the guesswork. It is the same discipline that finds a failing 16 KB native page size problem: the property that blocks you lives in what you built, not in what you configured.

This is also why we check the artifact itself rather than the project settings on every build we run. Our test devices are Samsung, Pixel, Xiaomi and OnePlus units spanning Android 11 to 15 across more than 80 countries, so we see both halves of the rule at once: a raised target changes behaviour on the newer units, while minSdkVersion is what keeps the older units installing the app. Targeting a recent level does not by itself remove older devices, which is the single most common worry we hear about a target bump.

What "Request more time" grants, and what it does not

Play Console contains two different extension mechanisms that look similar in a screenshot and do completely different things.

Mechanism	Where it lives	What it grants
Target API level extension	Details page of the warning or issue on the Policy status page	Continued distribution to all Google Play users until 1 November 2026 while you bring the app up to target
Request additional time	App content page, next to an eligible policy declaration	A new compliance deadline for that declaration, shown as "Extension granted" in its Timeline section

The second row is a different feature with its own help article: it applies to "certain policy declaration deadlines" such as declarations on the App content page, and it does nothing for a target API level issue (Request more time to complete a policy declaration). If you clicked something on App content and your Policy status warning did not move, that is why.

On the target API extension itself, the honest position is that Google's two documents are worded slightly differently as of 21 October 2026. The requirements page still says "You'll be able to access your app's extension forms in Play Console later this year", while the FAQ on the same page says the form "is available through the details page of the warning or issue on the Policy status page in Play Console", and the Policy Center article lists "Request target API level extensions through Play Console" as a do. Impacted apps receive the form link through their Notifications. Plan around the Policy status issue details page, and if the link is not there for your app, ask Play Console Help rather than assuming you have been skipped.

One reading, clearly labelled as ours: Google describes the extension entirely in terms of distribution — continuing to serve all users until 1 November 2026 — and never as permission to submit a build below the submission floor. Treat "can I keep serving users" and "will Play accept this upload" as separate questions, and get the second one confirmed for your own app before you rely on it.

What users see if you do not comply

Google answers this in its FAQ, and the answer is narrower than most developers expect. Existing installs are untouched: "Users who have previously installed the app from Google Play will not be impacted and will still be able to discover, re-install, and use the app on any Android OS version that your app supports."

New users are the loss. On a device running a newer Android version than your app targets, Google Play will tell the visitor that "this app is not available to install on their device because it was made for an older version of Android". Google also concedes the commercial effect directly: compliance problems "may impact your app download levels if new users on devices with newer Android OS versions cannot discover or download your app from Google Play". Your options if you never intend to update are to accept that restricted availability or unpublish the app.

What actually changes when you target Android 16

The deadline is the annoying part; the behaviour changes are the part that breaks apps. Google maintains two separate lists, and it explicitly asks developers to review both: the changes that apply to apps targeting Android 16, and the changes that affect all apps running on Android 16 regardless of target. From the targeting list (Behavior changes: Apps targeting Android 16 or higher):

• Edge-to-edge opt-out is gone. The Android 15 escape hatch windowOptOutEdgeToEdgeEnforcement is deprecated and disabled for apps targeting API 36 running on Android 16, so layouts must handle insets properly.
• Predictive back is on by default. System back animations are enabled, onBackPressed is not called, and KeyEvent.KEYCODE_BACK is not dispatched. If you intercept back, migrate to the supported navigation APIs or temporarily set android:enableOnBackInvokedCallback to false.
• elegantTextHeight is deprecated and disabled, continuing a change that already applied by default from Android 15.

Google's own migration path is: recompile against the existing target first to prove compatibility on Android 16, then raise targetSdkVersion and compileSdkVersion and take the new APIs (the target SDK migration guide, linked by Google from the requirements page). Test on an Android 16 device or emulator, because the targeting changes only activate on the newer OS.

Fix sequence, in order

1. Read the issue. Open the warning on the Policy status page and check which floor it cites: submission (API 36 for phones) or availability (API 35 for phones). They call for different actions.
2. Read the artifact. Run apkanalyzer manifest target-sdk on the exact file you intend to upload, or open it in APK Analyzer and read android:targetSdkVersion.
3. Change the manifest attribute, not just the SDK you compile against. Set targetSdkVersion to 36 for phones, 35 for Wear OS and Android Automotive, 34 for TV and XR.
4. Rebuild, re-run step 2 on the new artifact, and only then upload.
5. If your published app will not reach the required target in time, open the issue details on Policy status and use the extension form there for the run-off to 1 November 2026. Do not confuse it with Request additional time on the App content page.
6. Watch Publishing overview until the critical issue clears. In Google's Play Community on 17 August 2026, a developer reported that the target SDK warning was still showing after publishing an update that targeted API 36, and a responder said the warning is removed "after a few days". Other participants in the same thread advised confirming that the release had been sent for review and rolled out, and letting Policy status refresh, before escalating. That timing is a community report, not a documented Google SLA.

Frequently Asked Questions

What target API level does Google Play require in 2026?

For phones, tablets, foldables and Android Auto, new apps and app updates must target Android 16 (API 36) since 31 August 2026. Wear OS and Android Automotive OS apps must target API 35, and Android TV and Android XR apps must target API 34. An existing app must target API 35 on phones to stay available to new users on newer Android versions.

Does the extension let me submit an update that targets API 35?

Google documents the extension as continuing your distribution to all Google Play users until 1 November 2026. Its documentation does not describe the extension as lowering the submission floor, which it states separately as API 36 for phones. Treat the two as different questions and get a direct answer from Play Console Help for your app before building a release plan on it.

Where do I find the extension form?

Google says the form is reached from the details page of the warning or issue on the Policy status page in Play Console, and that impacted apps receive a form link through their Notifications. Only non-compliant apps get that warning, so a clean account will not show anything.

Why is the warning still there after I uploaded a compliant build?

Because the warning tracks the release that has actually been processed and rolled out, not the file in your local folder. Confirm in Latest releases and bundles that Play shows the new target for that version and that the release completed, then allow Policy status to refresh. Developers reporting this in Google's Play Community saw warnings clear over days. If it persists after that, contact Play Console Help with the package name and version code.

Does raising targetSdkVersion stop older devices from installing my app?

No. Google states that targeting a recent API level "still allow[s] an app to run on older versions (down to the specified minSdkVersion)". Availability on older devices is governed by your minimum SDK, not your target. What a raised target changes is how the app behaves on newer systems.

What happens to users who already installed my app?

They are unaffected. Google's FAQ says previously installed users "will not be impacted and will still be able to discover, re-install, and use the app on any Android OS version that your app supports". The restriction applies to new users on devices running a newer Android version than your app targets.

Is a published app I never update still fine at API 34?

It stays installed and usable for existing users, but on phones it will only be available to users whose device runs an Android version at or below your target, so new-user discovery on modern hardware effectively stops. Google offers an extension to 1 November 2026 if you plan to update, or unpublishing if you do not.

Sources

• Target API level requirements for Google Play apps — Play Console Help (deadlines, per-form-factor floors, extension, FAQ; accessed 21 October 2026)
• Google Play's Target API Level Policy — Policy Center (one-year and two-year rules, submission prevention)
• Meet Google Play's target API level requirement — Android Developers (last updated 1 October 2026)
• Detect app issues early with pre-review checks — Play Console Help
• Request more time to complete a policy declaration — Play Console Help
• Inspect app versions on the Latest releases and bundles page — Play Console Help
• apkanalyzer — Android Developers
• Analyze your build with APK Analyzer — Android Developers
• Behavior changes: Apps targeting Android 16 or higher — Android Developers
• Target SDK migration guide — Android Developers
• Policy notification regarding the required target SDK — Google Play Developer Community thread, 17 August 2026 (community experience, not policy)