Google Play API 36 deadline: app status and extension choices

Google Play’s next target API checkpoint is close enough to affect a release you may already have built. As of October 10, 2026, the standard Android deadline of August 31 has passed: new apps and app updates submitted to Google Play must target Android 16, API level 36 or higher. Google also has a separate rule for apps already published, and a temporary extension path that runs only through November 1. Those distinctions matter more than simply changing one number in a build file.

Start with the status of the app you are shipping. Google’s target API requirements distinguish a new app that has not been published, an update submitted to replace an existing app, and an existing app already on Play. The August 31, 2026 requirement for new apps and app updates is API 36. For an existing app, the requirement is API 35 or higher to meet the continuing-availability policy. If your app targets API 34 or lower, Google says it will not be available to new users on devices running Android versions newer than the app’s target. Google says users who previously installed the app are not impacted and can continue to discover, reinstall, and use it on any Android version the app supports.

That means a build that was acceptable as an existing release can still be too old for the next update. An app already on Play that targets API 35 meets the existing-app threshold, but a new version submitted after the deadline must target API 36 or higher. A new app that has never been published also needs API 36 or higher. Don’t treat the existing-app threshold as a general exemption for updates.

First identify which rule appliesCopy Anchor Link

Write down the app’s current Play status before changing the project:

• Not yet published: Google defines this as a new app. Its first submission must meet the new-app target, API 36 or higher for standard Android apps.
• Already published, submitting a replacement version: This is an app update. The new submission must target API 36 or higher.
• Already published, with no update being submitted: Check whether its target is at least API 35. If it is API 34 or lower, its availability to new users on newer Android devices is restricted under Google’s policy.

These are policy categories, not build-tool categories. A project can have a release on the store and a different build sitting locally; the local file does not change the status of the published app. Likewise, changing the target in source control does not show that the bundle you intend to upload contains the new value.

The policy page lists exceptions for permanently private apps restricted to a specific organization and intended only for internal distribution. It also lists different targets for other form factors: Wear OS and Android Automotive OS use API 35 for new apps and updates; Android TV and Android XR use API 34. If you ship one of those, use its row rather than applying the standard phone-app requirement.

Check the target in the release you will submitCopy Anchor Link

Find the effective targetSdkVersion for the Android artifact you plan to upload. Google describes this as the app’s target API level, declared in the manifest. Check the value produced by the release build, not only a source setting that may be overridden by a build profile or environment.

Keep three version values separate when you inspect the project:

• Target API is the behavior and policy value Google Play checks for this requirement.
• Minimum API is the oldest Android version the app is configured to support.
• Compile API is the platform level used to compile the app.

Raising the minimum API can drop support for older devices; it is not a substitute for meeting the target API requirement. A successful compile also does not, by itself, confirm that the uploaded bundle has the required target. Record the value from the release artifact or its generated manifest and compare that value with the rule for the app’s status.

If you generate builds from a template or an AI-assisted project, inspect the output as well as the configuration. A starter may preserve the target level that was current when it was created, while the app’s policy deadline moves on. Treat the project’s declared value as a clue, then verify the artifact that Play Console will receive.

Decide whether to update or request an extensionCopy Anchor Link

Google says developers who need more time may request an extension to November 1, 2026. The policy page directs affected developers to Play Console: noncompliant apps receive a policy warning, and the extension form is available from the warning or the app’s Policy status page. Check that page for the specific app rather than assuming that an extension is automatic or that every app has the same form.

An extension is a short runway, not a replacement for the update. If your app is already below the existing-app threshold, decide whether you can raise the target and submit a compliant build before the extension ends. If the project needs behavior changes or dependency updates first, use the extension only if Play Console offers it for that app, and plan the work backward from November 1. If you are preparing a new app or an update, plan around API 36; do not assume that an existing release’s API 35 status makes a new submission acceptable.

The deadline date has already passed as of this article’s check. If you have not reviewed the app since August 31, do that before the next release. For an app below API 35, inspect its Play Console warning and current availability status now. For an upcoming submission, confirm that the release artifact targets API 36 or higher. If the target is already correct, keep a record of the verified artifact so the release does not accidentally use an older build.

Test the target change before releaseCopy Anchor Link

A target-level increase can change which Android behavior rules apply to the app. Review the behavior changes between your current target and API 36, then exercise the app’s critical flows on representative devices and API levels.

Start with the behavior your app depends on: sign-in and account recovery, permissions, notifications, background work, deep links, file sharing, and any flows that use device features. The exact checks depend on the app; this is a test plan, not a claim that every listed area changed in Android 16. Check the behavior-change documentation for the source and target versions, update any incompatible dependencies, and test the release build rather than relying only on a development build.

Keep the Play policy check separate from your product test. A build can satisfy the target API number while still having a broken sign-in flow, and a build that works on one device can still be ineligible for a new submission if its target is too low. Track both outcomes: policy compliance for the submitted artifact, and successful core-flow tests for the app.

A short pre-release decisionCopy Anchor Link

Before your next Android submission, answer these questions in order:

1. Is the app new, an update to a published app, or a published app with no update being submitted?
2. What target API is present in the exact release artifact?
3. Does that value meet the rule for that category: API 36 for a new app or update; API 35 or higher for an existing app’s availability threshold?
4. If the published app is below API 35, does Play Console show an extension option, and what work must finish before November 1?
5. Have you tested the behavior changes that apply to the new target?

If any answer is unknown, resolve it before you queue the release. For a broader review of store submission tasks beyond target API, see our app store submission checklist for an AI-built app. This post covers the target-level decision; the checklist covers the rest of the submission surface.

SourcesCopy Anchor Link

• Target API level requirements for Google Play apps — Google Play Console Help, checked October 10, 2026.