Google Play's August 31 Deadline: What App Owners Need to Do
If you own an Android app that someone else built for you, you have until August 31, 2026 to get an update submitted that targets Android 16 (API level 36). This is not optional and it is not a suggestion from a blog. It comes from Google's own target API level requirements page, current as of August 2026, and it applies to every new app and every app update on Google Play.
Missing it does not delete your app. It does something quieter and, for most businesses, worse.
What the requirement actually says
From August 31, 2026, any app or app update you submit to Google Play must target Android 16, API level 36. Different form factors have different floors: Wear OS and Android Automotive apps target Android 15 (API 35), while Android TV and Android XR apps target Android 14 (API 34).
If you cannot make the date, Google's page says you can request an extension through Play Console that moves your deadline to November 1, 2026. That is a buffer, not a waiver. It buys ten weeks and nothing more, and it still requires someone with access to your Play Console account to go and ask for it before the end of the month.
What happens if you do nothing
Your app stays installed on every phone that already has it. Nothing is removed, and nothing stops working for your existing users. That is the part that makes this deadline easy to sleep through.
Here is the part that costs you. Google's page states that apps below the requirement will "stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level." New customers on newer phones stop finding you in the Play Store. The QR code on your packaging still resolves, but the listing behind it may not install. Your existing base slowly ages out while the replacement base never arrives.
You also lose the ability to ship. Once the deadline passes, you cannot publish an update that targets the old level, which means a bug fix, a price change, or a security patch is blocked behind the very migration you were putting off. If you are weighing whether an app is worth the ongoing commitment at all, our post on whether a small business actually needs an app is the more honest place to start than a rushed migration.
Why "just change the number" is not the work
The target API level is one line in a build file. Changing it takes seconds. What takes weeks is everything Android turns on the moment that number changes, because targeting a level is how an app tells the operating system it is ready for that version's rules.
Google documents these as behavior changes for apps targeting Android 16. Four of them are the usual suspects behind a migration that looks fine in a simulator and looks broken on a real phone:
- Edge-to-edge display is enforced. Apps can no longer opt out. If your layouts were written assuming the system bars reserve space at the top and bottom, your content now draws underneath the clock and the navigation gestures. This is the change most likely to make an otherwise healthy app look immediately wrong.
- Orientation and resize restrictions are ignored on large screens. On any display 600dp wide or larger — tablets and unfolded foldables — a portrait-only declaration no longer holds. An app built for one phone shape gets stretched into a shape nobody designed for.
- Predictive back is on by default. The older back-button callback is no longer invoked. Any custom handling of the back gesture, including the "are you sure you want to leave?" pattern on a checkout or a form, needs migrating to the newer API or it silently stops firing.
- Health sensor permissions are split apart. The single body-sensors permission is replaced by granular health permissions, and mobile apps using them must also declare a screen that displays a privacy policy.
Two of those have temporary opt-out flags, which is genuinely useful if you are up against the date. They are also explicitly temporary — the large-screen one is documented as lasting only until API level 37 — so an opt-out is a way to buy one release cycle, not a way to stop doing the work.
Realistically, a simple app with a well-maintained codebase is a few days of work plus device testing. An app that has not been touched in two years, or that leans on old third-party libraries which themselves need updating, is a different project. If nobody has opened your codebase since launch, assume the second case until a developer tells you otherwise.
Apple already did their version of this
If you have an iOS app too, that deadline has passed. Since April 28, 2026, Apple has required that anything uploaded to App Store Connect be built with Xcode 26 and the iOS 26 SDK, per Apple's own upcoming requirements page as of August 2026. If your last iOS submission predates that, you already cannot ship an update until someone rebuilds on the current toolchain.
The pattern is worth internalizing, because it repeats every year. Both stores set a moving floor, and an app that is not maintained does not sit still — it drifts below the line. Our guide to publishing to both stores walks the rest of that machinery, and this deadline is the maintenance half of the same story.
The next one is already dated: Google's 16 KB page size guidance says that from February 1, 2027, updates that do not support 16 KB memory page sizes cannot be released. That one only bites apps containing native C or C++ code, including native code inside third-party SDKs you may not know you have. Apps written purely in Kotlin or Java are already compliant.
What to do in the next two weeks
Ask whoever maintains your app three questions, in this order.
- What API level does our current release target? If the answer is 35 or lower, you are in scope. If nobody can answer, that itself is the answer.
- Can we submit an update targeting 36 before August 31, and what breaks when we do? You want a specific list, not reassurance. Edge-to-edge, large-screen layout, and back navigation are the three to name out loud.
- If not, has anyone requested the extension in Play Console? Ten weeks is worth having, and the request has to happen before the deadline rather than after it.
If you do not have a developer any more — the freelancer moved on, the agency folded, the contract ended — the useful thing to establish first is whether you hold the keys: the Play Console account, the signing key, and the source code. Without the signing key, an update cannot be published at all by anyone, and the fix is a new listing rather than an update. That is precisely why we hand over full code and store ownership on every build, and it is worth checking your own arrangement before you need it.
Where we are the wrong people to call
If your app is healthy and actively maintained, this is a routine ticket for the team that already knows the codebase. Handing it to a new agency means paying someone to learn your code before they fix anything, which is slower and more expensive than asking your existing developer to do it. Call them first.
We are a reasonable call in two situations: your app has been abandoned and needs someone to adopt it, or the migration surfaces that the codebase is old enough that rebuilding beats patching. Both are real, and the second is more common than app owners expect. You can see what a fixed-price build costs on our pricing page, sketch the scope in the app brief wizard, or book a free intro call and we will tell you honestly which of the two you are in.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
