Google Play Target API 36 Requirement: What Android Developers Must Do in 2026

Google Play policy dates and version numbers change. Confirm the current requirement in Play Console and the official pages linked at the end before you plan a release.

Target API rules arrive quietly and then stop being optional. Since August 31, 2026, new mobile apps and app updates submitted to Google Play must target Android 16 (API level 36) or higher. A build still on API 35 is rejected before review starts.

The requirement is narrower than it is often described. It is not a demand that every published app be rebuilt today, it is not the same thing as "Android 16 support", and the extension window that once softened the deadline has closed. This guide separates the official rule from the practical work.

What is target API level?

Android apps carry three separate SDK numbers, and only one is a Play requirement. Mixing them up causes failed uploads and unexpected runtime behaviour.

A useful way to hold it: compileSdkVersion is what you build against, minSdkVersion is who can install, and targetSdkVersion is how you promise to behave. Raising targetSdkVersion does not change minSdkVersion, and raising compileSdkVersion alone satisfies nothing.

What changed in Google Play's 2026 target API policy?

Google applies the same annual pattern to every platform release: an update must target the new API level, and an app that falls too far behind loses reach. The 2026 round raises the bar to API 36 for mobile, with different levels for other form factors.

Two details matter more than the table. First, the extension to November 1, 2026 was a published allowance for apps that needed more time, tied to extension forms in Play Console notifications. It is historical policy now, so do not plan a release around it. Second, permanently private apps — restricted to one organisation for internal distribution — are listed as an exception.

What happens if your app does not meet the requirement?

The consequences are graded, and they differ between new submissions and apps already on the store.

• New apps below API 36 are rejected at submission.
• Updates below API 36 are rejected for the same reason, including urgent bug fixes — which is why leaving the migration late is risky.
• Existing apps below API 35 lose reach. Google's wording is that they stop being discoverable to new users whose devices run an Android version higher than the app's target API level.

Note what is not stated. Google does not document this as automatic deletion, and does not describe existing installs being removed from devices. The documented effect is availability for newer-OS users. For certainty about a specific app, check its Play Console notifications rather than inferring from a blog post — including this one.

How to check your app's current target API level

There are four places to look, and they can disagree if you edit the wrong one.

1. The Gradle build file

The canonical location in a modern project. Open the module-level file, usually app/build.gradle.kts:

android {
    compileSdk = 36

    defaultConfig {
        minSdk = 23
        targetSdk = 36
        versionCode = 42
        versionName = "4.2.0"
    }
}

The Groovy equivalent in app/build.gradle uses different syntax for the same three values:

android {
    compileSdk 36

    defaultConfig {
        minSdkVersion 23
        targetSdkVersion 36
    }
}

2. The manifest

If your project still declares <uses-sdk> in AndroidManifest.xml, that value can matter. Gradle normally wins, but a stale entry is a genuine source of confusion.

3. The merged manifest

The most trustworthy build-side answer, because it reflects library contributions and build-type overrides. Open it under your module's build intermediates, or use APK Analyzer on the built APK.

4. Play Console

Play Console reports the target API level of what you actually uploaded, which is the only number the policy checks. If Console disagrees with your project, check whether a different build variant or a stale bundle was submitted.

How to update your app to Android 16 (API 36)

The mechanical part takes an afternoon. The behaviour changes are where the real work sits, so treat the steps below as the prerequisite rather than the whole job.

1. Install the Android 16 SDK. Use the SDK Manager to install the Android 16 (API 36) platform and build tools.
2. Update Android Studio and the Android Gradle Plugin. A current AGP is required to build against SDK 36 reliably. Let the AGP Upgrade Assistant handle Gradle and plugin versions together.
3. Raise compileSdk to 36. This unlocks the new APIs at compile time. Build and fix API errors before touching targetSdk, so failures stay attributable.
4. Raise targetSdk to 36. This is the value the policy checks, and it also switches on the Android 16 behaviour changes below.
5. Check dependencies. Libraries compiled against older SDKs can break at runtime. Update them and read each provider's Android 16 notes.
6. Rebuild, install, and validate. A clean build is not evidence of correct behaviour. Test on Android 16 with the flows affected by the targeted changes.

Bumping targetSdkVersion is precisely what enables the stricter behaviour, so the testing section below is not optional.

Important Android 16 behavior changes developers must test

These changes apply to apps targeting Android 16 and running on Android 16 or higher. An app still targeting API 35 keeps the older behaviour, which is why the same APK can behave differently after a target bump.

Edge-to-edge is no longer optional

Android 15 enforced edge-to-edge but allowed an opt-out through R.attr#windowOptOutEdgeToEdgeEnforcement. Targeting Android 16 deprecates and disables that attribute on Android 16 devices, so the app draws behind the system bars whether or not it is ready. The symptom is content under the status or navigation bar — a toolbar hidden behind the clock, a button trapped beneath the gesture bar. Handle window insets instead of assuming padding exists.

Predictive back replaces onBackPressed

For apps targeting Android 16, predictive back animations are enabled by default, onBackPressed is no longer called, and KeyEvent.KEYCODE_BACK is no longer dispatched. Old-style interception silently stops working: the user taps back and leaves the app instead of closing your dialog. Migrate to the supported back APIs, or set android:enableOnBackInvokedCallback="false" temporarily while you do.

Orientation and resizability restrictions are ignored on large screens

On displays with a smallest width of 600dp or more, orientation, resizability, and aspect ratio restrictions no longer apply. screenOrientation, resizeableActivity, minAspectRatio, and maxAspectRatio are ignored in full-screen and multi-window modes. Layouts built for one locked orientation will stretch, letterbox badly, or place components off-screen. Games, screens narrower than 600dp, and users who opt into the app's default behaviour are documented exceptions.

Smaller but real

Two lower-profile changes are easy to miss. The elegantTextHeight attribute is deprecated and ignored for apps targeting Android 16, so layouts that relied on the compact font can shift with scripts such as Arabic, Thai, Tamil, or Malayalam. And scheduleAtFixedRate now executes at most one missed period instead of replaying every missed execution, which breaks code that expected a catch-up burst.

Flutter, React Native and Unity developers

Frameworks do not exempt you from the policy: the uploaded artifact has a targetSdkVersion regardless of what generated it. What differs is where the value is set.

• Flutter: the value is typically driven by the Flutter engine's default, which the Android host project can override. Confirm the merged manifest of your release build rather than assuming.
• React Native: the value lives in the Android host project's build file. Raising compileSdk or AGP can surface incompatibilities in older versions, so check the framework's supported Gradle and SDK combinations.
• Unity: the build settings expose target API level alongside minimum API level, and native plugins can pin older values. Confirm the exported Gradle project, not only the editor dropdown.

I do not name specific minimum framework versions: they change faster than any article, and a wrong version number is worse than none. Check each framework's release notes for API 36 support, then verify the built artifact.

Testing checklist before uploading to Google Play

Two deserve emphasis. Testing on API 36 hardware is the only way to see the targeted behaviour changes, because an Android 14 emulator will not reproduce them. And the pre-launch report gives an automated stability read before real users do; the pre-launch report guide explains how to interpret it.

Common problems and how to fix them

Each row is a plausible cause to investigate, not a guaranteed diagnosis.

The compatibility framework matters here: it toggles individual Android 16 behaviour changes on a device without changing your target level, so you can find affected screens before committing to the bump. Google documents the flags for both the resizability and scheduled-work changes.

Frequently asked questions

What target API level is required for new Google Play apps in 2026?

For mobile apps, API level 36 (Android 16) or higher, for both new apps and updates, from August 31, 2026.

Is API 35 enough for a new mobile app submission?

No. API 35 satisfies the existing-app availability rule, but new mobile apps and updates must target API 36 or higher. API 36 is Android 16's API level, so "target API 36" and "target Android 16" describe the same requirement.

Does targetSdkVersion affect minSdkVersion?

No. They are independent. Raising targetSdkVersion does not change which devices can install the app; only minSdkVersion does that.

Will changing targetSdkVersion break my app?

It can. Raising the value switches on the targeted behaviour changes, so edge-to-edge, predictive back, and large-screen resizability start applying. That is why the testing checklist exists.

What happens to older apps that do not meet the requirement?

Google documents a discoverability effect: apps targeting too low an API level stop being available to new users on devices running a newer Android version. The documentation describes availability, not deletion.

Do Flutter, Wear OS and Android TV apps follow the same rules?

The policy applies to the uploaded artifact whatever produced it, so Flutter apps need API 36 too. Wear OS and Automotive require API 35; Android TV and Android XR require API 34, with separate availability thresholds.

Official resources

Every policy statement here comes from these pages. Where a page disagrees, the official page wins.

• Target API level requirements for Google Play apps — requirements by form factor, the extension window, and the private-app exception
• Target SDK requirements — migration guidance and links to each version's behaviour changes
• Android 16 behavior changes for apps targeting API 36 — edge-to-edge, predictive back, adaptive layouts, scheduling
• Android 16 behavior changes for all apps — changes that apply regardless of target level
• Android 16 migration guide — the two-phase compatibility-then-targeting workflow
• Android 16 compatibility framework changes — the flags for testing individual changes

Conclusion: separate the policy check from the engineering

Two jobs hide inside "update your target API level". The first is administrative: put 36 in the build file, confirm the merged manifest, and be sure the artifact you upload is the one you think it is. The second is the real work — handling insets, migrating back navigation, and making layouts survive a display that ignores your orientation lock.

Teams that treat the number as the whole task ship a build that passes the upload check and then breaks on new devices. Teams that test on Android 16 before the bump find the same problems earlier and cheaper. For coverage beyond your own device shelf, TestersHQ coordinates real-device testing and structured feedback; the real device testing guide explains how to choose devices worth testing on.

We do not guarantee Play approval or any particular outcome from a release review.