Google Play API 36 Deadline: What to Do

The short answer: Since 31 August 2026, Google Play only accepts new apps and app updates that target Android 16, which developers call API level 36. If your developer requested the extension, you have until 1 November 2026. After that, an app on an older target cannot ship anything: no feature, no bug fix, no security patch. And an app that has fallen two levels behind quietly disappears for new users on newer phones. One number tells you where you stand, so ask your developer for it today: "what is our target API level?"

What happens to your app

"Target API level" is a setting inside the app that tells Android which version it was built and tested for. Find yours in the table.

Your app targets	Can you publish an update?	Can new users find and install it?
Android 16 (API 36)	Yes	Yes, on all devices the app supports
Android 15 (API 35)	No, not after 31 August, or 1 November with the extension	Yes
Android 14 (API 34) or lower	No	Only on phones running the same Android version as your target, or older. New users on newer phones will not see it

Three clarifications from Google's own pages:

Existing users are not affected. Anyone who has installed the app before can still find it, reinstall it and use it.
Other devices have lower bars. Wear OS and Android Automotive apps must target Android 15. Android TV and Android XR apps must target Android 14.
Private internal apps are exempt. Apps permanently restricted to people inside one organisation do not have to comply.

Why this is easy to miss: nothing breaks on the day. Current users keep using the app, reviews keep coming, and the only symptom is a slow drop in new installs that nobody connects to a setting in a build file.

That drop matters for more than installs. Fewer new users and a stale "last updated" date both work against your App Store Optimization.

Five questions to ask your developer

You do not need to understand the code. You need to recognise a good answer.

Ask this	A good answer sounds like	A worrying answer sounds like
What is our target API level today?	A number, straight away. "35. We move to 36 this month."	"I will have to check", or "it is the latest" with no number
Have we requested the extension in Play Console?	"Yes, on this date", or "we do not need it, the update is in review"	"What extension?"
Which SDKs in the app need updating first?	A list: payments, analytics, maps, ads, login, push notifications, each with a version	"It should be fine"
Does the app contain native code, and is it ready for 16 KB page sizes?	"Yes, these libraries. We checked them with Android Studio's APK Analyzer" or "No, it is Kotlin and Java only"	"That does not apply to us", with no check done
What will you test, and on which phones?	A list of screens and journeys, on a small phone, a large phone and a tablet, on old and new Android versions	"We will check that it opens"

What changes when you target Android 16

Raising the target is not a one-line change. It switches on newer Android behaviour, and these are the changes that most often show up on screen.

Edge-to-edge is compulsory. The app draws behind the status bar at the top and the navigation bar at the bottom. On Android 15 an app could opt out. For apps targeting Android 16 that opt-out is ignored. Buttons stuck under the navigation bar are the classic symptom.
The back gesture changes. Predictive back animations are on by default, and the old way of intercepting the back button is no longer called. Any screen with custom back behaviour, such as "are you sure you want to leave?", needs checking.
Large screens ignore your orientation lock. On tablets and foldables (screens 600dp and wider), restrictions on orientation, resizing and aspect ratio are ignored. A portrait-only app will be stretched across a tablet in landscape. Google offers a temporary opt-out, which is a postponement, not a fix.
Health and fitness permissions are more granular. Apps that read body sensor data, such as heart rate, must request specific new permissions.
Background timers behave differently. Repeating tasks that were missed while the app was in the background no longer all fire at once when it returns.

The 16 KB requirement

This is a separate Google Play rule that often surfaces at the same time. Newer Android devices can use memory "pages" of 16 KB instead of 4 KB. Google Play says all apps targeting Android 15 or higher must support 16 KB page sizes on 64-bit devices, and the Android documentation currently states that from 1 February 2027, updates that do not support it cannot be released.

If the app and every library in it are written only in Kotlin or Java, it already complies.
If it contains native code, directly or inside a third-party SDK, those parts must be rebuilt or updated. Your developer can check in minutes: open the build in Android Studio's APK Analyzer and look for files ending in .so inside the lib folder. The tool flags any that are not aligned.
Most fixes are SDK version bumps. Google's advice is to check each SDK provider for the version that supports 16 KB.

If your app is built with React Native or Flutter

Cross-platform apps have one extra layer: the framework has to support the new target before your app can.

React Native. Version 0.81 targets Android 16 by default, and its release notes cover the same points as above: edge-to-edge with no opt-out, predictive back on by default, and the built-in SafeAreaView component deprecated in favour of a community library. The React Native team says the framework itself meets the 16 KB requirement, but third-party native libraries have to be checked one by one.

Flutter. Flutter apps have defaulted to edge-to-edge since version 3.27. Flutter's own documentation warns that the Android 15 opt-out stops working on Android 16. If your app used that opt-out, it has to be removed and the layouts fixed.

In both cases the usual blocker is not your code. It is one old plugin that nobody maintains any more. Ask for the plugin list early, because replacing one can take longer than everything else combined.

A testing checklist by area

Area	What to check
Layout	Every screen top and bottom: nothing hidden under the status bar, camera cut-out or navigation bar. Keyboard open on every form
Navigation	Back gesture from every screen, including pop-ups, payment pages and web views
Large screens	A tablet and a foldable, portrait and landscape, and split-screen
Permissions	Fresh install: camera, location, notifications, photos, contacts. Deny each one and see what the app does
Notifications	Push arrives with the app open, in the background and closed. Tapping it opens the right screen
Payments and login	A full real transaction on each payment method. OTP, Google sign-in, password reset
Third-party SDKs	Analytics events still firing, maps loading, ads showing, crash reporting working
Performance	Cold start time and scrolling on a budget phone, and a 16 KB test device or emulator if the app has native code
Old devices	The oldest Android version you still support. Raising the target must not break it

Release to a small percentage of users first using Play Console's staged rollout, watch the crash rate for a few days, then widen.

A yearly maintenance calendar

Google raises this requirement every year, and the deadline has fallen on 31 August in recent years. So the work is predictable. This is a planning pattern, not an official schedule. Confirm each year's dates on Google's page.

When	What to do
January to March	Review Google's developer previews and betas of the next Android version. Note the changes that affect your app
April to May	Update SDKs and the framework (React Native or Flutter). Remove dead plugins
June to July	Raise the target level. Run the full testing checklist. Staged rollout
By 31 August	Compliant update live. No extension needed
September to October	Buffer. Fix anything real users report
Any time	Do the iPhone equivalent. Apple sets its own yearly SDK requirement and lists it on its Upcoming Requirements page

Put the cost in the annual budget as a line of its own. Done on schedule it is routine work. Done in the last week of October it is an emergency, with a deadline your developer does not control.

Where this fits

An app is never finished. Yearly platform updates are part of owning one, and we plan them into app development from the first release for both Android and iOS. If the forced retest exposes screens that look dated, that is a sensible moment for a UI/UX design refresh, which we cover in Liquid Glass vs Material 3 Expressive.