Android target API 36 is now the bar for new apps and updates on Google Play. Google's developer page says that from 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted. Existing apps must target Android 15 (API level 35) or higher to stay available to new users on newer devices.
If your app is older, this is a maintenance task with a real business effect. This guide explains the rules, the changes that can break your app, and a safe order of work.
What the rule says
Google's Play Console Help page sets out three cases.
- New apps and updates: must target API 36 or higher. Wear OS and Android Automotive OS apps need API 35. Android TV and Android XR apps need API 34.
- Existing apps: must target API 35 or higher to remain available to new users on devices running a newer Android version.
- Permanently private apps: apps restricted to one organization and distributed internally are exempt.
Google also describes an extension request until 1 November 2026, made in Play Console. The pages say the form appears there, so check the Policy status page for your app rather than relying on a date you read elsewhere.
How to tell if you are affected
Open your module-level Gradle file and read the targetSdk value. In older projects it may be targetSdkVersion in the manifest. Then open Play Console and look at the Policy status page for the app. Google says affected apps receive a notification, and that the extension form is reached from that page.
Three checks give you a quick answer:
- Is the target below 35? Existing availability to new users on newer devices is at risk.
- Is the target below 36? The next update you ship will be rejected.
- Is the app internal only? It may be exempt, but confirm that it is permanently private.
Write the answers down with the date. It gives your team a shared starting point and gives a manager a clear picture.
Why the number matters
The target API level tells Android which behaviour your app was tested against. Google explains that each Android version brings changes that apply only to apps that declare support through the target level. Raising it opts your app into the new behaviour.
That is why the update is more than a one-line change. In Gradle it is targetSdk = 36, but the effects reach your screens and your code.
What changes when you target Android 16
Google lists the changes in its Android 16 behaviour changes page. These are the ones that most often need work.
Apps targeting API 36 can no longer opt out of drawing behind the system bars. Check headers, buttons and bottom bars.
The system back animations are enabled, and onBackPressed is no longer called. Move to the newer back handling.
Orientation and resizability limits no longer apply on screens 600dp wide or more. Layouts must adapt.
APIs that used body sensor permissions now need the matching health permissions.
Google notes that some of these have temporary opt-outs, and that the large-screen opt-out will not apply when targeting API 37. Treat opt-outs as a short bridge, not a plan.
Layouts are the usual surprise
Apps built for portrait phones often assume a fixed shape. On tablets, foldables and desktop-style windows, the same screen may now stretch. Test those sizes before release, not after the first user report.
Back navigation needs a real test
If your code overrides the back button, predictive back can change what users see. Walk through every flow that has a dialog, a bottom sheet or an unsaved form.
Common blockers we would check first
Updates stall for ordinary reasons, and most of them are outside your own code.
- Old libraries. An ad, analytics or payment SDK that has not been updated may fail on the new level.
- Build tooling. A new target level can need a newer Gradle plugin and compile SDK, which pulls in other upgrades.
- Hard-coded layouts. Fixed sizes and fixed orientation break on large screens.
- No test coverage. Without automated tests, every change needs a full manual pass.
None of these is a reason to wait. Each one is easier to fix before the deadline pressure grows.
A safe order of work
- 1AuditList your current target, SDKs and libraries
- 2Raise on a branchSet targetSdk to 36 and build
- 3Fix what breaksEdge-to-edge, back handling, permissions
- 4Test on real devicesPhone, tablet, foldable, older Android
- 5Staged rolloutRelease to a small share, then widen
Start with the audit. Old third-party libraries are a common blocker, because a library that has not been updated may use APIs that behave differently on the new level.
Then test beyond the happy path. Run your regression suite, add checks for screen sizes and back behaviour, and release in stages through Play Console so a problem reaches few users first. Our QA and testing practice treats release sign-off as a gate for this reason.
Plan the update before it is urgent
The requirement will move again when the next Android version arrives. Teams that keep the target level close to current spend less on each jump, because the behaviour changes arrive in small steps.
A yearly maintenance slot works well: update the target level, upgrade libraries, run the full test pass and release. It is cheaper than an emergency update when new installs start to drop.
How XOSOFT can help
Our mobile app development practice covers native iOS, native Android, cross-platform builds and store release. If your Android app needs the update and you want an engineer to check the risks first, a Discovery Sprint is a low-risk start. You can also book a technical call. It is a conversation with engineers, not a sales pitch.
Frequently asked questions
What happens if my app does not target API 36?
New apps and updates that do not meet the requirement cannot be submitted. Existing apps that target API 34 or lower stay available only on devices running that Android version or lower, so new users on newer phones may not see them.
Do users who already installed my app lose it?
No. Google says people who already installed the app keep access, can reinstall it and can keep using it. The restriction affects availability to new users on newer devices.
Is there an extension?
Google's pages describe an extension request to 1 November 2026, made through Play Console. Check the Policy status page in Play Console for the current form and your app's status.
Is changing targetSdk enough?
No. Raising the number changes how the system treats your app. Layouts, back navigation and permissions can behave differently, so the update needs testing on real devices.
Need help with mobile app development?
Talk to the engineers who would do the work. We reply within one working day.