Google Play enforces a minimum target API level for apps, and if your app targets an API level below the current requirement, you cannot publish new apps or updates until you raise it. This catches many developers off guard, because targeting a recent API level is not just a checkbox — it means adopting the behavior changes, permission models, and restrictions of that Android version, which can require real work and testing. Because any app from a new personal account must also complete a closed test with at least 12 testers opted in for 14 continuous days before production access, this guide explains target API level requirements and how to validate compliance during your window.
The closed-testing process is the same regardless of API level, but meeting the target requirement introduces behavior changes you must test on real devices. Using your window to validate those changes turns the mandatory wait into confidence that your app behaves correctly under the modern Android rules Google enforces.
Two requirements, one launch
To publish, your app must both meet Google Play's target API level requirement and, for a new personal account, complete the 12-tester, 14-day closed test. See the closed testing guide. These are independent gates: one about which Android behaviors your app adopts, the other about real-world validation. Both must be satisfied, so address them together. Review Google's target API level policy for the current required level, which rises over time.
Standard advice applies: recruit committed, device-diverse testers, keep your count above 12, and prepare your listing in parallel. Use the window to specifically test the behavior changes that come with your target API level.
Target vs minimum API level
It is important not to confuse target and minimum SDK. Your minimum SDK is the oldest Android version your app supports and can run on; your target SDK declares the Android version your app is built and tested against, and it determines which runtime behaviors and restrictions apply. Google's requirement is about the target level: it must be recent (typically within a year of the latest Android release). Raising your target does not drop older users — you can keep a low minimum SDK while targeting a high level — but it does mean your app opts into the newer version's behavior changes on devices running it.
This distinction matters because raising your target is not about excluding old devices; it is about adopting new rules. When you bump your target API level, review the behavior changes Google documents for each version between your old and new target, since each can affect permissions, background execution, storage access, notifications, and more. Understanding this is the first step to a smooth compliance upgrade. See device and version testing.
Behavior changes to test
Each recent Android version has introduced behavior changes that a higher target enforces, and these are exactly what you must test. Notable areas include the runtime notification permission (Android 13+), scoped storage restricting broad file access, tighter background execution and location limits, stricter intent and package-visibility rules, foreground service type requirements, and various privacy and security tightenings. If your app relied on older, looser behavior, raising your target can break it in ways that only appear at runtime on a device running that Android version.
| Behavior area | What to verify |
|---|---|
| Notification permission | Requested correctly on Android 13+ |
| Scoped storage | File access works without broad permissions |
| Background limits | Background work still functions |
| Foreground services | Correct service types declared |
| Permissions & privacy | Prompts and restrictions handled |
Test these on devices running your target Android version, where the changes take effect. See notification permission testing.
Testing target-level compliance
The critical insight is that target API behavior changes take effect on devices running that Android version, so you must test on such devices, not just an old one where the changes do not apply. A bug from scoped storage or the notification permission may be invisible on an Android 11 device but break on Android 13+, so your testing must include current Android versions. This is where a device- and version-diverse closed test is invaluable: your testers on newer Android versions will exercise exactly the behaviors your higher target enforces, surfacing compliance issues before launch.
Systematically walk through the features that touch the changed behaviors — notifications, file access, background work, permissions — on devices running your target-level Android, confirming each works under the new rules. Fix anything that broke, and re-test. Because these issues are version-specific and often silent on older devices, real testers across current Android versions are the reliable way to validate compliance. See Android version behavior changes.
Setting up your closed-testing track
Once your signed release build, targeting the required API level, is ready, create a closed-testing track in the Play Console and upload it, add testers by email or Google Group, and share the opt-in link each tester must use before installing. Correct configuration matters because the 14-day clock counts only opted-in testers, and a misconfigured track is a common reason developers realize late that their timer never started. If your build does not meet the target requirement, the Console will flag it, so confirm compliance before you rely on the window. See how to create a closed testing track.
Give testers clear onboarding instructions and, ideally, ensure some run current Android versions so they exercise your target-level behavior changes. Every failed opt-in is a tester who does not count toward your 12, so smooth guidance maximizes active testers from day one and gives you the version coverage compliance testing needs.
Recruiting version-diverse testers
For target API testing, Android-version diversity is as important as device diversity, since the behavior changes only bite on newer versions. Recruit 12+ committed, device-diverse testers for 14 continuous days, aiming to include testers on the latest Android versions, keep a buffer above 12, and keep them engaged. Monitor your active count in the Play Console and recruit replacements early if it slips.
If assembling a version- and device-diverse group is your bottleneck, a service that supplies verified real testers across current Android versions solves it quickly. You can submit your app to get started, and read where to find real testers and how to keep testers engaged.
Making the 14-day window count
Because the requirement forces you to test anyway, use the window to validate that your app behaves correctly under the modern rules your target API level enforces. Have version-diverse testers exercise notifications, storage, background work, and permissions on current Android versions, and fix anything the new behaviors break. A well-run window turns a mandatory delay into confidence that you meet Google's target requirement in practice, not just on paper.
Enter production having confirmed your app runs correctly under your target level's behavior changes across current Android versions, and you avoid both the publishing block and the runtime bugs that catch unprepared developers. The 14 days are an investment in staying current with Android's evolving platform. See the testing checklist.
Turning tester feedback into fixes
Give testers a frictionless way to report problems and ask specific questions: did notifications work on your Android version, could you access or save files, did background features function, did any permission prompt behave oddly? Concrete questions, especially from testers on current Android versions, produce the actionable reports that reveal target-level compliance issues.
Then close the loop: when you ship a build addressing reported issues, tell testers what changed and ask them to reconfirm on their Android version. This validates fixes across versions and keeps testers engaged. An app that enters production having validated its behavior under the required target level launches compliant and correct on modern Android. See fixing crashes before production.
Use internal testing to check compliance early
The internal testing track is faster than the closed track, so use it to confirm your build meets the target requirement and behaves correctly on current Android versions before your counted 14-day window begins. Upload there, run the pre-launch report (which exercises current devices), and fix obvious behavior-change breakages first. Catching a scoped-storage or notification-permission bug privately, rather than during your closed test, prevents wasting days of your continuous window on a build that misbehaves on modern Android. See pre-launch report vs closed testing.
A practical rhythm is to validate each build's target-level behavior on the internal track and current-version devices, then promote it to the closed track where version-diverse testers confirm compliance broadly. See internal vs closed testing.
After launch: the target rises again
Your closed test validates today's target requirement, but the bar rises annually, so staying compliant is ongoing. Each year, Google raises the required target level, and you must update your app to keep publishing updates, which means adopting and testing the next round of behavior changes. Build the habit of tracking Android releases and Google's target requirements, and plan a compliance-and-testing cycle each year. An app that keeps pace stays publishable and modern; one that lets its target level lapse eventually cannot ship updates at all. See policy changes to watch and post-launch monitoring.
How to raise your target level safely
Raising your target API level is a code-and-test exercise, not just a manifest edit. Update your targetSdkVersion to the required level, then work through Google's documented behavior changes for every version between your old and new target, addressing each that applies to your app. Some changes require code updates — migrating to scoped storage, requesting the notification permission, declaring foreground service types — while others are handled automatically. Do this deliberately rather than bumping the number and hoping, because an unaddressed behavior change becomes a runtime failure on modern devices.
Once your code accounts for the changes, build and run on emulators and devices spanning the affected Android versions, exercising the features that touch each changed behavior. Treat the upgrade as its own testing effort feeding into your closed test: by the time your build reaches the closed track, it should already handle the new rules, and your version-diverse testers then confirm it across real hardware. This staged approach turns a potentially disruptive requirement into a controlled upgrade. See behavior changes by version.
Key takeaways
- Google Play requires a recent target API level — below it, you cannot publish.
- The 12-tester, 14-day requirement applies alongside the target requirement.
- Target differs from minimum SDK — raising your target does not drop old users.
- Test behavior changes — notifications, storage, background, permissions — on current Android versions.
- The target requirement rises yearly — plan an annual compliance cycle.
Frequently asked questions
What is the target API level requirement?
Google Play requires apps to target a recent API level (typically within a year of the latest Android release) to publish new apps or updates.
What is the difference between target and minimum SDK?
Minimum SDK is the oldest Android version you support; target SDK is the version you build and test against, determining which behaviors apply. The requirement is about the target.
Will raising my target drop older users?
No. You can keep a low minimum SDK while targeting a high level, so older devices still install your app.
Why does my app break when I raise the target?
Because a higher target enforces newer behavior changes — scoped storage, notification permission, background limits — that only take effect on devices running those versions.
Which devices should I test target compliance on?
Devices running current Android versions, where the target-level behavior changes take effect, not just older devices where they do not apply.
Does the target requirement change over time?
Yes. It rises annually, so you must periodically raise your target and test the new behavior changes to keep publishing updates.
Should I check compliance on internal testing first?
Yes. Confirm your build meets the target and behaves correctly on current versions via the faster internal track before your counted window begins.
How do I raise my target API level?
Update targetSdkVersion, then address every documented behavior change between your old and new target that applies to your app, and test on the affected Android versions.
Is bumping the target number enough?
No. The number opts you into new behaviors that can break your app at runtime, so you must handle each relevant behavior change and test it.
Can I get an extension on the target requirement?
Google sometimes offers limited extensions in specific circumstances, but you should plan to meet the requirement on time rather than rely on one.