On this page
The target API level is the single number Play checks when you submit an update. Google requires new apps and app updates to target an API level close to the latest major Android release, with the deadline moving each year. Miss it and Play stops accepting updates, which is why this requirement deserves a place on every release calendar.
targetSdkVersion versus minSdkVersion
| Setting | What it controls | Who it affects |
|---|---|---|
| minSdkVersion | The oldest Android version your app can install onto. | Users on very old devices. |
| targetSdkVersion | The Android version your app declares compatibility with, which unlocks modern behavior. | Play's acceptance of your build and runtime behavior on new devices. |
Raising minSdkVersion drops support for old devices. Raising targetSdkVersion changes how your app behaves on current devices, because Android applies newer permissions, storage, and background-execution rules to apps that target the newer level. Play enforces the target, so the two numbers move independently.
How the Play requirement works
The rule is roughly one year: new apps and updates must target an API level within a year of the latest major Android release. Google announces the exact cutoff each cycle, and it typically falls at the end of August. When the deadline passes, Play refuses new submissions that fall short, and shortly after, updates to existing apps are blocked too. The current exact figure is shown in Play Console, which is the authoritative place to check rather than a blog post.
How to update your app
Raise compileSdk and targetSdk together
Update your Gradle configuration so the app compiles against the new API and targets it. Compiling at the new level surfaces deprecations you must handle before they become runtime failures.
Work through behavior changes
Each Android release documents behavior changes in permissions, foreground services, notifications, storage, and more. Read the list for the versions you cross and test each affected flow on a real device.
Update dependencies
Libraries that predate the new target often break under it. Upgrade AndroidX, Play libraries, and any SDK that touches permissions or storage before you debug what looks like an app bug.
Test, then submit
Run the app through your normal test pass on current devices, then cut a release. Target API updates are exactly the kind of release that deserves a closed test before production.
Crossing a major target API level is the release most likely to break something subtle, from background work that stops running to permissions that behave differently. AppsTestLab runs the update through real-device testing before submission, which is where these behavior changes usually reveal themselves.
Frequently asked questions
Where do I see the current required target API level?
Play Console shows the requirement and flags your app when it falls short. Treat the console as the source of truth, since Google announces the exact cutoff separately for each Android release cycle.
Does raising targetSdkVersion drop old device support?
No. Device support is controlled by minSdkVersion. Raising the target changes behavior on modern devices and satisfies Play's acceptance rule, while minSdkVersion keeps or cuts older devices.
What if a library breaks when I raise the target?
Upgrade the library first, then look for app code. Most failures after a target bump come from dependencies built for an older behavior contract rather than from your own logic.
Sources & references
Official Google documentationThese links open Google's official Play Console Help pages used to verify this guide. AppsTestLab guidance is independent and not affiliated with Google.
Get help doing this