Since August 31, 2026, Google Play has required every new app and every app update to target Android 16 (API level 36) or higher before it can be submitted. That is the whole rule for phones and tablets. If your targetSdkVersion is still 34 or 35, you cannot ship a bug fix, a price change, or anything else until you migrate, unless you have an extension. Google's Play Console Help says you can request one to November 1, 2026 from the Policy status page, which as of today (October 5, 2026) leaves under four weeks.
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. 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 it does to apps you don't update, what breaks, and what to do with the time left.
What is Google Play's target API level requirement in 2026?
Starting August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play. Separately, existing apps must target Android 15 (API level 35) or higher to remain 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 publish. Any new app, and any update to an existing app, must target API 36 to be submitted. An approved extension pushes this to November 1, 2026.
- The distribution rule (API 35). Applies to apps already on the store, whether or not you update them. If your live app targets API 34 or lower, Google says it "will stop being available to all new users whose devices run Android OS versions higher than your apps' target API levels." New users on older Android versions can still find and install it.
Android 16 was released on June 10, 2025, so the API 36 requirement arrived a little over a year later. The pattern was the same in 2025, when Google's July 10, 2025 policy announcement set August 31, 2025 as the date for new apps and updates to target Android 15 (API level 35).
What does "update your target API level by August 31" mean?
It refers to Google Play's yearly target API level deadline. For 2026, new phone and tablet apps and app updates had to target Android 16 (API level 36) by August 31, 2026. In 2025 the same date applied to Android 15 (API level 35). Play Console shows target API warnings, and the extension form, on the Policy status page.
If you are reading this because that warning is still showing, the deadline itself has passed. What you can still do, according to Google's help page, is request the extension to November 1, 2026 if you have not already, and use that window to finish the migration below. If you already have the extension, November 1 is your real deadline.
What happens to existing apps after the deadline?
Existing apps are not removed. Google says users who previously installed the app from Google Play can still discover, re-install and use it. What changes depends on your target: an app targeting API 35 stays available to everyone, while an app targeting API 34 or lower stops being available to new users on newer Android versions.
So an app sitting on API 35 that you never touch again keeps its full audience for now. It is only blocked from receiving updates until you move to API 36. An app on API 34 or lower loses more. New users whose phones run a newer Android version than the app targets can no longer get it. That quietly cuts off a growing share of new installs. In both cases, your listing does not vanish and your reviews do not reset.
What happens to updates if you miss the deadline?
Updates are where the deadline bites. Without an extension, a new release that targets below API 36 cannot be submitted to Google Play, so no bug fixes, no policy fixes and no new features. With an extension, you can keep submitting until November 1, 2026. After that, an API 36 build is the only way to ship.
The real cost is being frozen. Once you cannot publish, every other problem becomes unfixable. Think of a crash on a device you did not test on, a broken API key, an expired certificate on a backend you depend on, or a policy warning that requires a change. You are locked out of the one lever you have, 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 restricted to users in a specific organization and intended for internal distribution only are exempt.
Here is the full picture in one place. It includes the separate threshold that decides whether an existing app stays available to new users on newer Android versions:
| 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 33 or higher (see note) |
| Android XR | API 34 (Android 14) | API 34 or higher |
One note on Android TV. Play Console Help says an existing TV app targeting API 33 is compliant. The developer.android.com version of the same requirement lists API 33 or lower as restricted for TV. Targeting API 34 satisfies both, and it is the level you need for any TV update anyway. If you are working on a TV app, our guide to why Android and Android TV apps get rejected covers the separate TV quality review.
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.
What actually breaks when you set targetSdk to 36?
Three changes break ordinary apps. First, edge-to-edge is enforced with no opt-out, so content draws under the status and navigation bars. Second, predictive back is on by default, so onBackPressed() is not called and KEYCODE_BACK is not dispatched. Third, on screens 600dp wide or larger, orientation, resizability and aspect ratio restrictions are ignored.
Take them one at a time, because each has a specific fix:
- Edge-to-edge enforcement. For apps targeting API 36, the
windowOptOutEdgeToEdgeEnforcementattribute that saved you on Android 15 is deprecated and disabled. 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. The predictive back system animations are enabled by default, and any custom back handling built on
onBackPressed()silently stops firing. Migrate toOnBackPressedDispatcheror theOnBackInvokedCallbackAPIs. Google documents a temporary opt-out,android:enableOnBackInvokedCallback="false"on the<application>or<activity>tag, 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,
screenOrientation,resizableActivity,minAspectRatioandmaxAspectRatioare ignored, as aresetRequestedOrientation()andgetRequestedOrientation(). Games, identified by theandroid:appCategoryflag, are exempt. Everyone else can declare thePROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITYproperty on an activity as a temporary opt-out. But Google says it won't apply when targeting API level 37, so it buys you one cycle, not a permanent pass.
Beyond those three, the smaller changes are worth a grep through your codebase. Apps that use BODY_SENSORS must switch to the granular android.permissions.health permissions such as READ_HEART_RATE, and mobile apps migrating to them must declare an activity that shows the app's privacy policy, or the permission is revoked. ScheduledExecutorService#scheduleAtFixedRate() now runs at most one missed execution when the app returns to a valid lifecycle, instead of all of them. MediaStore.getVersion() is now unique to each app, so stop parsing it. 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, but it is a separate rule with its own date. Google says apps targeting Android 15 or higher must support 16 KB memory page sizes on 64-bit devices, and from February 1, 2027, updates that don't support 16 KB pages can't be released. Pure Kotlin or Java apps, including all their libraries, already comply.
This one bites indirectly. You may have no native code of your own and still fail, because a dependency ships native .so libraries. Common ones are a database engine, an image codec, an analytics SDK, a game engine, or a cross-platform runtime. Android Studio warns you about prebuilt libraries that aren't 16 KB compliant, and the APK Analyzer's Alignment column flags the specific files. Update each SDK that ships unaligned libraries and rebuild. Play Console also shows a compatibility warning for affected releases.
Google's stated reasons are worth knowing, since they explain why the requirement is not going away. On 16 KB devices, Google measured app launch times 3.16% lower on average under memory pressure (up to 30% for some apps). Power draw during app launch was 4.56% lower. Camera hot starts were 4.48% faster and cold starts 6.60% faster, and system boot was about 8% faster. Fixing alignment now, while you are already touching the build for API 36, is cheaper than a second migration before February. The app pre-launch checklist for Google Play covers the other checks worth running in the same pass.
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. Google's help page does not mention any extension beyond that date.
Two practical points. First, the form lives on the warning itself, so start from the Policy status page rather than searching help pages for a form. Second, an extension is a short window, not a reprieve. From today, November 1 is under four weeks away, 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 that has not yet shipped an API 36 compatible build. Do not treat it as a way to defer starting. 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. - 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 your build for
.sofiles with the APK Analyzer, 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, then production at a small percentage (our guide to staged rollout percentages covers which numbers to pick). 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.
We went through this ourselves this month: the updates for IOn Sleep and IOn Reclaim, our own Android apps, now target API 36.
One scheduling note that people forget: submitting is not the same as being live. Play Console Help says review can take a few hours or up to seven days, and longer in exceptional cases. Our guide to how long Google Play app review takes goes into the detail. If you are on an extension, a compliant build that gets rejected for an unrelated policy reason in late October needs enough runway to be fixed and resubmitted before November 1. 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. If this is a brand-new app on a personal developer account, remember the separate 12 testers closed testing requirement before you can reach production at all.
Once the technical migration lands, the surrounding release work is the part worth automating. IOn Emit is a Windows desktop app for the publishing side of Google Play: managing your listing and checking store assets and metadata before you submit, in the free tier, with keyword gap analysis, rank tracking and Screenshot Studio in Pro. It keeps the listing side clean so the only thing you are debugging before November 1 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
Since August 31, 2026, new apps and updates for phones and tablets must target API level 36 to be submitted to Google Play. Existing apps are not removed. Those on API 35 stay available to everyone but cannot be updated until they move to API 36. Those on API 34 or lower also stop reaching new users on newer Android versions. An extension to November 1, 2026 is available through the Policy status page in Play Console, and Google's help page lists no later date.
The migration itself is small for most indie apps. Bump the SDK, handle window insets, and move off onBackPressed(). Confirm your native dependencies are 16 KB aligned before February 1, 2027, 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.
This post is part of our app publishing guides for indie Android developers.