Google Play Target API Level 2026: What to Do Before November 1

If your Android app has not shipped an update in a while, the Google Play target API level rules for 2026 probably apply to you, and the clock is short. Since August 31, every new app and update must target Android 16, and the extension Google offered for teams that needed more time ends on November 1, 2026. This guide explains what the rule actually requires, what happens to an app that misses it, what changes in your app when you target Android 16, and a realistic two-week plan to get compliant without shipping a broken release.

What the Google Play target API level rule says in 2026

Every Android app declares a targetSdkVersion: the Android version it was built and tested against. Google raises the minimum each year so apps pick up current privacy, security, and UI behavior. The official target SDK requirements for 2026 are:

• •New apps and app updates must target Android 16 (API level 36) or higher to be submitted, as of August 31, 2026.
• •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.
• •Other form factors have lower bars: Wear OS and Android Automotive OS apps need API 35, while Android TV and Android XR apps need API 34.

Teams that needed more time could request an extension to November 1, 2026. That is the date that matters now. After it, there is no further grace period announced, and any app still below the bar falls under the restrictions below.

What happens if your app misses the deadline

The most common misunderstanding is that Google deletes non-compliant apps. It does not. According to Google's Play Console help page, the consequences are narrower, but they still hurt a growing product:

• •New users on newer phones cannot find or install the app. If your app targets API 34 or lower, it is only offered to devices running that Android version or older. Since most new phones run current Android, your install funnel shrinks over time.
• •Store links show an error. Someone tapping your link from a newer device sees a message that the app "was made for an older version of Android".
• •You cannot ship updates until the new build targets API 36. That includes urgent bug fixes and security patches.
• •Existing users keep the app. People who already installed it can keep using and reinstalling it.

For a business, the update block is the real risk. The day you need to push a payment fix or respond to a security issue is the worst day to discover a target API migration standing in the way.

Does this apply to your app?

Almost certainly, if the app is publicly listed on Google Play. The only exemption Google lists is for permanently private apps restricted to users in a specific organization and intended only for internal distribution.

To check where you stand:

1. 1.Open Play Console and look at the Policy status page. Affected apps receive a warning there, and that warning is also where Google says the extension form lives.
2. 2.Check the latest release's target SDK in your app bundle explorer, or ask your developer to confirm the targetSdkVersion in the Android build config.
3. 3.Note which app versions your users actually run. If most of your traffic comes from people who installed long ago, you have more breathing room than an app that depends on fresh installs from ads or referrals.

If you inherited the app from a previous agency or freelancer and cannot answer these questions in ten minutes, that is useful information in itself: it usually means the build setup also needs attention.

What changes when you target Android 16

Changing the number is a one-line edit. The work is everything that number switches on. The Android 16 behavior changes that most often affect business apps are:

• •Edge-to-edge is enforced. The opt-out attribute that let apps avoid drawing behind the status and navigation bars is disabled for apps targeting API 36. Headers, bottom tabs, and floating buttons can end up under system bars if insets were never handled.
• •Predictive back is on by default. The system no longer delivers the old onBackPressed callback or KEYCODE_BACK. Custom back handling, such as "are you sure you want to leave this form?" prompts, needs migrating. A temporary opt-out exists, but it is a stopgap.
• •Large screens ignore orientation locks. On displays with a smallest width of 600dp or more, which covers most tablets and unfolded foldables, Android ignores portrait-only locks and aspect ratio limits. A phone-only layout gets stretched to fill the window.
• •Health and fitness permissions are more granular. Apps that read body sensor data move to the new health permissions and must show a privacy policy activity.
• •Some fixed-rate background tasks behave differently. Missed scheduled executions no longer all run at once when the app returns, which can surprise sync or reminder logic.

None of this is exotic, but each one can produce a release that passes review and then generates one-star reviews about overlapping buttons or a back button that closes the app.

A two-week plan to get compliant

With less than two weeks until November 1, here is the order we would work in:

1. 1.Day 1: Request the extension if you have not. It costs nothing and protects you if testing uncovers something larger. Do it from the Policy status page in Play Console.
2. 2.Days 1 to 2: Upgrade the toolchain. Raise compileSdkVersion and targetSdkVersion to 36, then update the Android Gradle Plugin, Kotlin, and any libraries that do not yet support API 36. Expect this to surface deprecated APIs.
3. 3.Days 3 to 6: Fix the behavior changes. Handle window insets on every screen, migrate back handling, and test layouts on a tablet or foldable emulator. Do not rely on the orientation opt-out property: Google notes it stops working once you target API 37.
4. 4.Days 7 to 9: Regression test the money paths. Sign-up, login, payments, push notifications, deep links, and anything that runs in the background. These break quietly.
5. 5.Days 10 to 12: Staged rollout. Ship to an internal or closed testing track first, then roll out to a small percentage of production users and watch crash reports before going to 100%.

If the app has not been touched in two or more years, add time. Jumping several Android versions at once means several years of behavior changes, not one.

React Native, Flutter, and Expo apps

Cross-platform apps are not exempt, and they add one wrinkle: the framework version decides how hard the jump is.

• •React Native: the target and compile SDK live in the Android Gradle config. Older React Native versions may not build cleanly against API 36, so the honest fix is sometimes a framework upgrade, not a version bump. Third-party native modules are the usual blocker.
• •Expo: newer SDKs set sensible Android defaults, and the expo-build-properties config plugin lets you set compileSdkVersion and targetSdkVersion explicitly. Very old Expo SDKs may need upgrading in steps.
• •Flutter: the default target comes from your Flutter SDK, so upgrading Flutter and its plugins is usually the first move, followed by checking edge-to-edge and back gesture handling in your widgets.

If you are still choosing a framework for a new app, our Flutter vs React Native comparison covers which one ages better for a small team. Annual platform updates like this one are part of the real cost of owning an app.

When to bring in help

Code Nativex regularly drops into existing codebases to ship one specific change, and target API migrations are a good fit for that: a clear deadline, a known checklist, and real risk if it is rushed. We start with a short, paid discovery to read the code and the build setup before committing to a scope, so you get a fixed price rather than an open-ended estimate. All work stays in your repository, and you keep full ownership of the code.

If you would rather stop treating platform deadlines as emergencies, an ongoing retainer covers these yearly updates before Google's notices arrive. You can see the full range of mobile app development services we offer, or read how we handled a similar time-boxed fix in our Next.js security patch guide.

The bottom line

The Google Play target API level rule will not delete your app, but missing it quietly cuts off new Android users and blocks every future update. Request the extension today, raise the target to API 36, and spend most of your time testing edge-to-edge layouts, back navigation, and large screens rather than the version number itself. Then put next year's deadline in the calendar: Google raises the bar every year.

If you want a developer to check your app's build and give you a fixed-price plan before November 1, request a quote and tell us which app and framework you are on.