Android 16 (API 36) changes a basic assumption many apps rely on: on large screens, the system can ignore your orientation, aspect ratio and resizability locks. If you target API 36 and haven’t audited your layouts, you can ship a phone-perfect app that collapses into clipped toolbars, broken navigation, and impossible flows the moment it runs on a tablet, foldable, Chromebook, or connected display. (developer.android.com)
This is not a niche edge case. Google Play’s target API requirement now pushes teams towards Android 16 for new apps and updates (with an extension option available up to 1 November 2026). (developer.android.google.cn)
What changed in Android 16: “universal resizable” on large screens
When an app targets Android 16 (API level 36), Android’s large-screen behaviour changes in a way that surprises teams who’ve historically “stabilised” UI via manifest restrictions.
On large screens (Android’s guidance calls out smallest width of at least 600dp as the baseline for “large screen”), Android 16 can treat the following as baseline expectations rather than app-enforced constraints:
- Screen orientation locks (for example, forcing portrait)
- Aspect ratio locks / letterboxing expectations
- Activity resizability constraints
In the Android 16 documentation, this is explicit: for apps targeting API 36, orientation, resizability and aspect ratio constraints are ignored on large screens by default. (developer.android.com)
The practical consequence
If your UI only works at “phone portrait, full-screen”, Android 16 is going to put it into situations you previously avoided:
- Landscape-only windows on tablets
- Narrow/tall windows in split-screen
- Very wide windows on desktop-like environments
And Android is giving you ways to test this early, via the compatibility framework flag UNIVERSAL_RESIZABLE_BY_DEFAULT. (developer.android.com)
Why founders and heads of engineering should care
If you ship B2C, the failure mode is obvious: reviews that read “unusable on tablet” or “buttons off-screen”, followed by a rating dip you can’t fully repair with a hotfix.
If you ship B2B, the risk is different: large screens are disproportionately common in the “serious work” environments that drive renewals (tablets in field work, Chromebooks in education, connected displays in retail, desktop modes in emerging Android form factors). Even if only a minority of users hit the issue, they’re often the high-value ones.
Also: the target SDK step tends to be scheduled late. Teams do the API bump to meet Play deadlines, then discover the UI regressions when it is too late to redesign flows.
The 10-screen audit: a concrete pre-release checklist
This checklist is deliberately not “test on a tablet”. It’s a fixed set of window shapes that force the real breakpoints in both Compose and legacy Views.
Run it on:
- One tablet / large-screen emulator
- One foldable (or foldable emulator)
- One Chromebook or an emulator in freeform/desktop-like resizing if you support those environments
Android also recommends using the resizable emulator / compatibility tools for these behaviours, and explicitly calls out the compat flag for testing. (developer.android.com)
The 10 screens (window configurations) to validate
Treat each as a pass/fail gate. If any fails, you have an adaptive layout bug, not “a weird device”.
- Phone portrait (baseline)
- Phone landscape (wide but short)
- Tablet portrait (tall, large width)
- Tablet landscape (very wide)
- Foldable cover screen (narrow)
- Foldable inner display (large)
- Split-screen: half-width tablet (tall and narrow)
- Split-screen: one-third width tablet (very narrow)
- Freeform window: wide-but-short (desktop-style)
- Freeform window: narrow-but-tall (chat sidebar style)
If your app is “fine” in 1–4 but fails 7–10, you are not actually adaptive; you are just “tablet tolerant”. Android 16’s baseline behaviour is designed to expose exactly that gap. (developer.android.google.cn)
What to look for on every screen (the failure modes)
This is where teams waste time. They stare at the UI and think “looks a bit off”, but don’t know what to call out, how to fix it, or whether it’s acceptable.
Audit these categories systematically:
- Reachability: primary actions off-screen; bottom bars hidden by system UI; floating buttons overlapping content.
- Navigation integrity: back/up behaviour inconsistent after configuration change; duplicate toolbars; drawers permanently open when they should collapse.
- Content clipping: dialogs cut off; lists hidden behind app bars; chips/buttons truncated.
- State loss: form entries cleared on resize; scroll position jumps; selected item lost in two-pane layouts.
- Input ergonomics: keyboard (IME) covers fields; focus jumps to unexpected views; “Next” action fails to move sensibly.
- Performance: repeated recomposition / re-layout spikes during live resize; jank when dragging window size.
Android’s own guidance warns about letterboxing and layout issues when resizing, and encourages designing for varying sizes and aspect ratios rather than relying on fixed assumptions. (developer.android.com)
Compose-specific checks (what actually breaks)
Compose makes adaptive UI easier, but it also makes it easy to accidentally build “one layout that scales” rather than layouts that reflow.
1) Window size class decisions are stable and intentional
If you branch UI by width size class, ensure the breakpoints match your product requirements, not whatever defaults you copied.
Checks:
- Reflow points happen where users would expect (for example, list-detail becomes two-pane at a sensible width).
- When crossing a breakpoint during live resize, you don’t lose selection state or scroll position.
If you are using Jetpack WindowManager / window size class APIs, keep versions current and verify behaviour on the devices you support; Android’s large-screen ecosystem is moving quickly, especially around desktop-like usage and connected displays. (android-developers.googleblog.com)
2) Remembered state survives configuration changes and resize
The common Compose trap is remember { ... } where you needed rememberSaveable, or state held in a composable rather than in a ViewModel.
Checks:
- Rotate / resize mid-form: inputs remain.
- Rotate / resize mid-checkout: you do not re-trigger network calls or duplicate side effects.
3) Insets are handled, not guessed
On tall/narrow and wide/short windows, system bars and the IME will collide with your layout if you hard-code padding.
Checks:
- Text fields remain visible when keyboard opens.
- Bottom bars and snackbars don’t fight each other.
4) Dialogs and bottom sheets adapt
Many “resizable” failures are really modal UI failures.
Checks:
- Bottom sheets aren’t locked to an unusable height on wide/short windows.
- Dialog content scrolls instead of clipping.
Legacy Views checks (the ones that cost you days)
If you still have Views (or a hybrid Compose-in-View / View-in-Compose app), the breakpoints tend to fail differently.
1) ConstraintLayout and “match_parent” assumptions
Wide screens expose layouts that were only ever tested at 360–411dp widths.
Checks:
- Constraints don’t produce “infinite whitespace” with tiny content stuck to one edge.
- Minimum sizes exist where needed.
2) Fragments and multi-pane layouts
Large screens tempt you into “just show both fragments”, but that has knock-on effects:
- Back stack semantics change
- Deep links route incorrectly
- The “selected item” state becomes ambiguous
Your audit should include navigating via:
- Cold start deep link
- In-app navigation to the same destination
- Back from detail to list
3) Activity/manifest constraints are no longer your safety net
Historically, teams “fixed” UI by declaring orientation, aspect ratio, or resizability settings in the manifest.
Android 16’s large-screen behaviour deliberately reduces how much you can rely on that. The documentation calls out that orientation, aspect ratio, and resizability restrictions are overridden for apps targeting API 36 on large screens. (developer.android.google.cn)
So the right question is not “how do we prevent resizing”, but “how do we ensure resizing doesn’t break the flow”.
If your product requires a single fixed UI geometry to function, you should assume Android 16 large-screen users can and will escape it.
How to run the audit efficiently (without turning it into a month)
You are trying to catch classes of failures, not pixel-perfect UI polish.
- Pick two critical flows: onboarding/login and the primary money-making workflow.
- For each flow, run all 10 window configurations.
- Record only hard failures:
- Can’t complete flow
- Can’t reach primary action
- Data loss / state loss
- Overlapping/clipped UI that hides meaning
- Fix failures in this order:
- Navigation/state correctness
- Reachability
- Layout reflow
- Visual polish
- Re-run the same 10 screens after each fix batch.
If you need to test the Android 16 behaviour before fully moving targetSdk, Android documents a compat flag (UNIVERSAL_RESIZABLE_BY_DEFAULT) to force the behaviour for testing. (developer.android.com)
When the answer is “do not do this”
A few anti-patterns show up repeatedly when teams scramble late.
- Do not ship a “tablet layout” that is just your phone layout centred with massive margins. It looks broken, and users interpret it as neglect.
- Do not lock orientation “because it’s easier”. On Android 16 large screens, that assumption is less reliable, and even where it holds, OEMs and device owners can apply overrides in some scenarios. (developer.android.com)
- Do not treat resize bugs as “UI issues” if they involve state, navigation, or idempotency. Those are correctness bugs; they will surface as support tickets and churn.
Where codeversols can help (briefly, and honestly)
If you have a deadline-driven targetSdk bump and you need confidence you won’t ship large-screen regressions, this is the kind of audit we run with teams: pairing with your engineers to identify breakpoints, fix the highest-risk flows in Compose and Views, and leave you with a repeatable checklist you can run for every release.
Close
Android 16 (API 36) turns resizability and orientation flexibility into the baseline expectation on large screens, whether your app was designed for it or not. (developer.android.google.cn)
If you run the 10-screen audit before you submit to Play, you catch the real failures: clipped controls, broken navigation, and state loss under resize. Do it once, bake it into release gates, and “works on my phone” stops being your definition of done.
