Target API 36 by 1 November: An Android 16 Migration Checklist

If you asked Google Play for more time on the Android 16 target API requirement, that extra time ends on 1 November 2026. After that, an app update you submit has to target API level 36, and the behaviour changes that come with it apply on Android 16 devices. Most apps can make the jump in a few days of work. The trouble is that a couple of the changes are visual and easy to miss until a user files a one-star review with a screenshot.

Here is what the rule says, the changes that actually break things, and a checklist you can work through this week.

What the Google Play target API rule requires

From 31 August 2026, according to the Android Developers target API page:

• New apps and app updates must target Android 16 (API 36) or higher. Wear OS and Android Automotive OS apps need API 35; Android TV and Android XR apps need API 34.

• Existing apps must target at least Android 15 (API 35) to stay available to new users on devices running a newer Android version than the app targets.

Developers who needed more time could request an extension to 1 November 2026. Per the Play Console Help article, affected apps got the request form through Play Console Notifications, and an app on an extension keeps reaching all users until 1 November. Without an update after that, your app stops being available to new users on newer Android versions. Existing users keep it.

The code change itself is one line:

android {
    defaultConfig {
        targetSdk = 36
    }
}

Bump compileSdk to 36 as well. The real work is everything that line switches on.

The Android 16 changes that break apps

Google's Android 16 behaviour changes page lists everything that applies once you target 36. These four are the ones most likely to bite.

1. Edge-to-edge is no longer optional

On Android 15, you could keep your old layout by setting windowOptOutEdgeToEdgeEnforcement. When you target 36, that attribute is deprecated and disabled on Android 16 devices. Your app draws behind the status bar and the navigation bar, whether you planned for it or not.

Symptoms: toolbars under the status bar, bottom buttons hidden behind the gesture bar, a floating action button you cannot tap. The fix is to handle window insets properly. In Compose, that usually means using Scaffold padding or the WindowInsets modifiers; in Views, applying insets with ViewCompat.setOnApplyWindowInsetsListener. Remove the opt-out attribute so you are not relying on it.

2. Predictive back is on by default

Apps targeting 36 get predictive back animations by default, and onBackPressed is no longer called, nor is KEYCODE_BACK dispatched. If your app overrides onBackPressed to show a "discard changes?" dialog or to close a drawer, that logic silently stops running.

Move it to OnBackPressedDispatcher callbacks, or BackHandler in Compose. If you need a short-term escape hatch, there is a temporary opt-out:

<application android:enableOnBackInvokedCallback="false">

Treat that as a bridge, not a fix.

3. Orientation locks are ignored on tablets and foldables

On displays with a smallest width of 600dp or more, Android 16 ignores screenOrientation, resizableActivity, and min and max aspect ratio settings for apps targeting 36. Games declared with android:appCategory are excepted. If your app is portrait-locked, it will now rotate and resize on large screens.

The temporary opt-out is a manifest property:

<property
    android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
    android:value="true" />

Google says this opt-out will not apply once you target API 37. If you use it now, schedule the real layout work for next year rather than hoping it goes away.

4. elegantTextHeight is ignored

The elegantTextHeight attribute is deprecated and ignored for apps targeting 36. Google calls out text in scripts including Tamil, Gujarati, Kannada, Malayalam, Odia and Telugu as needing a check. For apps with Indian-language users, this is a real one: look for clipped ascenders and descenders and cramped line heights.

Smaller changes worth a search through your code

• Fixed-rate scheduling. If you use ScheduledExecutorService.scheduleAtFixedRate, missed runs are no longer replayed in a burst when the app comes back; at most one runs.

• Health sensors. BODY_SENSORS is replaced by granular permissions such as READ_HEART_RATE, and mobile apps must declare an activity that shows the privacy policy, or the permission is revoked.

• Photo picker. With limited media access, photos your app owns are pre-selected in the picker. Users can deselect them, which revokes access.

A five-day migration checklist

For a typical app with a small team:

1. Day 1: Bump compileSdk and targetSdk to 36, update AndroidX and Compose dependencies, and fix compile warnings.

2. Day 2: Run every main screen on an Android 16 emulator with gesture navigation and three-button navigation. Screenshot each one. Fix insets.

3. Day 3: Search for onBackPressed and KEYCODE_BACK. Move each to a back callback and test every dialog, drawer and bottom sheet.

4. Day 4: Test on a tablet and a foldable emulator. Decide: fix layouts now, or use the temporary resizability opt-out with a ticket for next year.

5. Day 5: Check text in every language you support, run your test suite, and push to an internal testing track before production.

Teams on Flutter or React Native are not exempt. The target SDK lives in your Android build files, and edge-to-edge and back handling affect your app's host activity. Check your framework's release notes for the version that handles Android 16 properly before you bump.

Ship the update a few days before 1 November, not on the day. Play review times vary, and a rejected build on 31 October is a bad way to spend a Saturday.