For general Android apps, Google Play’s requirements effective August 31, 2026 call for Android 16 (API level 36) or higher for new apps and updates. An already-published general app has a different threshold: it generally needs Android 15 (API level 35) or higher to remain available to new users on devices running a newer Android version. These are separate rules, and the applicable threshold also depends on your app’s form factor. Check the current Google Play target API level requirements before preparing a release.
Which target API level does your app need?
Google Play applies different tests to incoming submissions and to the availability of apps already in the store. The thresholds below are effective August 31, 2026, according to Google Play’s requirements page.
| App category | New app or update submission | Existing-app availability to new users | If below the applicable threshold |
|---|---|---|---|
| General Android apps | API 36 or higher | API 35 or higher | New apps and updates below the submission threshold are blocked. Existing apps below their availability threshold may not be available to new users on devices running a newer Android OS. |
| Wear OS | API 35 or higher | Check the platform-specific existing-app threshold on Google Play’s requirements page. | Submission and existing-app availability consequences depend on which threshold applies. |
| Android Automotive OS | API 35 or higher | Check the platform-specific existing-app threshold on Google Play’s requirements page. | Submission and existing-app availability consequences depend on which threshold applies. |
| Android TV | API 34 or higher | Check the platform-specific existing-app threshold on Google Play’s requirements page. | Submission and existing-app availability consequences depend on which threshold applies. |
| Android XR | API 34 or higher | Check the platform-specific existing-app threshold on Google Play’s requirements page. | Submission and existing-app availability consequences depend on which threshold applies. |
The platform-specific submission requirements are not interchangeable with the general mobile threshold. For specialized apps, confirm both the submission and existing-app rules for that category in the current Play Console Help article before applying the table’s general consequences.
Submission blocking is different from reduced availability
If a new app or update misses its submission threshold, Google Play blocks that submission. For an existing app below its availability threshold, the stated consequence is narrower: it may no longer be discoverable by new users on devices running a newer Android version than the app targets. Google Play says prior installers can continue to discover, reinstall, and use the app on Android versions it supports. This is not the same as removing the app from the store for every user.
#1 Best Overall
Extensions and the private-app exception
Google Play describes an extension to November 1, 2026 for impacted apps. The request form is delivered through Play Console notifications, so treat it as an option to request—not an automatic grace period. Check the affected app’s Console for eligibility and the request form.
Android’s guidance identifies an exception for apps that are permanently private, restricted to users in a specific organization, and intended only for internal distribution. Being unlisted or privately distributed by itself does not establish that an app qualifies. See Android’s target API level guidance and confirm the app’s status in Play Console.
Rank #2
How to check the target level of a release
- Identify the release and app category. Decide whether you are submitting a new app, updating a published app, or checking an existing app’s discoverability. Then identify whether it is a general mobile app, Wear OS, Android TV, Android Automotive OS, or Android XR app. Use the corresponding row and verify the current requirements in Google Play Console Help.
- Inspect the app module’s final target setting. In a typical Gradle project, check the app module’s
targetSdkortargetSdkVersion. Android also documents the manifest attributeandroid:targetSdkVersion. Verify the merged and final build configuration used for the release artifact, rather than relying on a remembered value or a setting in a different build variant. Android’s target SDK guidance describes these settings. - Confirm the threshold for the exact release. A general app update is judged against the new-submission threshold, not merely the lower threshold that may keep an existing app available to new users. Recheck Play Console requirements and app notifications before upload, including any extension or exception that Play Console confirms for this app.
What compileSdk, targetSdk, and minSdk each mean
These settings affect different parts of an Android app; changing one does not automatically change the others. Android explains the distinction in its build documentation.
Quick Recap
| Setting | What it controls | What a change does not mean |
|---|---|---|
compileSdk |
The Android APIs available to the project at compile time. | It does not, by itself, opt the app into the runtime behavior associated with a target API level. |
targetSdk |
The Android version whose runtime behavior the app targets; the platform can activate behavior changes based on it. | Raising it does not by itself drop support for older Android releases. |
minSdk |
The oldest Android API version on which the app can run. | It is not the Google Play target API threshold for a new release. |
How to migrate and test without treating it as a version bump
- Review behavior changes across the migration path. Read both changes that affect all apps running on the new Android version and changes activated when targeting that API level. If your app is moving across multiple Android releases, include relevant changes from intervening versions. Account for third-party libraries and SDKs as well as your own code. Android’s Android 16 behavior changes and migration guidance are starting points.
- Use upgrade and compatibility tools to isolate work. Android Studio’s SDK Upgrade Assistant can help update
targetSdkand surface significant breaking changes. Android 16 compatibility toggles let developers test target-gated behavior changes in debuggable builds without repeatedly changing the app’s target setting. See SDK Upgrade Assistant guidance and Android 16 compatibility framework tools. - Set up the Android 16 SDK and a test environment. Android’s setup examples use
compileSdk = 36andtargetSdk = 36and recommend Android Studio Meerkat 2024.3.1 or higher for Android 16 SDK work. Follow the current Android 16 SDK setup instructions; tooling requirements may change independently of Google Play policy. - Build the release candidate and test affected flows. Run the app on an Android 16 device or emulator and exercise features affected by the behavior changes, along with integrations that depend on platform behavior. Test more than startup: include the user flows and libraries implicated by the migration notes. Compatibility toggles can help isolate target-gated changes, but they do not replace a test of the final target configuration.
- Verify the artifact and Play Console state before submission. Confirm the final build’s target level, category-specific threshold, release date, and any Console-confirmed extension or exception. Revisit the current requirements page and the app’s Play Console notifications immediately before release.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →
