Google Play Blocked Your Update Over the Target API Level? Here’s How to Get to API 36.

The requirement, exactly

• New apps and updates must target the required level. An existing app that is not updated stays on Play, but stops being available to new users on Android versions higher than its target.
• Extension: Google lets you request an extension to 1 November 2026 from the Policy status page of the affected app in Play Console. It buys weeks, not a waiver.
• Google raises the requirement every year (the next step, API 37, is expected around August 2027); a modernized project makes each yearly bump routine.

Source: Play Console Help, Target API level requirements for Google Play apps (linked in the sources panel, verified 22 September 2026).

How the block shows up

• Play Console → Policy status: “Your app must target Android 16 (API level 36) or higher.”
• Upload of a new release fails with an API-level error, or the release cannot be rolled out.
• Google warning emails ahead of the deadline that were forwarded to a mailbox nobody reads.

There is nothing to appeal. It is a technical requirement; the only exit is a compliant build or the extension.

If you are not sure what your project currently targets, paste your build.gradle, libs.versions.toml, pubspec.yaml or package.json into the Android update readiness checker. It reads the text in that one request, reports the target and compile SDK it can see alongside the other requirements that block updates, and stores nothing.

What changes when you target API 36

Setting targetSdk = 36 opts the app into Android 16 behaviour. The changes that most often break older apps:

Edge-to-edge is enforced

Apps targeting Android 15 got edge-to-edge by default with an opt-out; on Android 16 the opt-out (windowOptOutEdgeToEdgeEnforcement) is deprecated and no longer honoured. Screens that never handled window insets end up with content under the status bar, buttons hidden behind the navigation bar, and overlapped keyboards. The fix is real inset handling — ViewCompat.setOnApplyWindowInsetsListener, WindowInsets in Compose, SafeArea/MediaQuery.padding in Flutter, SafeAreaView plus edge-to-edge configuration in React Native — screen by screen.

Orientation and resizability on large screens

On displays of at least 600 dp smallest width, Android 16 ignores screenOrientation, resizableActivity, minAspectRatio / maxAspectRatio and setRequestedOrientation() for apps targeting 36. Apps that were “portrait only” must lay out correctly in landscape and in split-screen windows. A temporary opt-out exists (android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY as an activity or application property) but Google states it will not apply once you target API 37 — it postpones the work by one year at most.

Predictive back is on, and onBackPressed is not called

For apps targeting 36 on Android 16 devices, predictive back animations are enabled by default, onBackPressed() is no longer called and KEYCODE_BACK is not dispatched. Apps that intercept the back key to show “discard changes?” dialogs, close drawers or manage custom navigation stacks silently lose that behaviour unless they migrate to OnBackPressedCallback / OnBackInvokedCallback (or temporarily set android:enableOnBackInvokedCallback="false").

Background work, alarms and notifications

Exact-alarm and foreground-service rules that started in Android 14/15 continue to tighten; older code that schedules work or starts services from the background needs a review, and the Play policy declarations for those permissions must match.

Permissions and privacy

Photo picker instead of broad media permissions, the notification runtime permission, and the Data safety form all need to reflect what the modernized app actually does.

Dependencies and the toolchain

Compiling against SDK 36 needs an Android Gradle Plugin that supports it, which in turn needs a Gradle and Kotlin version your old plugins may not compile with. This cascade is usually the largest part of the work, especially in Flutter and React Native projects with abandoned plugins.

By framework

Should you request the extension?

Yes, if the migration cannot be finished before your next essential release — the request takes minutes and removes the block until 1 November 2026. No, if you expect to ship the compliant build within days anyway; the form does not speed up anything. Either way, the extension does not remove the requirement.

What we do

1. Read the notice and the build configuration; confirm the target, compile SDK, AGP, Gradle, Kotlin and framework versions.
2. List the Android 16 behaviour changes that apply to your app (not the generic list) and the dependencies that must move.
3. Raise the target, resolve the toolchain cascade, fix insets and large-screen layouts, replace deprecated APIs, and re-verify the Data safety form.
4. Test on Android 16 devices, produce the release bundle, and hand over a staged-rollout checklist — or roll it out for you if you prefer.

The 16 KB page size requirement and the Play Billing Library 8 requirement usually surface in the same release; we handle them together. See the 16 KB page size fix and the Billing Library upgrade.

Release checklist

• targetSdk and compileSdk at 36; AGP, Gradle and Kotlin at versions that support it
• Edge-to-edge handled on every screen, including dialogs, bottom sheets and WebViews
• Back handling migrated to OnBackPressedCallback / OnBackInvokedCallback (predictive back)
• Large-screen orientation and split-screen verified
• Exact alarms, foreground services and notification permission reviewed against the Play declarations
• Deprecated SDK versions replaced; Play Console policy status clean
• 16 KB alignment verified; Play Billing Library 8+ where purchases exist
• Extension requested if the release date is at risk

Frequently asked questions