Google Play Target API Level Requirement: How to Move to API 36 and Unblock Your Updates

What the target API level requirement says (as of October 2026)

This isn't a reviewer's judgment call. Play Console checks it automatically when you upload a bundle or roll out a release. Your targetSdkVersion tells Android which version's behavior your app was tested against, and Google raises the minimum every year so apps pick up newer security and privacy protections.

The current rules took effect on August 31, 2026. Here they are, from Google's Play Console Help page and the Android Developers requirement page:

The two official pages disagree on the existing-app threshold for Android TV, so if you ship a TV app, go by what your app's Policy status page shows. Either way, there are two separate consequences:

• Blocked releases. If your build doesn't meet the threshold, you can't publish a new app or an update. Your current version stays live.
• Shrinking reach. An existing app below the "existing apps" level stops being available to new users whose devices run a newer Android version than your target. Google says people who already installed it can still find it, reinstall it and use it on any Android version the app supports.

Google offers an extension to November 1, 2026 through a form in Play Console. The only permanent exception is for permanently private apps that are limited to users in one organization and meant only for internal distribution.

Why your upload or update is blocked

The error usually shows up the moment you upload an AAB or try to send a release for review. The usual causes:

• The target was never raised. targetSdk is still 34 or 35 because last year's migration was the most recent one.
• A hidden override. defaultConfig says 36, but something else wins: a product flavor that sets its own targetSdk, a shared convention plugin or version catalog entry, or a build script that never sets targetSdk at all, so a leftover android:targetSdkVersion in AndroidManifest.xml is used.
• A framework default. Flutter, React Native and Capacitor each set their own value, and an older framework version resolves to an older API.
• The wrong artifact. CI built from an old branch or cache, or someone uploaded a local AAB by hand.
• The extension ran out. An extension only moves the deadline to November 1, 2026. After that date, the block applies to you too.
• Old releases on other tracks. Check which version codes and tracks the Policy status issue lists. In practice, an old build that is still active on a testing track can keep a warning open.
• A related check. Google Play requires apps targeting API 35+ to support 16 KB memory page sizes on 64-bit devices, so a fixed target can surface a native-library alignment warning next. As of October 2026, Google's page-size guide says updates without 16 KB support can't be released starting February 1, 2027. AGP 8.5.1+ and NDK r28+ handle alignment by default, but prebuilt native SDKs must be 16 KB-compatible too.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix it: migrate to API 36 step by step

The version bump takes one line. Most of the work is dealing with the behavior changes that come with it. Do this on a branch and plan time for testing.

1. Update your tooling. Google's AGP compatibility table lists Android Gradle Plugin 8.9.1 and Android Studio Meerkat (2024.3.1 Patch 1) as the minimum for API 36. AGP 9.x is current but brings its own breaking DSL changes, so treat it as a separate step if you are far behind. AGP 8.x and 9.x need JDK 17 or newer.
2. Install Android SDK Platform 36 under Tools > SDK Manager > SDK Platforms, and make sure your CI runners have the same platform (or can download it).
3. Raise compileSdk and targetSdk in the module's build.gradle.kts: compileSdk = 36 under android, and targetSdk = 36 under defaultConfig. You don't need to raise minSdk.
4. Remove manifest leftovers. Gradle's targetSdk takes precedence over the manifest, but delete any old <uses-sdk android:targetSdkVersion> anyway and check flavors for their own targetSdk. Then confirm the result in the Merged Manifest tab in Android Studio.
5. Update dependencies. Upgrade AndroidX (especially activity, core and appcompat), Firebase, Play services, and your ad, payment and analytics SDKs to versions that support Android 16. Outdated libraries cause much of the edge-to-edge and back-handling breakage.
6. Work through the behavior changes for every level you are skipping (see the next section). Run ./gradlew lint to catch deprecated APIs such as system bar color calls.
7. Verify the artifact, not the source. Run bundletool dump manifest --bundle=app-release.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion on the exact AAB you plan to upload.
8. Upload to internal testing first. Check the target SDK shown for the bundle in App bundle explorer and look at the pre-launch report. Then promote to production with a staged rollout and watch Android vitals.

Behavior changes that break apps when you target API 36

Targeting 36 opts you into every behavior change from your old target up to Android 16. If you are jumping from 34, you have to handle both the Android 15 and Android 16 changes.

Android 16 (API 36)

• No more edge-to-edge opt-out. windowOptOutEdgeToEdgeEnforcement is deprecated and disabled. Content draws behind the status and navigation bars, so every screen has to apply window insets. In Compose, use WindowInsets, safeDrawingPadding() or Scaffold padding. With Views, use ViewCompat.setOnApplyWindowInsetsListener.
• Predictive back is on by default. onBackPressed() isn't called and KEYCODE_BACK isn't dispatched anymore. Move to OnBackPressedDispatcher or OnBackInvokedCallback. As a temporary escape hatch, you can set android:enableOnBackInvokedCallback="false".
• Orientation and resizability locks are ignored on large screens. On displays with a smallest width of 600dp or more, Android 16 ignores screenOrientation, setRequestedOrientation(), resizableActivity and minAspectRatio/maxAspectRatio. A portrait-only app will rotate and resize on tablets and foldables. Games (identified by the android:appCategory flag) are exempt. The per-activity opt-out PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY is temporary: Google says it won't apply once you target API 37.

Android 15 (API 35)

• Edge-to-edge by default. setStatusBarColor() and setDecorFitsSystemWindows() are deprecated and disabled, and setNavigationBarColor() only still has an effect (as a translucent bar) with 3-button navigation.
• Foreground service limits. dataSync and the new mediaProcessing type get 6 hours per 24 hours, and you have to implement Service.onTimeout(). BOOT_COMPLETED receivers can't start dataSync, camera, mediaPlayback, phoneCall, mediaProjection or microphone foreground services.
• Background activity launches are tightened for PendingIntents and invisible windows.

Coming from API 33 or lower

Android 14 requires a foregroundServiceType and a matching FOREGROUND_SERVICE_* permission for every foreground service, and Google Play asks you to declare the types you use in the foreground service permissions declaration under Policy and programs > App content. Android 14 also stops pre-granting exact alarms to most newly installed apps and requires an export flag on runtime-registered receivers. Android 13 added the POST_NOTIFICATIONS runtime permission and granular media permissions. Read our sensitive permissions guide before you declare anything.

How to test

Test on an API 36 emulator with gesture navigation and with 3-button navigation, and on a tablet or foldable emulator. Repeat the flows that are easy to break: keyboard over input fields, bottom sheets, back from deep links, notifications and background sync. If the migration ships with clipped buttons or crashes, you can end up with a broken functionality rejection instead.

Flutter, React Native and Capacitor specifics

Flutter

In android/app/build.gradle(.kts), most projects use targetSdk = flutter.targetSdkVersion. That value depends on your Flutter SDK version: Flutter 3.27 moved the default to API 35, and Flutter 3.35 moved it to 36 (and raised the default minSdk to 24). Run flutter upgrade to 3.35 or newer, or set targetSdk = 36 and compileSdk = 36 explicitly. Raise the com.android.application plugin in settings.gradle(.kts) to 8.9.1 or later. Handle insets with SafeArea or MediaQuery.paddingOf(context), replace the deprecated WillPopScope with PopScope, and update outdated plugins.

React Native and Expo

Bare React Native projects set compileSdkVersion, targetSdkVersion and buildToolsVersion in the ext block of android/build.gradle. React Native 0.81 targets API 36 by default. It deprecates the built-in SafeAreaView in favor of react-native-safe-area-context and adds an edgeToEdgeEnabled Gradle property to turn on edge-to-edge for Android versions below 16 as well. BackHandler keeps working, but native code that overrides onBackPressed() needs migrating. With Expo, upgrade to SDK 54 or newer (which ships React Native 0.81), or set android.targetSdkVersion through the expo-build-properties config plugin, then make a new EAS build.

Capacitor / Ionic

In practice, the Android target SDK moves with the Capacitor major version. Capacitor 8 sets compileSdkVersion and targetSdkVersion to 36 (and minSdkVersion to 24) in android/variables.gradle, and its upgrade guide asks for AGP 8.13.0 and Android Studio Otter (2025.2.1) or newer. Run npx cap migrate and follow that guide rather than just changing the number on Capacitor 6 or 7. Every plugin has to be compatible with the same major version. Capacitor 8 drops android.adjustMarginsForEdgeToEdge in favor of its System Bars core plugin, so in the WebView set viewport-fit=cover and pad with env(safe-area-inset-*).

Extensions, Policy status and contacting Google

There's nothing to appeal: an old-target build is blocked automatically, and no message makes Play Console accept it. You have three options:

1. Ship a compliant build. This is the only permanent fix. Because the reach restriction is tied to your app's target API level, a compliant update is also the way to get back in front of new users on newer devices.
2. Request the extension. Google says the form is on the details page of the warning or issue under Policy and programs > Policy status, and affected apps get the link through Play Console notifications. The extension runs until November 1, 2026 at the latest. Google's Help page names no other route, so if your issue shows no form, plan to meet the requirement instead.
3. Clear stale warnings. If production already targets 36 but Policy status still shows the issue, check the version codes and tracks it lists and replace old testing-track releases with a compliant build (or pause those tracks). If it persists, contact Developer Support through Play Console Help and quote the compliant version code.

If you are publishing a brand-new app from a personal account that needs a closed test, migrate before you start the 14-day clock, so your testers check the same API 36 build you later send to production.

How to avoid the next deadline

Since 2023, the deadline has fallen on August 31 every year, and the new level has been the Android version released the year before. Assume another bump in 2027 (most likely API 37, Android 17), but only Google's announcement counts. Make the migration routine instead of an emergency:

• Add a CI gate. After the release build, run bundletool dump manifest and fail the pipeline if targetSdkVersion is below the threshold you set. Add the 16 KB alignment check (zipalign -c -P 16 -v 4 on a built APK) for native libraries.
• Keep dependencies current. Use Renovate or Dependabot for AGP, AndroidX and your framework, so the yearly bump is small.
• Test on the beta. Run nightly builds on the newest Android beta emulator; behavior changes are documented months ahead.
• Schedule the work in spring, leaving time for testing and, for new personal accounts, closed testing.

At appsubmitter.io, AI-assisted checks look for things like target levels, overrides and inset handling, and engineers review the results. We can add these gates to your CI/CD pipeline and run the Play Console side for you. Code changes are scoped and quoted up front. Talk it through in a free consultation call or book the Android service.

Template: how to reply to the Google Play review team

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Subject: Target API level requirement – [App name] ([package name])

Hello Google Play team,

We are migrating [App name] ([package name]) from target API level [current level] to API level 36 (Android 16).

Current status:
- compileSdk and targetSdk raised to 36 on our release branch, Android Gradle Plugin updated to [version]
- Remaining work: [e.g. edge-to-edge layout fixes on X screens / update of SDK name to a version that supports API 36 / foreground service changes]
- Testing: internal testing build [version code] planned for [date], staged production rollout planned for [date]

[Extension request:] We are requesting the extension to November 1, 2026 so we can finish testing instead of releasing an untested build to our users.

[Stale warning:] Version code [number], which targets API 36, has been live on the production track since [date]. Policy status still lists [version code / track]. Could you confirm whether any further action is required?

Thank you,
[Your name]
[Developer account name and ID]

Checklist before you resubmit

• The final AAB targets API 36 (or your form factor threshold for Wear OS, Automotive, TV or XR), verified with bundletool dump manifest on the exact file you upload.
• compileSdk is 36 or higher, the Android Gradle Plugin is 8.9.1 or newer, and CI runners have SDK Platform 36 installed.
• No android:targetSdkVersion override remains in AndroidManifest.xml, product flavors, build types or shared convention plugins.
• windowOptOutEdgeToEdgeEnforcement is removed and every screen was checked edge-to-edge with gesture and 3-button navigation.
• Back navigation works with predictive back and nothing relies on onBackPressed() or KEYCODE_BACK.
• Layouts were tested on a tablet or foldable emulator (smallest width 600dp or more), where orientation and resizability locks are ignored.
• Every foreground service declares a foregroundServiceType and the matching permission, and the foreground service permissions declaration in Play Console App content is up to date.
• Native libraries pass the 16 KB page-size alignment check in APK Analyzer or with zipalign -c -P 16 -v 4.
• The build passed internal testing and the pre-launch report without new crashes before you promote it to production.
• Older releases on testing tracks that still target an old API level have been replaced or paused.

Frequently asked questions

Official source: Play Console Help – Target API level requirements for Google Play apps. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.