Android Target API Level: Meeting Google Play's API 36 Rule

Once a year Google Play raises the Android version your app has to target, and a few teams find out when an upload is refused. The 2026 step is Android 16, with behaviour changes you will see on real devices. This guide covers what the rule says, what happens to apps that fall behind, and how to change the setting in a native, Flutter or React Native project. Google's requirements below are from its own pages as of 2 October 2026.

The short version

• Since 31 August 2026, new apps and app updates must target Android 16 (API level 36) to be submitted to Google Play.
• Wear OS and Android Automotive OS apps need API level 35. Android TV and Android XR apps need API level 34.
• Existing apps that target API level 34 or lower stop being offered to new users on devices running a newer Android version.
• You can request an extension to 1 November 2026 from the Policy status page in Play Console.
• The change itself is one Gradle line, but targeting Android 16 turns on behaviour you need to test: edge-to-edge, predictive back and large-screen layouts.

What the target API level is

Three numbers in your Gradle file look alike and do different jobs:

• minSdk is the oldest Android version your app installs on.
• compileSdk is the Android SDK your code is compiled against. It decides which APIs you can call.
• targetSdk tells Android which version's behaviour your app was built and tested for. When you raise it, the system applies the newer rules to your app.

Google's guide to meeting the target API level requirement explains why Play cares: some security, privacy and performance changes reach an app when it declares support through targetSdkVersion, while the app keeps running on older Android versions down to its minSdk. Raising the target does not drop old devices.

The 2026 requirement

As of 2 October 2026, the Play Console Help article Target API level requirements for Google Play apps sets out the levels from 31 August 2026:

The exception Google lists is permanently private apps: apps restricted to users in one organisation and intended for internal distribution. A small team publishing to the public store should assume the rule applies.

The extension to 1 November 2026

If you need more time, Google lets you request an extension to 1 November 2026. The article says apps that are out of line receive a policy warning and a notification in Play Console, and the extension form sits on the details page of that warning on the Policy status page. If you have not seen a warning, check Policy status before assuming there is nothing to do. An extension buys weeks, not a new deadline, so plan the work as if 1 November is the real date.

What happens to existing apps that fall behind

A live app is not removed for missing the target. It is narrowed. According to the same article, an existing phone or tablet app that targets API level 34 or lower stops being available to new users whose devices run a newer Android version than the app targets. In practice:

• People who already installed the app keep it. They can still find it, reinstall it and use it on any Android version it supports.
• New users on newer devices cannot discover or install it. Google says Play tells them the app was made for an older version of Android.
• New users on devices at or below your target API level can still install it.
• Your next update has to meet the current target for new apps and updates, which is API level 36 for phones and tablets.

Google notes this may reduce downloads, and that is the real cost: the people you lose are the ones on newer devices who never get the chance to install. If you no longer plan to maintain an app, the article points to unpublishing as the alternative.

How to change targetSdk

For a native Android project, the setting lives in your module's build.gradle.kts. As of 2 October 2026, Google's Android 16 SDK setup guide shows both values:

android {
    compileSdk = 36

    defaultConfig {
        targetSdk = 36
    }
}

The same guide names the lowest Android Gradle plugin release that works with the Android 16 SDK, and points to the Android Gradle plugin Upgrade Assistant if you are on an older one. Android Studio's Android SDK Upgrade Assistant walks through the behaviour changes for each step up. If you are several levels behind, Google's target SDK guide links the behaviour changes for Android 13, 14, 15 and 16; read each one, not just the last.

What changes when you target Android 16

Google's page on behaviour changes for apps targeting Android 16 lists several. Three are the ones most likely to show up in a small team's app:

• Edge-to-edge without an opt-out. Android 15 let you opt out with windowOptOutEdgeToEdgeEnforcement. When you target Android 16 and run on Android 16, that attribute is disabled, so content draws behind the system bars and you handle insets yourself.
• Predictive back. On Android 16 devices, the predictive back animations are on by default, onBackPressed is not called and KEYCODE_BACK is not dispatched. Migrate to the supported back APIs, or opt out for now with android:enableOnBackInvokedCallback="false" in the manifest.
• Large screens. On displays with a smallest width of 600dp or more, orientation, resizability and aspect-ratio restrictions are ignored. A portrait-locked app fills the window on a tablet or foldable and can rotate. Games are excepted, and there is a temporary per-activity opt-out.

Test on an Android 16 device or emulator, in portrait and landscape, on a phone and a tablet-sized screen. Rotation recreates activities, so check that screens keep their state.

Check your libraries

Google's guide asks you to check that third-party SDKs support the level you are moving to and to raise it with the provider if one does not. Update your dependencies in the same change, and read their release notes for anything about edge-to-edge or back handling.

Flutter and React Native

Flutter

As of 2 October 2026, Flutter's guide to building and releasing an Android app shows android/app/build.gradle.kts reading targetSdk = flutter.targetSdkVersion. That value comes from the Flutter Gradle plugin and is managed by Flutter, so the usual route to a newer target is upgrading Flutter. You can replace the variable with a fixed number if you want to control it yourself. If your project already has a fixed number there, upgrading Flutter will not change it, so check that line before you build.

React Native and Expo

The React Native team's React Native 0.81 release post says Android apps built with 0.81 default to targeting Android 16 (API level 36), and warns that Android 16 requires edge-to-edge with no opt-out and turns on predictive back. A bare React Native project keeps the number in its Android Gradle files, so an older project needs either a React Native upgrade or a manual change there.

For Expo, the Expo SDK 54 release notes say React Native for Android now targets Android 16, with edge-to-edge always on. If you need to override the default, the expo-build-properties config plugin takes an android.targetSdkVersion option. Rebuild the app after the change, because the value is set at build time.

A checklist for the change

1. Open Policy status in Play Console and note any target API warning and its deadline.
2. Raise compileSdk and targetSdk to 36, and update the Android Gradle plugin and your libraries.
3. Work through the behaviour changes for each level you skipped.
4. Test edge-to-edge, back navigation and large-screen layouts on Android 16.
5. Ship to a testing track before production. Our guide to Google Play testing tracks covers the options, and a staged rollout limits the damage if something slips through.

If you also ship on iOS, our guide to publishing on the App Store covers Apple's side, including its own SDK minimums. For the Play side from the beginning, see publishing an app on Google Play.

How FeedbackKit fits in

A target bump changes how your app looks on devices you may not own. A tablet user sees a portrait layout stretched to landscape, or a toolbar tucked under the status bar, and you often hear about it in a one-star review. An in-app feedback board gives those users somewhere better to say it, and lets the next person vote on the same report instead of writing their own.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

The board is part of your app, so test it with the rest of your screens after the change. FeedbackKit has SDKs for Kotlin with Jetpack Compose, Flutter and React Native. When the update is out, tell the people who reported layout problems that they are fixed; our post on closing the loop shows how. To give your Android users a place to report what the next release should fix, start free.