Google Play's target API 36 requirement took effect on August 31, 2026, three weeks before this was published. If your app hasn't moved yet, that's a compliance gap today, not a countdown. This covers where an app stands right now depending on what it targets, what actually happens to apps sitting below the bar, and what the November 1, 2026 extension still buys a team that's behind.
What Google Play actually requires now
New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play, effective August 31, 2026. That part is a hard floor: miss it, and the Play Console won't accept the upload. Existing apps get a lower bar. They need to target Android 15 (API level 35) or higher just to stay available to new users, according to Google's target API level requirements page, last updated September 16, 2026.
Those are two different numbers for two different situations, and mixing them up is the easiest way to misjudge your own exposure. An app you haven't touched since 2024 might still be fine on the existing-app floor of API 35, even though a fresh submission of that same app today would need API 36.
The floor is different for Wear OS, Android Automotive OS, Android TV, and Android XR
Phone and tablet apps aren't the only ones on the clock. Google runs a separate new-submission floor and existing-app floor for each form factor, and they don't all match the phone/tablet numbers.
| Form factor | New apps/updates must target | Existing apps stay available if targeting |
|---|---|---|
| Phone/tablet | Android 16 (API 36) | Android 15 (API 35) or higher |
| Wear OS | Android 15 (API 35) | Android 14 (API 34) or higher |
| Android Automotive OS | Android 15 (API 35) | Android 12L (API 32) or higher |
| Android TV | Android 14 (API 34) | Android 14 (API 34) or higher |
| Android XR | Android 14 (API 34) | Android 14 (API 34) or higher |
The Wear OS and Automotive existing-app floors come from Google's Play Console compliance answer on target API requirements, which spells out those two thresholds directly rather than leaving them as a general cutoff.
Three of these five rows use a lower number for existing apps than for new submissions. Phone/tablet drops one level, from 36 to 35. Wear OS drops one level, from 35 to 34. Android Automotive OS drops the furthest: a new Automotive submission needs API 35, but an existing Automotive app only needs API 32 to stay available to new users, a three-level gap. Only Android TV and Android XR use the same number in both columns. If you're assuming the new-submission number applies everywhere, Automotive is the row that breaks that assumption hardest.
One more thing worth getting right: Android Automotive OS is the embedded, in-car operating system built into the vehicle's own display. It's not Android Auto, the app that projects your phone's screen onto a car's head unit. They're different products with different codebases, and only Automotive OS shows up in Google's target-API table. If your team ships an Android Auto integration and nothing that runs natively in-car, this table doesn't apply to you at all.
What actually happens if an app misses the bar
Here's Google's exact wording: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level." Apps that fall below the floor for their form factor "will only be available on devices running Android OS that are the same or lower than your app's target API level."
Read that carefully, because it's narrower than the version that tends to circulate. An app below the bar doesn't get pulled from Google Play. The listing itself stays up, and it doesn't get uninstalled from any device that already has it. What changes is who can install it fresh: a user on a phone running a newer Android version than the app's target can no longer install it. A user on an older or matching OS version still can. Existing installs keep working, keep updating, keep everything they had before August 31.
That distinction matters for how urgently you treat this. "My app got removed from the Play Store" is a five-alarm fire. "New users on newer phones can't install my app until I bump the target SDK" is a real problem with a known fix, and it's the one that's actually happening.
How to catch up if you're behind on the August 31 bar
If nobody on your team owns Android full-time, this is usually the point where the gap gets found, days or weeks after it started costing installs. Bringing in a dedicated Android developer to own the migration beats splitting the work across whoever's free that sprint.
1. Check what your app currently targets and who it's blocking
Pull targetSdkVersion from your current production build and check it against the table above for your form factor. Because the consequence only bites for new users on devices running a newer OS than your app's target, your actual exposure depends on your install base's OS distribution. Check that breakdown in Play Console before you fix anything, so you know how many devices are already locked out.
2. Decide: full API 36 bump now, or the extension to November 1
Google's policy gives developers who need more runway the option to request an extension pushing the deadline to November 1, 2026, through extension forms in Play Console. But there's a catch worth being precise about: Google's own page says developers "will be able to access" those extension forms "later this year." As of the page's last update on September 16, 2026, and as of today, that's a future promise, not a live button. If you go looking for the extension request form in Play Console right now, don't be surprised if it isn't there yet. Plan around the November 1 date, but don't assume the request mechanism is already open.
If the bump is straightforward and you just need hands on it fast, it's often quicker to get a shortlist of vetted mobile engineers in 72 hours than to wait on the extension process to clarify itself.
3. Bump targetSdkVersion and handle Android 16 behavior changes
Update targetSdkVersion, update any libraries or SDKs that pin to an older target, and test against Android 16's behavior changes before you resubmit. This is standard SDK migration work, but it's rarely a one-line change once you factor in third-party dependencies that haven't caught up yet. While you're in the build anyway, it's worth checking whether Android 17's per-app memory limits affect you too, since it's a separate rollout hitting the same codebase around the same time.
4. Resubmit and monitor availability by OS version
Push the updated build to Play Console and watch whether availability comes back for the OS versions that were previously blocked. This closes the loop on step 1: if your OS distribution showed a chunk of your install base locked out, confirm that number drops after the update goes live.
FAQ
Does this mean my app was removed from Google Play?
No. Your app stays listed on the Play Store and existing installs are untouched. The rule only blocks new installs on devices running a newer Android version than your app's target. Nothing about this rule pulls a listing or uninstalls the app for anyone who already has it.
What if my app targets Android 15 already?
You're fine on the existing-app floor for phone and tablet, and this rule change doesn't affect your current listing. The catch is your next submission: any new update to that app still needs to target Android 16 (API 36) to clear Play Console's upload check.
Can I still get more time after August 31?
Google's policy allows it: an extension to November 1, 2026, requested via Play Console's extension forms. The one thing to hold loosely is timing on the request mechanism itself: Google's page says developers will be able to access those forms later this year, without a firmer date attached as of its September 16 update.
Does the requirement apply the same way to a Wear OS or Android Automotive OS app?
No. Each form factor carries its own new-submission floor and existing-app floor, and they're not interchangeable with the phone/tablet numbers. Wear OS and Automotive both have a lower existing-app floor than new-submission floor, same as phone/tablet, but Automotive's gap is the widest: a new Automotive submission needs API 35, while an existing Automotive app only needs API 32 to stay available, a three-level spread.