From August 31, 2026, Google Play will not accept a new app or an app update unless it targets Android 16 (API level 36) or higher. That is the whole rule for phones and tablets. If your targetSdkVersion is still 34 or 35 after that date, the upload is rejected at submission time, which means you cannot ship a bug fix, a price change, or anything else until you migrate. You can request an extension to November 1, 2026 from inside Play Console.
The part that catches solo developers out is that bumping one number in build.gradle is not the migration. Setting targetSdk = 36 opts your app into a set of behavior changes that only apply to apps targeting API 36, and two of them (edge-to-edge enforcement and predictive back) will visibly break a normal app that was written for API 34. This post covers what the requirement actually says, what breaks, how long a realistic migration takes, and what to do if you are reading this with under a month to go.
What is Google Play's target API level requirement in 2026?
Google Play's 2026 target API level requirement is that new apps and app updates must target Android 16 (API level 36) or higher from August 31, 2026. Separately, existing apps must target Android 15 (API level 35) or higher to stay available to new users on devices running a newer Android version than the app targets.
Those are two different rules that people constantly merge into one, so it is worth separating them properly:
- The submission rule (API 36). Applies the moment you try to upload. Any new app or update to an existing app submitted on or after August 31, 2026 must target API 36. This is enforced by Play Console at upload, not by review.
- The distribution rule (API 35). Applies to apps already on the store that you never update. If your app targets API 34 or lower, it stays installable only on devices running an Android version at or below what you target. New users on newer phones see a message saying the app was made for an older version of Android and cannot install it.
Google runs this cadence every year: roughly one year after a stable Android release, that API level becomes the submission floor. Android 16 reached stable on June 10, 2025, so August 31, 2026 is the matching enforcement date. Nothing here is a surprise policy change, which is exactly why there is no sympathy in the process if you miss it.
What happens if you miss the August 31 deadline?
If you miss the deadline, your app is not removed from Google Play and existing users are not affected. What you lose is the ability to publish. Uploads that target below API 36 are blocked, so no updates, no fixes, no new releases. Apps still targeting API 34 or lower also become uninstallable for new users on newer devices.
The distinction between restricted and removed matters a lot if you are panicking. Nobody loses their app off their phone. Anyone who has already installed your app from Google Play can keep using it, reinstall it, and carry it to a new device. Your listing does not vanish and your reviews do not reset.
The real cost is being frozen. Once you cannot publish, every other problem becomes unfixable: a crash affecting a device you did not test on, a broken API key, an expired certificate on a backend you depend on, a policy warning that requires a metadata change. You are locked out of the one lever you have. That is a far worse position than spending two evenings on a migration now, and it tends to arrive at the worst possible moment.
Missing the deadline does not delete your app. It freezes it. Every future bug fix is blocked until you migrate, so the cost lands on the day you actually need to ship something urgent.
Which apps get a different deadline?
Phone and tablet apps must target API 36 from August 31, 2026. Wear OS and Android Automotive OS apps only need Android 15 (API level 35). Android TV and Android XR apps only need Android 14 (API level 34). Permanently private apps distributed only inside a specific organization are exempt from the requirement entirely.
Here is the full picture in one place, including the separate threshold that governs whether an existing app stays visible to new users on newer hardware:
| Form factor | New apps and updates (Aug 31, 2026) | Existing apps stay available if targeting |
|---|---|---|
| Phone and tablet | API 36 (Android 16) | API 35 or higher |
| Wear OS | API 35 (Android 15) | API 34 or higher |
| Android Automotive OS | API 35 (Android 15) | API 32 or higher |
| Android TV | API 34 (Android 14) | API 34 or higher |
| Android XR | API 34 (Android 14) | API 34 or higher |
If you ship a phone app that also has a Wear OS module, the phone module still has to hit API 36. The lower Wear OS floor does not pull your main app down with it. And if your app is a private, organization-only distribution, you are outside the requirement, but that applies to almost nobody publishing on the public store.
What actually breaks when you set targetSdk to 36?
Three changes break ordinary apps: edge-to-edge is enforced with no opt-out, so content draws under the status and navigation bars; predictive back is on by default, so onBackPressed() is never called and KEYCODE_BACK is not dispatched; and on screens 600dp wide or larger, orientation and resizability restrictions are ignored.
Take them one at a time, because each has a specific fix:
- Edge-to-edge enforcement. The
windowOptOutEdgeToEdgeEnforcementattribute that saved you on Android 15 is deprecated and ignored on Android 16. Your layouts must handle window insets themselves. In Compose that means using the insets APIs; in Views it means applyingWindowInsetsCompatpadding. Symptoms if you skip it: a toolbar sitting under the status bar clock, or a bottom button hidden behind the gesture bar. - Predictive back. Any custom back handling built on
onBackPressed()silently stops firing. Migrate toOnBackPressedDispatcheror theOnBackInvokedCallbackAPIs. There is a temporary escape hatch,android:enableOnBackInvokedCallback="false"in the manifest, which is fine as a deadline-day measure but should not be your permanent answer. - Large screen adaptive layouts. On displays with a smallest width of 600dp or more,
android:screenOrientation,android:resizeableActivity="false",minAspectRatio, andmaxAspectRatioare all ignored, as issetRequestedOrientation()at runtime. Apps markedandroid:appCategory="game"are exempt. Everyone else can set thePROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITYmanifest property as a temporary opt-out, but Google has said that escape hatch stops working at API 37, so it buys you one year, not a permanent pass.
Beyond those three, the smaller changes are worth a grep through your codebase. Health and fitness apps must replace BODY_SENSORS with granular permissions such as READ_HEART_RATE, and mobile apps that read health data must declare an activity showing a privacy policy or the permission gets revoked. ScheduledExecutorService#scheduleAtFixedRate() now runs at most one missed execution when the app resumes instead of all of them. MediaStore.getVersion() returns an opaque per-app string, so stop parsing it and only compare it for change. If none of those appear in your source, you are clear on them.
Do you still need to handle the 16 KB page size requirement?
Yes, and it is a separate rule with an earlier date. Since November 1, 2025, every new app and update submitted to Google Play that targets Android 15 or higher must support 16 KB memory page sizes on 64-bit devices. Pure Kotlin or Java apps already comply. Apps shipping native .so files must be rebuilt with aligned toolchains.
This one bites indirectly. You may have no native code of your own and still fail, because a dependency ships native libraries: a database engine, an image codec, an analytics SDK, a game engine, or a cross-platform runtime. Open App Bundle Explorer in Play Console and look at what native libraries your bundle actually contains, then check that each one comes from a version built for 16 KB alignment. React Native and Flutter have shipped compatible versions, and the major game engines have followed.
Google's stated numbers for why this exists are worth knowing, since they explain why the requirement is not going away: app launches 3% to 30% faster, roughly 4.5% better battery, camera startup 4.5% to 6.6% faster, and about 8% faster system boot on 16 KB devices. If your build fails the alignment check, Play Console blocks the release outright rather than warning you, which is the same failure mode as the target API check and one more reason not to leave both to the same afternoon. A clean pre-submission pass catches these before they cost you a release window, which is the whole point of the app pre-launch checklist for Google Play.
How do you request an extension to November 1, 2026?
Extensions are requested inside Play Console, not by email. Open the Policy status page, find the target API level warning or issue for your app, open its details page, and use the extension form linked there. An approved extension moves your deadline to November 1, 2026. There is no further extension beyond that date.
Two practical points. First, the form lives on the warning itself, so if you do not see a target API level issue listed for your app, you have nothing to extend and probably nothing to request. Second, an extension is nine extra weeks, not a reprieve. November 1 is a hard stop, and it lands right before the fourth-quarter period when you least want to be blocked from shipping.
Treat the extension as insurance for a migration that is genuinely underway and hitting a real blocker, such as an SDK vendor who has not yet published a 16 KB compatible build. Do not treat it as a way to defer starting. The failure pattern is predictable: request the extension in August, do nothing in September, and discover the edge-to-edge work in late October with a release you needed live yesterday. If you want a wider view of the console mechanics around all of this, the solo developer's guide to Play Console covers where these settings actually live.
How should a solo developer migrate in the time left?
Work in one order: bump compileSdk and targetSdk to 36 and fix compile errors, then handle edge-to-edge insets, then migrate back handling, then check native library alignment, then test on a large screen. Ship through internal testing first, then a staged production rollout. Budget two focused evenings for a small app.
A concrete sequence that works for a small codebase:
- Set
compileSdk = 36andtargetSdk = 36. Do these together and resolve whatever the compiler complains about before you run anything. LeaveminSdkalone, since the requirement says nothing about the minimum you support and lowering your reach helps nobody. - Fix insets. Run the app on an Android 16 device or emulator and look at every screen top and bottom. Anything tucked under the status bar or the gesture bar needs inset padding. This is usually the single biggest chunk of work.
- Migrate back handling. Search for
onBackPressedandKEYCODE_BACK. Move each one toOnBackPressedDispatcher. Then test the back gesture on every screen that has unsaved state or a custom dismiss. - Audit native libraries. Check App Bundle Explorer for
.sofiles, update any SDK that ships unaligned ones, and rebuild. - Test on a tablet profile. Launch on a 600dp-plus emulator and rotate. If your app assumed portrait forever, this is where you find out.
- Roll out in stages. Push to internal testing, which clears in minutes, then production at a small percentage. Watch crash rate for a day before going wider, and write the change up honestly in your release notes using the patterns in the release notes best practices guide.
One scheduling note that people forget: submitting on August 30 does not mean you are live on August 30. Review still takes time, and Google Play review runs from a few hours to seven days. If a compliant build gets rejected for an unrelated policy reason on August 29, you need enough runway to fix it and resubmit before the window closes. Give yourself at least a week of buffer, and know the common reasons Android apps get rejected so a routine rejection does not become a deadline miss.
Once the technical migration lands, the surrounding release work is the part worth automating. IOn Emit is a desktop app that handles the publishing side: managing your Google Play listing, checking store assets and metadata before you submit, keyword gap analysis against competitors, rank tracking, and a screenshot studio that outputs the right dimensions. It keeps the listing side clean so the only thing you are debugging in the last week of August is your own code. If the console itself is still the obstacle, publishing an Android app without fighting the Play Console covers the parts that trip people up.
The takeaway
The deadline is August 31, 2026, the requirement is API level 36 for new apps and updates on phones and tablets, and the penalty is being locked out of publishing rather than being removed from the store. An extension to November 1, 2026 is available through the Policy status page in Play Console, and that is the last date available.
The migration itself is small for most indie apps: bump the SDK, handle window insets, move off onBackPressed(), confirm your native dependencies are 16 KB aligned, and test on a large screen. Two evenings of work now, or a frozen app on the day you urgently need to ship a fix. The version of this that goes badly is always the one where somebody assumed changing one number in build.gradle was the entire job.