Google Play Target API Level Requirement: Why Did Your App Get a Warning?

You probably landed here after seeing a target API level notice in Play Console or in your inbox. Don't panic. Your app has not been removed. Start with these steps:

1. Open the Policy status page for your app in Play Console and read the full warning.
2. Write down the target API level your app uses today.
3. Check the current threshold and deadline on the official help page.
4. Confirm that you have access to the source code and to the developer who built the app.
5. If time is short, check whether an extension request is available.

In this guide, Talha Aslan and our team explain how the rule works, what the warning actually says, and how much work the update really involves. We verified the details on the Play Console Help page for target API level requirements. The thresholds change every year, so always check the current value on that official page.

What does target API level actually mean?

Every Android release has an API level number. The target API level (targetSdkVersion, the setting that tells the system which Android version your app was built and tested for) lives in your app's build file. In practice, it tells Android which version's rules your app follows.

Two settings often get mixed up here. First, the minimum level (minSdkVersion) decides the oldest Android version that can install your app. Second, the target level decides which new behaviors your app accepts. Therefore, raising the target level does not lock out older phones. Your app keeps running on older devices.

So why does Android need this setting at all? According to the Android Developers documentation, some new behaviors only apply to apps that explicitly target that version. As a result, old apps don't break overnight when a new Android version ships. However, that flexibility also slows down privacy and security improvements. That is why Google Play sets a floor for the target level.

In short, the target API level is a technical statement about how current your app is. Changing the number is easy. The real work is making sure the app behaves correctly under the new rules.

How does the Google Play target API level policy work?

In short, the Google Play target API level policy rests on a two-part time window. Google Play's target API level policy says that new apps and app updates must target an API level within one year of the latest major Android version release. Play Console blocks submissions that miss this bar.

For existing apps, the window is wider. Under the policy, apps that don't receive updates and don't target a level within two years of the latest major release become unavailable to new users on newer Android versions. In other words, your listing stays live, but someone who buys a new phone can't find it.

This window is not a fixed number. Instead, it moves. Each time a new Android version ships, the threshold climbs one step. Google describes this in its announcements as a regular yearly update. Consequently, an app that passes this year will get another warning next year if nobody touches it.

Wear OS, Android TV, Android Automotive OS and Android XR can have different thresholds from phone apps. Also, the official page lists permanently private apps, restricted to users in a specific organization and meant for internal distribution only, as an exception. Check the table on the help page to see which group you belong to.

How do new apps, updates and existing apps differ?

To read the warning correctly, you need to know which situation your app is in. The same rule leads to different outcomes in each case. The table below sums up the general framework of the official policy. For the exact API number and date, always rely on the official page.

The second row is the sneakiest one. We often see business apps run for years without a single update. Then an urgent bug appears. The developer prepares a fix, and then Play Console rejects the upload. Suddenly, a five minute fix turns into a compliance project that takes weeks.

The third row, on the other hand, causes a silent loss. Your current users won't notice anything. Still, new user acquisition shrinks a little more every month.

What is the warning email or Play Console notice telling you?

According to the official help page, only apps that don't meet the requirement receive policy warnings and notifications in Play Console. So if you saw the warning, your app really is at risk. The notice may reach you as a Play Console notification or as a similar message in the email inbox linked to your account.

In the warning, look for these details:

• Which app or package name it affects.
• Which target level the app uses today.
• The threshold you need to reach and the deadline.
• Whether an extension request is available.

The most reliable version of this information sits on the Policy status page in Play Console. The help article on checking your app's policy status explains that this page shows compliance issues and any active enforcement against your app. Instead of clicking the link in an email, we recommend that you sign in to Play Console yourself and open that page. That is because fake emails that imitate Google do circulate.

Also, don't just forward the warning to your developer. As the account owner, add the deadline to your own calendar. That way, the process doesn't depend on one person's memory.

What exactly happens if you miss the requirement?

The fear we hear most often is that the app will vanish from the store one morning. The reality is different. An existing app that misses the target level requirement stays on Google Play. However, its reach shrinks.

According to the official page, an outdated app stays available only on devices whose Android version is the same as or lower than the app's target level. Therefore, a user who has already moved to a newer Android version can't find your app when they search for it. Meanwhile, users who installed it before can still reinstall and use it.

Don't underestimate the business impact. Example scenario: a chain of hair salons promotes its booking app to new customers through the store. New phones hit the market every month, and they ship with the latest Android version. As a result, the pool of new users the app can reach quietly gets smaller over time. Even with the same ad budget, installs drop.

On top of that, the update door closes. If your payment provider changes, if a security flaw appears, or if you want to add a campaign screen, you first have to raise the target level. In other words, the real loss is that you can't move fast when it matters.

How can you find your app's current target level?

You don't need to open the code for this. In Play Console, the details for the app bundles you uploaded show the target SDK for each one. Menu names can change over time, so simply look at the app bundle or release details screen. The warning on the Policy status page often states the current value too.

If you have access to the source code, the value sits in the module level build file. The official Android documentation says you can set it in your build configuration or through the matching attribute in the manifest file. Ask your developer to send you this value and the date of the last build in writing.

We also want to flag a problem we see often. Some businesses don't know where their source code lives. The project may sit on the laptop of a freelancer who has since moved on. In that case, reading the target level is easy, but changing it is hard. First, clarify who holds the code and the signing key. We cover this in its own section below.

Put simply, your first day of work is simple. Collect the current value, the required threshold and the deadline in one note. The rest of the plan builds on those three facts.

How do you request a Google Play target API level extension?

When the threshold rises, Google usually offers a limited extension to developers who need more time. According to the official help page, you reach the extension form from the details page of the warning or issue on the Policy status page in Play Console. Affected apps also get the form link through Play Console notifications.

Follow this order for an extension request:

1. Sign in to Play Console and select the affected app.
2. Open the target API level warning on the Policy status page.
3. If the details screen shows an extension form link, open the form.
4. Write a short and honest reason; for example, explain that you are waiting for a third party library update.
5. If Google approves it, add the new deadline to your calendar and start the update plan right away.

That said, keep two things in mind. First, an extension is not a right, and it has a time limit; check the current extension date on the official page. Second, an extension doesn't remove the work. It only postpones it. So treat the extra time as working time, not waiting time.

Finally, never give a false reason on the form. Misleading Google creates a risk that can affect your account later.

What is the hidden cost of putting the update off?

For many businesses, a target level warning feels like a "we'll deal with it later" task. However, the longer you wait, the more the work piles up. The reason is simple. Every Android version in between brings its own behavior changes, and you end up handling all of them at once.

For example, picture two businesses. The first raises its app one step every year and reviews a few screens and permissions each time. The second doesn't touch its app for three years. Eventually, the second business has to fix the changes from several Android versions, outdated libraries and broken build tools all at the same time.

Another cost of waiting is lost knowledge. The developer who wrote the app moves on to other projects, the documentation gets stale, and the test devices disappear. Consequently, a new team needs extra time just to understand the code.

Lastly, don't forget the opportunity cost. While the update door is closed, you can't ship new features. Your competitor launches a new campaign screen while you fight build errors. That is why we treat the target level upgrade as a fixed item on the yearly maintenance calendar.

Why is raising the target level more than a one line change?

Technically, the target level is a number, and changing it takes a minute. The real work starts after that number changes. That is because a new target level means your app accepts the new Android rules.

When you raise the number, you usually run into three kinds of problems:

• Build problems: you may need to move build tools, plugins and libraries to current versions.
• Behavior problems: the app builds, but some screens, permissions or background tasks act differently.
• Layout problems: new system bars, screen edges or large screen rules can break your interface.

Build problems show up right away, because the compiler throws errors. Behavior problems are more dangerous. The app reaches the store and runs fine for a few days. Then you notice that notifications don't arrive or that the app never asks for location permission.

For that reason, always plan a target level update together with a test round. After the upgrade, watch your crash rate closely too. We cover the store's crash thresholds in our guide to app crash rate and store thresholds.

Which recent Android changes tend to cause trouble?

Google publishes a separate list of behavior changes for each Android version. With every upgrade, we read that list line by line and mark the items that affect the app. A few examples from recent versions show the scope of the work:

• For apps that target Android 15, edge to edge display became the default. Content can draw behind the status bar and the navigation bar.
• Android 15 also added a runtime limit for some foreground service types.
• Apps that target Android 16 can no longer opt out of edge to edge display.
• Predictive back animations are on by default once you target Android 16.
• On large screens, Android 16 ignores orientation and resizability restrictions, so your tablet layout may change.

Which items apply depends on the version you target. In other words, your list is the sum of every version between your current level and the target. Also, apps that come from before Android 12 face older changes too. Examples include explicitly declaring exported components and setting the mutability of pending intents.

In short, the change list looks like a technical document, but it touches the user experience directly. So read it together with your design team.

How can third party SDKs block the update?

An SDK (software development kit) is a ready made piece of code from another company that you add to your app. Most features such as payments, maps, analytics, ads and notifications come through these kits. When you raise the target level, these kits must also work with the new version.

The official Android documentation clearly recommends that you check whether third party SDKs support the new level before you upgrade. In our experience, this is where projects get stuck most often. For instance, a local payment provider's old kit won't build on the new level, and the provider hasn't released an updated version yet.

In that case, you have three options:

1. Wait for the updated kit and request an extension meanwhile.
2. Switch to another kit that does the same job and gets regular updates.
3. Move the feature to a web view for the time being.

The right choice depends on the kit's role and your contract. Either way, list your kits early. Also, if you change what data the kits collect, you may need to update your Google Play Data safety form as well. Otherwise, the update can get stuck for a different reason.

Is the process different for React Native or Flutter apps?

The rule is the same, but in practice the path differs slightly. Cross platform frameworks, the tools that build both iOS and Android apps from one codebase, manage the target level in their own templates and releases. Therefore, you may first have to move the framework itself to a current version.

For example, in an older project built with React Native, raising the target level often means upgrading the framework by several versions too. That, in turn, means checking every plugin against the new release. Flutter projects look similar. We discuss whether Flutter suits business apps in our Flutter guide.

Cross platform projects also have an advantage. Popular community plugins usually adapt to new Android versions quickly. However, rarely used or abandoned plugins can become a serious obstacle.

That is why we start with a plugin inventory no matter which framework you use. Replacing an abandoned plugin can be the most time consuming part of the job. In addition, it makes sense to bundle any pending iOS work into the same update round.

A step by step target level update plan

Below is the order our team follows when we handle a target level warning. If you work with your own developer, you can use this list as a roadmap.

1. Inventory: list the current target level, framework version, libraries and kits.
2. Gap analysis: read the behavior changes for every Android version between your level and the target.
3. Build setup: move build tools and plugins to current versions.
4. Code changes: apply the changes to permissions, notifications, background tasks and layouts.
5. Testing: try the main flows on both an older and the newest Android version.
6. Closed release: ship the version to an internal or closed testing track first.
7. Staged rollout: start production with a small share of users and watch the crash rate.
8. Wrap up: confirm that the warning has cleared from the Policy status page.

The step teams skip most often is the second one. Teams that jump straight to building without a gap analysis only learn about problems from user complaints.

During a staged rollout, you may want to nudge users on the old version to update. Our article on how to force an app update covers the right screens and flows for that.

What should you check during testing?

Testing a target level update also differs from testing a normal release. Even if you write no new code, the system treats your app differently. So run through the list below on at least one older and one current Android device:

• Which permissions does the app request on first launch, and what happens when the user denies them?
• Do notifications arrive both while the app is open and while it is closed?
• Do location, camera and gallery access work as expected?
• Does any content hide under the status bar or the navigation bar?
• Do the back gesture and the back button return to the right screen?
• Does the layout hold up on a tablet or foldable device?
• Do flows that involve money or data, such as payment, sign in and booking, work smoothly?

Also test scenarios such as denied permissions, battery saver mode and the app sitting in the background for a long time. The official documentation likewise recommends testing permission denial and power management modes.

When you finish, record the results in a short note. Next year, you can reuse the same list, and the job will go faster.

Example scenario: how do you update an old booking app?

This is not a real client case. Instead, it is an example scenario that reflects a pattern we see often. A dental clinic chain had a booking app built years ago. The app works, but it hasn't had an update in several years. When the clinic wants to add a new branch screen, Play Console rejects the upload.

As a result, the first review reveals three problems. First, the app's target level is several versions behind. Second, the notification kit it uses won't build on the new version. Third, appointment reminders rely on a background task whose timing changes under the new rules.

For a scenario like this, we split the work into two waves. In the first wave, we handle compliance only: build setup, kits, permissions and layout. In the second wave, we add the new branch screen. After that, we go to production with a staged rollout.

Here is why we split it. If you put compliance and a new feature in the same release, it gets harder to trace the source of any bug. So two separate releases take a little longer, but they cut the risk considerably.

Why does a maintenance contract solve this problem up front?

The target level warning is the clearest sign that a mobile app is never a one time project. Android ships a new version every year, and Google Play raises the threshold every year. That calendar won't change. Consequently, your app needs a yearly maintenance rhythm too.

These are the clauses we look for in a good maintenance contract:

• It states clearly that the yearly target level upgrade is in scope.
• The developer updates kits and libraries on a set schedule.
• It defines how many business days it takes to respond to a policy warning.
• It confirms that the source code, signing key and store account access stay with your business.
• The developer delivers a short test report after every update.

We build your app, we publish it to the store, and then we take care of that maintenance rhythm too. If you want a quote for a target level update on your current app or for a new project, reach out through our mobile app development service page.

Without a maintenance contract, the warning lands as a surprise every year. With one, it becomes a calendar item.

What should you do if your developer has disappeared?

Many businesses that receive a target level warning can no longer reach the person or company that built their app. In that case, the first question is where the source code lives. Without the code, you can't raise the target level. Instead, you would have to rebuild the app.

Next comes the signing key. If you use Play App Signing, Google stores the app signing key and you only work with the upload key. If you lose the upload key, you can request a reset through Play Console. However, if an older project never set this up, the process gets harder.

At this point, we want to warn you against shortcuts that break the rules. Deleting the current app and publishing a new one under a different package name costs you your users and reviews. Using someone else's developer account goes against Google's rules and puts your account at risk.

If your app faces enforcement such as removal or suspension, the situation is different. For that scenario, our article on a Google Play app removed for a policy violation is a better starting point.

A final checklist before you publish

Before you send the new version to production, tick off every item below. This list lowers the risk that your first upload gets rejected.

1. The target level meets the current threshold on the official page.
2. The app passed its main flows on at least one older and one current device.
3. All kits run on versions that support the new level.
4. Permission explanations and the privacy policy are up to date.
5. The Data safety section matches the data the new kits collect.
6. Your store description and screenshots reflect the new interface.
7. The staged rollout percentage and a rollback plan are ready.

However, the store review can also stop you for reasons unrelated to the target level. If a rejection follows your upload, our article on the most common reasons apps get rejected lists the usual suspects. That way, you avoid making the same mistake twice.

In the first week after release, check crash reports and user reviews every day. Side effects of a target level change usually show up during that first week.

When should you take each step after a Google Play target API level warning?

A Google Play target API level warning is a reminder, not a penalty. If you act at the right time, your app stays live without interruption. In short, your timeline should look like this:

• The week the warning arrives: note the current level, the threshold and the deadline, then confirm code and account access.
• The first month: finish the inventory and gap analysis, and identify kit issues.
• Before the deadline: test the update and start a staged rollout.
• If time runs short: request an extension if the form is open, and keep working.
• Every year: add the upgrade to your maintenance calendar ahead of the next Android release.

If you see this as a regular maintenance routine instead of a one time fire drill, the warnings won't catch you off guard again. Our team can run the compliance update, the test round and the store release for you from start to finish. To review your app's situation together and get a quote, just fill out the form on our mobile app development page.

One last reminder: the threshold windows in this article describe the general framework of the official policy. Before you change anything in your app, always check the current API number and date in Play Console Help.