Google Play's August 31 Deadline Does Not Delete Your App. It Makes It Invisible to Every New User on a Modern Phone.
Google Play's target API level deadline lands on August 31, thirteen days from today, and almost every summary I have read describes the consequence as apps being pulled from the store. That is not what the policy says. Nothing gets removed. Your listing stays up. Everyone who already installed your app keeps it and can reinstall it.
What happens instead is that your app stops being discoverable to new users whose devices run a newer Android version than your app targets. That is a growth problem, not an existence problem, and the difference changes whether this is worth your weekend.
I have one small Android app that still earns a little. I spent an hour on the actual policy text rather than the coverage, and the useful finding is that there are two separate numbers here, not one.
Two requirements, two API levels
This is the part the summaries flatten, and it is where people make bad decisions.
To stay available to new users, an existing app must target Android 15 (API level 35) or higher. If it targets API 34 or lower, it will only be available on devices running an Android version equal to or lower than what the app targets.
To submit anything at all after August 31, whether a brand new app or an update to an existing one, you must target Android 16 (API level 36) or higher.
So if you are sitting on API 34 today, the fix is not "get to 35." Getting to 35 makes you visible again but leaves you unable to ship an update, because updates submitted after the deadline need 36. You are going to 36 either way. Anyone planning a minimal hop to 35 is doing the work twice.
The other form factors have their own numbers. Wear OS and Android Automotive OS need API 35 or higher for new apps and updates. Android TV and Android XR need API 34 or higher. If you only ship a phone app, ignore all of that.
What a user actually sees
Google published a description of the failure mode, and it is worth picturing because it tells you where the damage lands.
Someone on a newer device follows a link to your Play Store page. Instead of an install button they get told the app is not available to install on their device because it was made for an older version of Android. That is it. No error, no crash, no removal notice to you beyond the policy warning in Play Console.
Your existing users see none of this. They keep the app, they can find it, they can reinstall it, on any Android version your app supports. The deadline hits acquisition only.
Which means the honest way to size this risk is to open your Play Console stats and answer one question: how many installs in the last 90 days came from devices running an Android version newer than your target? If the answer is most of them, this is urgent. If your app is aimed at older hardware or a market running older OS versions, the immediate bleed is smaller than the panic suggests, though it grows every month as devices turn over.
The extension is real, and it is narrower than people think
You can request an extension to November 1, 2026. That is nine extra weeks, which for a solo developer with a day job is the difference between rushing a migration and doing it properly.
Two details matter. The extension form appears on the Policy status page in Play Console, reached through the details of the warning or issue, and it only shows up for apps that are actually non-compliant. If your app is fine you will never see it, which is correct but confusing if you go hunting.
Also worth noting: Google's own help page says the extension forms would become available in Play Console "later this year," phrasing that has been on the page since it was last revised. If you are counting on the extension, go look for the form now rather than on August 30.
There is one genuine exemption, and it is narrow: permanently private apps restricted to users in a specific organisation and intended for internal distribution only. If you are shipping an internal tool to one company through managed Google Play, this does not apply to you.
What I would actually do
If your app targets API 35 already, you are compliant for availability. You still need 36 for your next update, so fold the target bump into whatever you ship next rather than treating it as its own project.
If your app targets 34 or lower and still makes money, go straight to 36. Skip 35. Budget more time than the version bump suggests, because the cost is never the manifest line, it is the behaviour changes each Android version brings and the testing to find what broke. Read the migration guide for each version you are jumping across, not just the destination.
If your app targets 34 or lower and makes nothing, this is a good forcing function to make a decision you have probably been avoiding. Either it is worth a weekend or it is not. If it is not, you can leave it, and it will quietly stop reaching new users while continuing to serve everyone who has it. That is a legitimate choice and nobody will send you an angry email about it. The alternative, if you want to stop serving it entirely, is to unpublish deliberately rather than let it decay.
The thing I would not do is request the extension as a default. Nine weeks of runway on a task you have not started is how a September problem becomes an October problem. Ask for it if you have a specific plan that needs the time.
Where I could be wrong
I am arguing this is less dramatic than the coverage claims, and there is a fair counter: for an app whose growth comes entirely from Play Store search, losing discoverability on modern devices is close to a death sentence over a year, even if nothing is deleted on day one. Slow invisibility can be worse than a fast removal because it does not force you to react. I think that is right, and it is the strongest argument for treating this as urgent even though the mechanism is gentle.
The second thing I could be wrong about is the two-number reading. I am confident in it because the policy page states the new-app-and-update requirement (API 36) and the availability requirement (API 35) in separate sections with separate tables. But Google's help pages get revised, and the version I read is the version I read. Check it yourself before you plan around it, and check the Policy status page in your own console, which is authoritative for your specific app in a way that any blog post is not.
Author
Lukas
@lukcombinator