Targeting Android 16 (API 36) in Flutter: Edge-to-Edge, Predictive Back, Large Screens and 16 KB Pages

Google Play requires app updates to target API level 36 (Android 16) by August 31, 2026, with an extension to November 1, 2026 that you can request in Play Console. Bumping targetSdk in a Flutter project is a one-line change. The behavior changes that come with it are not, and several of them hit Flutter apps in ways that don't show up until a user on a foldable or a gesture-navigation phone opens the app.

Here are the four changes I check on every Flutter app before shipping an API 36 build.

1. Edge-to-edge is no longer optional

Android 15 made apps draw edge-to-edge by default but left an opt-out attribute. For apps targeting Android 16, that opt-out no longer applies on Android 16 devices. Your Flutter UI is drawn behind the status bar and the navigation bar, full stop. Flutter's docs also warn that leaving the opt-out attribute in place can cause problems on Android 16 and above, so remove it rather than leaving it as dead configuration.

What breaks:

App bars and headers that assumed the system reserved space at the top.
Bottom buttons, bottom sheets and custom bottom navigation that now sit under the gesture handle or the three-button bar.
Full-screen pages without a Scaffold, such as splash, onboarding and camera screens, which never got automatic padding.

The fix is to respect window insets everywhere: SafeArea around content that must stay tappable, and the padding and view-padding values from MediaQuery when you want a background to extend under the bars while the content does not. Material 3 widgets such as Scaffold, AppBar and NavigationBar already handle most of this, so the problems are usually in custom layouts. Test with both gesture navigation and three-button navigation, because the bottom inset differs a lot between them.

2. Predictive back is on by default

For apps targeting API 36 and running on Android 16, predictive back system animations (back-to-home, cross-task and cross-activity) are enabled by default, and the old back callbacks are no longer delivered. The user starts a back gesture and sees a preview of where they'll land before committing.

That breaks the old Flutter pattern of intercepting back at the last moment. WillPopScope is deprecated; the replacement is PopScope, where you declare up front whether the route can pop and react in a callback after a pop was attempted. The mental shift matters more than the API:

Decide "can this screen be popped?" as state, not as a question asked during the gesture. An unsaved form sets that state to false as soon as it becomes dirty, so the system can show the right animation.
Show your "discard changes?" dialog from the callback after a blocked pop, not by cancelling the gesture halfway through.
Check nested navigators, such as tabs with their own stacks. They are where back handling most often ends up closing the whole app instead of going back one level.

Test predictive back on a real Android 16 device with both navigation modes. Behavior with three-button navigation has been less consistent than with gestures.

3. Orientation locks are ignored on tablets and foldables

This is the change most Flutter apps aren't ready for. For apps targeting Android 16, orientation, resizability and aspect-ratio restrictions are ignored on displays whose smallest width is at least 600 dp. That covers the manifest's screenOrientation and resizeableActivity attributes as well as runtime orientation requests, which includes what Flutter's SystemChrome.setPreferredOrientations asks the platform to do.

A phone-only app that locked itself to portrait will now be shown in landscape on a tablet, in a resizable window on a foldable, and in split screen next to another app. If your layouts were built for a 390-dp-wide portrait phone, that shows up as stretched cards, giant buttons and content hidden off-screen.

There is a temporary opt-out that restores the old compatibility-mode behavior, but Android 17 is removing it. Use it to buy time, not as the fix. The real work is responsive layout:

Drive layout from the available width (LayoutBuilder or MediaQuery size), not from the device type or orientation.
Pick two or three breakpoints, for example compact, medium and expanded, and give each a deliberate layout: bottom navigation on phones, a navigation rail and two panes on wider windows.
Cap the width of reading content and forms so they don't stretch across a 12-inch screen.
Handle state across configuration changes. Resizing a window on a foldable shouldn't reset a half-filled form or restart a video.

4. 16 KB memory pages for native code

Separately from API 36, Google Play has required apps targeting Android 15 or higher to support 16 KB memory page sizes since November 1, 2025. Pure Dart code is unaffected. What matters is every .so file in your app bundle: the Flutter engine, plus native libraries pulled in by plugins for things like databases, image processing, video, ML and cryptography.

The workflow:

Upload a build and open App Bundle Explorer in Play Console. The Memory page size field lists every library that doesn't support 16 KB pages.
Update the Flutter SDK, the Android Gradle Plugin and the NDK (r28 or newer aligns native code for 16 KB by default), then update the plugins that own the flagged libraries.
Test on an Android 15+ emulator image with 16 KB pages, or a Pixel with the 16 KB developer option enabled. adb shell getconf PAGE_SIZE should report 16384.

If a flagged library belongs to an abandoned plugin, you have to replace it. No build flag will fix a binary you don't control.

A pre-release checklist

Remove the edge-to-edge opt-out and audit every screen for insets, in both navigation modes.
Migrate WillPopScope to PopScope and test predictive back, including nested navigators.
Run the app on a tablet and a foldable emulator in landscape, split screen and freeform windows.
Confirm in App Bundle Explorer that every native library supports 16 KB pages.
Only then raise targetSdk to 36 and ship.

None of these are exotic. Together they decide whether your app feels native on a 2026 Android phone or looks like it was built for 2019.

I build Flutter apps for Android and iOS, including large-screen and IoT products. See Flutter app development or get in touch.