Google Play now asks for two different things depending on what you are doing. Since 31 August 2026, any new app and any update must target API 36, which is Android 16. An app that is already listed and is not being updated only needs to target API 35 to stay available. So if you are shipping anything at all, the number that applies to you is 36, and an extension to 1 November 2026 can be requested if you need one.
That distinction is the part people get wrong, because the lower number is the one that gets quoted. It is the floor for staying listed, not the bar for publishing, and the moment you touch the app you are held to the higher one.
The app does not stop working. Everyone who has it installed keeps using it exactly as before. What happens instead is that it becomes unavailable to devices running newer Android versions, which means new installs quietly decline while everything on your dashboard looks superficially fine.
What target API level actually controls
There are three version numbers in an Android project and they are routinely confused, which is why this deadline catches people who thought they had handled it.
Minimum SDK is the oldest Android version your app will install on. Raising it drops old devices. Compile SDK is which API version your code is built against. Target SDK is a declaration to the operating system: this app has been tested against this version and expects its behaviour.
That last one is the deadline. Android uses it to decide how much backwards compatibility to apply. An app targeting an old API gets legacy behaviour for permissions, background execution and storage, because the system assumes it was never updated for the newer rules. Google's requirement exists to stop apps sitting on compatibility shims indefinitely.
Raising the target is therefore not a version number edit. It is a statement that you have tested against the newer behaviour, and the behaviour genuinely changes.
What breaks when you raise it
The changes that catch teams are rarely in their own code. They are in libraries, in permissions, and in assumptions made years ago.
Background work is the most common. Successive Android versions have tightened what an app may do when not in the foreground, and code that starts a service on a schedule, or on receiving a broadcast, may find the system simply refuses. Apps that sync, poll, or run periodic uploads hit this first.
Permissions are second. Newer versions replaced broad permissions with narrower ones and added runtime prompts where previously there were none. An app that requested storage access and read whatever it liked now needs to request scoped access and handle refusal properly, which many older codebases never had to do.
Then there are dependencies. A library last updated in 2022 may not be compatible with the current target, and if it is abandoned you are choosing between forking it, replacing it, or removing the feature. This is usually the part that turns a two day task into a two week one, and it is invisible until you try.
Read More - Google's August Spam Update Finished on the 21st. Did Your Traffic Move?
The deadline is not the only Play change this year
Two others matter and are easy to miss because they do not produce a console warning until you are already affected.
Google has introduced a Contacts permissions policy pushing apps toward the Android Contact Picker rather than broad address book access. If your app reads the whole contacts list to offer an invite feature or to match users, that pattern is now discouraged and increasingly restricted. The picker returns only what the person explicitly selects, which is better privacy and a real change to how the feature works.
Google has also separated billing fees from store service fees, and introduced a reduced rate tier for developers meeting quality benchmarks through the Apps Experience Program. If you sell anything in your app, the fee you pay is no longer a single number you can assume, and it is worth actually checking rather than carrying the figure you learned three years ago.
Organisation accounts additionally require a D-U-N-S number or equivalent business registration, which is straightforward but slow if you discover it during a release.
Why this becomes urgent at the worst moment
The pattern we see is not a team ignoring the deadline. It is a team that raised the target last year, considered it handled, and did not realise the bar moves annually. The work is small and the surprise is the expensive part.
The failure mode is not a broken app. It is an app that cannot ship.
Teams typically discover the requirement when they try to release something else. A bug fix, a price change, a seasonal feature. The upload is rejected because the target API is too low, and now a small change is blocked behind a compatibility project nobody scoped.
That is the expensive version. The same work done deliberately, with time to test background behaviour and replace an abandoned dependency, is ordinary maintenance. The same work done because a critical fix is blocked is a fortnight of pressure with a customer waiting.
If your app has not been updated in over a year, assume you are in this position and check before you need to ship rather than after.
What a sensible upgrade looks like
Raise the target in a branch and build. The compiler will tell you about removed APIs immediately, and that list is the smallest part of the work.
Then test the behaviours that change silently. Background sync, notifications, file access, camera and media, anything using contacts or location. These compile perfectly and fail at runtime on a device running the newer version, which is why an emulator on the right API level matters more than the build succeeding.
Audit dependencies before you start, not during. List every library, check its last release date, and identify anything unmaintained. Finding that a payment or analytics SDK is abandoned is much better news in week one than in week three.
Ship to internal testing first and use it for a few days on a real device on the new Android version. Store policy compliance is checked at upload; behavioural regressions are not, and those are what reach your users.
Read More - Your Reps Update the CRM the Night Before the Meeting: Fix CRM Adoption
The maintenance question underneath
We treat this as a recurring calendar item on every app we look after rather than as a project, because it arrives every year whether or not anyone planned for it. An app with no owner is the one that discovers the deadline through a rejected upload, which is also the version that stalls a release nobody expected to be blocked. It is the same neglect that shows up in retention, which we went through in why nobody opens your app after day one.
Target API deadlines arrive annually. So do App Store equivalents, dependency deprecations, and OS behaviour changes. An app is not a project that finishes.
Businesses that treat mobile as a build once asset consistently end up in emergency upgrades, because the accumulated gap between their code and the current platform grows until crossing it is a project rather than a task. Businesses that budget a few days a quarter never experience this deadline as an event at all.
That is the honest cost of an app, and it is worth knowing before commissioning one. We set out the wider version of that calculation in whether your business actually needs an app. If you already have one and it has drifted, our mobile app development team does these upgrades as scoped work rather than emergencies.
Frequently Asked Questions
What happens to my app if I miss the deadline?
Existing installs keep working and existing users are unaffected. The app stops being available to new users on devices running recent Android versions, and you cannot publish updates until the target is raised. It is a distribution and release freeze rather than an outage, which is why it goes unnoticed.
Is raising the target API just changing one number?
The edit is one number. The work is verifying that your app still behaves correctly under the newer rules for background execution, permissions and storage, and that every dependency supports the new target. For a well maintained app it can genuinely be a day. For one untouched in three years it is usually weeks.
Can I raise the target without raising the minimum SDK?
Yes, and you generally should. Target and minimum are independent. You can target API 36 while still supporting much older devices, which is the normal configuration. Raising the minimum drops users and is a separate decision with its own reasoning.
How do I know which target level my app uses?
It is in your Gradle configuration as targetSdk, and Play Console shows it on the app bundle details for each release. If the console is warning you about it, you are already past the point where it needs attention.
Does this affect iOS too?
Apple runs an equivalent requirement on its own schedule, requiring builds against a recent SDK for new submissions. The specifics differ but the pattern is identical: both stores periodically require you to have kept up, and both enforce it at submission. If you ship on both, they need planning together.
We have no in-house mobile developer. What now?
Scope it as a defined piece of maintenance rather than an open ended engagement. A target API upgrade has a clear finish line: builds against the new target, passes testing on the new Android version, and uploads to Play without rejection. That is a fixed piece of work, which makes it easy to brief and easy to price.
How often will this keep happening?
Annually, and the requirement moves forward each year. Treat it as recurring maintenance in the same category as certificate renewals: predictable, unavoidable, and much cheaper handled on a schedule than discovered under pressure.
Talk to our team if your app has not shipped an update in a while and you would rather find out now than when a fix is blocked.