Identify which rule applies
| Distribution case | Requirement in the current guidance |
|---|---|
| Standard new mobile app or update | Target API 36 or higher |
| Wear OS or Android Automotive OS new app/update | Target API 35 or higher |
| Android TV or Android XR new app/update | Target API 34 or higher |
| Existing mobile app remaining available to new users on newer Android versions | Target API 35 or higher |
The existing-app threshold is not permission to submit an API 35 mobile update. Submission and ongoing discoverability are separate gates. The official guidance also lists separate existing-app thresholds for each special form factor.
Check the uploaded bundle, not just the editor
Read the target SDK from the exact release artifact. Build flavors, convention plugins or a stale exported project can make the uploaded value differ from the setting you just edited. APKLint's Target SDK Checker helps inspect that artifact; it does not submit an extension or certify policy compliance.
Raise compileSdk as required by the build, then audit target-dependent changes: permissions, background execution, edge-to-edge layouts and other behaviors relevant to your app. Test both clean installation and update from the production version.
Handle a deadline notice explicitly
The current policy allows affected developers to request an extension to 1 November 2026. An extension is not automatic. Check the app's notification and the issue details under Policy status for the available request and its outcome.
The source contains rollout wording about form availability; the actual app notice is the operational reference. Keep a record of the submitted request rather than assuming the general help article granted one.
Understand the impact on existing users
A discoverability restriction for new users on newer devices is not the same as disabling installations already obtained from Play. Google describes different treatment for previous users. Do not tell every user to sideload an unknown replacement APK.
Use the current target-API policy as the dated source of truth and repeat this check before the next release. This article's date does not make later policy changes apply retroactively.
Check the release flavor that reaches the store
Suppose a project has a development flavor targeting API 36 while a production convention still overrides the target to 35. An emulator run of the development app can succeed even though the production bundle misses the applicable submission threshold. Build the actual production variant and inspect its packaged target SDK before preparing the release.
The target-API guidance, reviewed on 29 September 2026, separates new submissions and updates from existing-app availability. Classify the intended action and form factor first. A threshold for an existing listing is not an alternative target for a newly submitted mobile update.
Use the target change to select behavior tests
List the platform behaviors relevant to this app: permission requests, background work, display insets, notifications or file access as applicable. Follow Android's migration documentation for the target transition and turn each affected behavior into a specific test. Changing a numeric build setting alone does not resolve compatibility changes in application code.
Test a clean install and an upgrade preserving realistic synthetic state. For a reminder app, for example, confirm that saved reminders, permission denial and later permission changes behave correctly after the update. A screen that renders normally at launch says little about a scheduled operation occurring later.
If requesting a documented extension, retain the actual app-specific request and outcome. Continue the technical migration while that request is considered. A general help page mentioning an extension does not prove that a particular app has been granted one.
Check supported device and form-factor releases independently. A shared source repository can produce artifacts governed by different distribution requirements. Keep each artifact's inspected target and intended destination in the release record so a compliant watch build is not mistaken for evidence about the phone bundle.
Finally, inspect the uploaded artifact details and the resulting Console notice. If they disagree with local expectations, compare checksums and variant settings before making another speculative configuration change. This connects the policy assessment to the exact package being submitted.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
