Android 16's Adaptive Apps Mandate: What Actually Changes

By Michael Samuel Naeem · September 15, 2024 · 5 min read

Android 16 changes a rule that a lot of apps quietly depended on: on large-screen devices, the system now ignores your app's orientation, resizability, and aspect-ratio restrictions. If you target the new SDK level, android:screenOrientation="portrait" and resizeableActivity="false" stop having their old protective effect on tablets, unfolded foldables, and desktop windowing. The device will rotate and resize your app whether you declared you support it or not. This is the "adaptive apps mandate," and the practical takeaway is blunt: on big screens, you no longer get to opt out of being resizable.

I've spent the last several release cycles helping teams unwind orientation locks, and the ones panicking are the ones who used those locks as a layout crutch rather than a genuine product decision. Let me separate the real work from the noise.

What actually changed, precisely

The mandate is scoped to large screens — displays whose smallest width is roughly 600dp or more. That's tablets, foldables when unfolded, ChromeOS, and desktop-mode windows. On a normal phone, nothing changes: a portrait-only phone game stays portrait-only. But on the big devices, for apps targeting the relevant SDK:

• android:screenOrientation restrictions are ignored — the app can be rotated freely.
• resizeableActivity="false" is ignored — the app can be resized, including split-screen and free-form windows.
• Fixed aspect-ratio (maxAspectRatio) constraints are ignored — the app fills whatever window it's given.

The system is essentially saying: on a device large enough that these restrictions hurt the user, the user's control wins over the developer's lock.

Why Google is forcing this

Large screens have been a second-class experience for years precisely because apps lock orientation and refuse to resize. You unfold a foldable expecting a tablet layout and get a stretched phone UI frozen in portrait. Google tried encouragement (large-screen guidelines, quality tiers) and it didn't move the needle enough, so this is the enforcement step. The bet is that removing the escape hatch on big screens pushes the ecosystem toward genuinely adaptive UI — the kind that treats window size as an input, not an exception.

If you've already built adaptive layouts driven by window size classes, this mandate is a non-event. The apps in trouble are the ones that hardcoded portrait and never handled a wide window.

The two failure modes you must fix

There are really only two ways an app breaks under this change, and both are fixable without a rewrite.

1. Layout that assumes portrait. UI that hardcodes a narrow, tall arrangement looks broken stretched across a landscape tablet. The fix isn't to fight the resize — it's to branch layout on window size class so a wide window gets a wide layout (two panes, a list-detail split) instead of a stretched single column.

2. State lost on configuration change. A rotation or resize is a configuration change, and an activity that doesn't preserve state recreates and loses the user's place. If you locked orientation partly to avoid dealing with recreation, that shortcut is gone. You now must survive recreation properly.

Surviving recreation is the real homework

The orientation lock let sloppy state handling hide. Remove it and every unsaved bit of UI state becomes a visible bug on rotate. The fixes are well-established:

• rememberSaveable for transient UI state in Compose — scroll positions, expanded/collapsed, text field contents — so it round-trips through the saved instance state bundle.
• SavedStateHandle in your ViewModel for state that must survive not just rotation but process death. This is the same discipline covered in surviving process death with SavedStateHandle — the mandate just makes it non-optional on large screens.
• Don't cache Activity-scoped things that a resize invalidates, like a Configuration-derived dimension captured once.

If your app already handles rotation cleanly on a phone, resize on a tablet is the same machinery at a different size.

A preparation checklist

Here's the sequence I run teams through:

1. Audit the manifest. Find every screenOrientation, resizeableActivity="false", and maxAspectRatio. For each, ask: was this a real product need or a layout crutch? Keep only genuine needs (and know they won't be honored on large screens anyway).
2. Drive layout from WindowSizeClass. Replace any implicit portrait assumption with explicit compact/medium/expanded branches.
3. Test in a resizable emulator. Use the resizable (foldable) emulator and drag the window through sizes. Rotate. Split-screen. Fold and unfold.
4. Verify state across every config change. Type into a field, rotate, confirm it survives. Scroll a list, resize, confirm the position holds.
5. Check touch targets and insets at the new sizes. Edge-to-edge behavior and cutouts differ across form factors.

What you don't have to do

A few things teams over-worry about. You don't have to support phones in landscape if landscape genuinely doesn't make sense for your product — the mandate is large-screen only, so a portrait phone game is fine. You don't have to build a bespoke tablet UI overnight; a competent responsive layout that reflows is enough to pass and to be usable. And you don't have to abandon orientation preferences entirely — you can still request an orientation, it just won't be enforced on large screens.

What I'd take away

Android 16's adaptive apps mandate removes the ability to lock orientation and resizing on large screens, and it does so to end the era of stretched phone UIs on tablets and foldables. If your app is already adaptive — layout branched on window size class, state preserved with rememberSaveable and SavedStateHandle — you're done. If it leaned on orientation locks as a layout crutch, the work is to make layout a function of window size and to survive configuration changes cleanly. Audit the manifest, test in a resizable emulator, and verify state across every rotate and resize. The mandate isn't asking for a rewrite; it's asking you to stop pretending the window can't change size.

Resources

• Large screen app quality (Android developers)
• Make apps adaptive / device compatibility modes
• Support different screen sizes
• Configuration changes
• Window size classes