What happens if your Android app doesn't target API 36 by 1 November 2026?

If your Android app doesn't target API 36 by 1 November 2026, Google Play won't delete it, and your existing users keep it. What you lose is the ability to publish updates of any kind until you raise the target. If the app also sits below API 35, it stops being available to new users on newer Android devices. So this is a slow loss of growth and of your ability to patch, not an overnight takedown. With five days left, you can still avoid most of it.

This post is for founders and operators who either hold an extension or have just spotted the warning in Play Console. It covers where you stand today, what changes on 1 November, and the order we would work in this week.

Five days left: where you stand on 26 October

The main requirement is already in force. Since 31 August 2026, Google's Play Console Help page has said that when you update your app, you must target Android 16 (API level 36) or higher. The 1 November date marks the end of the extension window. It is not the start of the rule.

Two bars, two consequences: API 36 and API 35

Newly's guide frames it well: there are two separate bars.

• API 36 decides whether Play accepts your upload. Below it, new apps and updates are refused, unless an extension is covering you until 1 November.
• API 35 decides whether new users on newer phones can see you. Google's wording is that an existing app targeting below Android 15 stops being available to new users on devices running a higher Android version than the app's target.

These bars apply to phones, tablets and Android Auto. Other form factors have lower bars: Wear OS and Android Automotive OS need API 35, and Android TV and Android XR need API 34. If you ship to several form factors, check each one separately.

What the 31 August date already changed

Many teams assumed updates would get a grace period beyond new apps. They don't. Newly points out that Google's requirements table prints the same 31 August date for both. So if you have no extension, you may already be unable to ship. Apollo's guide notes that an update targeting below 36 with no extension cannot be published, and that neither date has moved since late September.

The API 35 floor arrived in August 2025. That is why a neglected app first loses discoverability (for missing 35) and then loses the ability to update (for missing 36). If your app is still on API 34, you are already a year behind on the first bar.

What actually happens if you miss 1 November

Extensions end on 1 November. After that, Google's published guidance offers no further route to ship a build that targets below 36.

What existing users keep

According to Primetestlab's detailed write-up, missing the date does not delete your app, does not terminate your developer account and does not raise anyone's minimum Android version. People who installed your app keep it, on old phones and new ones. It keeps running, and so does whatever it connects to.

What you lose: updates and new-user discovery

The losses are quiet, which is what makes them dangerous.

1. No updates of any kind. That includes the urgent ones: a crash fix, a payment-provider change, a security patch. You may only discover the problem on the day you need to ship and can't.
2. No new users on newer Android versions, if you are below API 35. Your listing vanishes for them. Your install curve flattens, and nothing in your dashboards says why.

For an app that matters to the business, neither outcome is acceptable. The rest of this post is about avoiding both.

Targeting is not the same as minimum SDK

Clients confuse these two more than anything else, so let's be precise.

• minSdk is the oldest Android version your app will install on.
• targetSdk tells Android which version's behaviour rules your app has been tested against.

Raising targetSdk to 36 does not drop support for older devices. Users on older Android versions keep installing and running the app as before. What changes is how the app behaves on Android 16, because the operating system now applies Android 16's rules instead of compatibility shims.

android {    compileSdk = 36    defaultConfig {        // minSdk: leave this exactly as it was        targetSdk = 36    }}

That small change is the easy part. The behaviour changes it switches on are where the work sits.

Targeting 36 is a UI project, not a version bump

Effort estimates vary widely. Creuto describes days of focused work for most apps. Rapidlabs argues the extension window isn't enough to start a migration on an app nobody has touched in two years. Both can be true. In our experience it comes down to three things: how much your layouts assume the old window insets, how much you rely on orientation locks, and how stale your dependencies are.

Edge-to-edge with no opt-out

Android 15 enforced edge-to-edge drawing for apps targeting 35, but you could opt out with windowOptOutEdgeToEdgeEnforcement. For apps targeting 36, the Android Developers behaviour-changes page says that attribute is deprecated and disabled on Android 16 devices. It still works on Android 15, which is a trap. Your app can look fine on one test phone and broken on another.

Google's advice is to remove the attribute entirely, so the app handles edge-to-edge properly on Android 15 too.

<!-- Remove this from your theme. On Android 16 it is ignored anyway. --><item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>

Halodoc's migration write-up describes what this broke in practice: custom toolbars, sticky calls to action and floating buttons that relied on inconsistent fitsSystemWindows usage. Those are the elements that make or lose money (checkout buttons, booking bars), and they end up hidden under the status bar or the gesture area.

Orientation and resizability on large screens

On displays with a smallest width of 600dp or more, Android 16 ignores orientation, resizability and aspect-ratio restrictions for apps targeting 36. That covers tablets, open foldables and desktop-style windows. In practice, that means manifest settings such as screenOrientation, resizeableActivity="false" and min/max aspect ratio, plus setRequestedOrientation() calls in code.

The consequence goes beyond looks. Google's January 2025 post on these changes explains that orientation changes and resizing recreate the Activity by default. If your app doesn't preserve state, a user who rotates their tablet mid-form can lose everything they typed.

There is a temporary developer opt-out on Android 16, and Google's own timeline anticipates removing it at API 37. Our position: use it only to get a compliant build out this week if you must, and treat it as debt. Plan around it and you will be doing this work next year, under the same kind of deadline.

adb shell am compat enable UNIVERSAL_RESIZABLE_BY_DEFAULT com.yourcompany.yourapp

Google's launch post also lists other changes for apps targeting 36: predictive back needs migration or an explicit opt-out, elegantTextHeight is ignored, and fixed-rate work scheduling is optimised. The first matters most for anything with custom back handling, such as multi-step forms or in-app browsers.

SDKs, wrappers and build toolchain

Your own code is only part of the app. Creuto argues that outdated payment, analytics, maps and chat SDKs are the most common blocker. That is an opinion rather than a measured figure, but it matches what we see. An old SDK may draw its own screens that ignore insets, or may not build against compileSdk 36 at all.

Halodoc found that raising targetSdk and compileSdk to 36 across all modules also forced an upgrade of the whole build toolchain. Plan for that knock-on effect.

If your app is built with React Native, Flutter or a webview wrapper, you also depend on the framework and every plugin supporting Android 16. Median's coverage of wrapper apps shows these are affected just like native ones. Our breakdown of React Native versus native in 2026 explains why a framework's upgrade cadence belongs in that decision, not only development speed.

Your triage order for this week

With five days left, scope is everything. This is the order we would follow on a client app.

Check the live Play Console warning and extension status

Start with the facts in your own console, not in blog posts (this one included).

1. Confirm which bar you are failing. Is the app below 35, or between 35 and 36? Check each form factor you ship to.
2. Confirm your extension status. An extension is per app, only opens once Google has flagged the app as non-compliant, and isn't a permanent exemption. Google doesn't describe approval as automatic, so if a request is still pending, carry on migrating as if it will be refused.

If an agency or developer who has since moved on built the app, you may not even know where the signing key lives. Fix that before anything else. Our guide to auditing an inherited or unfinished app covers what to check first, starting with access, keys and build reproducibility.

What to test first

Once the target is raised and the app builds, test in order of commercial risk:

1. Insets on Android 16. Every screen with a top bar, bottom bar, floating button or sticky call to action. Use an Android 16 device or emulator, because Android 15 will hide the problem.
2. Tablets and foldables. Rotate and resize on every primary flow. Fill in forms halfway, rotate, and check nothing is lost.
3. Back handling. Multi-step flows, modals, in-app browsers and anything with custom back logic.
4. Third-party SDK screens. Payment sheets, login, maps and chat. You can't fix these in your own code.

Then submit, and leave room for review. Our notes on shipping to the App Store and Google Play explain how to plan releases so review time doesn't eat your last day. If you need hands on the work itself, our Android app development team handles migrations like this on fixed quotes with weekly delivery.

Do not schedule yourself into the next cliff

Google raises the target API bar every year, and the pattern repeats: a requirement date in late summer, an extension window, then a hard stop. Teams that treat it as a yearly emergency spend more and ship worse than teams that treat it as routine maintenance.

What we recommend to clients:

• Run an annual target-API upgrade as soon as each new Android version is stable, not when Play Console starts warning you.
• Keep dependencies current all year. A minor SDK update every quarter is far easier than a jump across three major versions in one week.
• Keep a short regression checklist for insets, large screens and back handling, so the next change is a test run rather than a discovery exercise.
• Track the next items on Google's calendar and verify them against official pages. Secondary sources mention 16 KB memory page-size support for future updates and changes to the Play Billing Library as upcoming requirements. Confirm the exact dates in Google's own documentation before you plan around them.

The 1 November deadline is real, but the bigger risk is the habit it exposes. An app nobody updates for a year is always one Google policy change away from going quiet.

If you are staring at a Play Console warning and aren't sure how deep the fix goes, talk to us about your Android app. We reply within 4 hours during UK business hours, give you a straight read on the work involved, and you own the code throughout.