Android 17 App Compatibility Testing: Large Screens, Orientation, and Resizable Layouts

Last reviewed against current Android Developers and Flutter documentation.

For most of Android's history, an app could decide how it wanted to be shown: lock the activity to portrait, cap the aspect ratio, declare the app non-resizable. On a phone that produced predictable layouts. On a tablet, a foldable or a desktop window, it produced an app that refused to fill the space it was given.

Android 17 removes that escape hatch. For apps targeting Android 17 (API level 37) or higher, orientation, resizability and aspect-ratio restrictions are ignored on large displays. Nothing crashes and nothing warns you — the app simply appears in a window shape you never designed for.

Quick answer

What actually changed in Android 17

Android 17 introduces no new restriction — it removes the ability to avoid an existing one. Android 16 introduced the behaviour and a temporary developer opt-out; Android 17 removes that opt-out, so once you target API 37 the behaviour is unconditional on large displays.

The platform documentation is specific about scope. For apps targeting Android 17 (API level 37) or higher, the following are ignored across large-screen devices in full-screen and multi-window modes:

The visual consequence: your app fills the entire display window regardless of aspect ratio or the user's preferred orientation, and pillarboxing is not used to compensate.

Where the rule does not apply

Three documented exceptions. Know them before you redesign anything:

• Small screens. Screens whose smallest width is smaller than sw600dp. A phone in portrait behaves as before.
• Games. Apps categorised as games via the android:appCategory flag.
• User opt-in. Users can choose the app's default behaviour in the device's aspect-ratio settings — a user decision, not something you can set for them.

One caveat about the threshold. Google's pages do not phrase it identically: the behaviour-changes page says "greater than 600dp", the Android Developers blog says "greater than or equal to 600 dp", and Flutter says "600dp or greater". Treat the boundary as "around sw600dp" and verify against current documentation for devices sitting exactly on it.

Which apps and devices are affected

Two conditions must both be true. Miss either one and nothing changes: your app must target API 37 or higher, and it must be running on a display whose smallest width is above the large-screen threshold.

In practical terms the affected surfaces are tablets, foldables when unfolded, phones in desktop-windowing or freeform mode, connected displays, and any app running in split-screen or resizable windows on those devices. Android 16 already applied this to apps that did not opt out, so if you went through that transition, Android 17 changes nothing further until you bump your target level.

Why fixed-orientation assumptions break

The failures are not random. They cluster around code that assumed a shape instead of measuring one.

Layout maths and constraints. Screens built for a 360dp-wide portrait window with a fixed height run out of vertical space when the window becomes 800dp wide and 400dp tall; content moves below the fold and becomes unreachable if the container does not scroll. Separately, components set to fill the available width look correct on a phone and absurd across a tablet in landscape — Google's guidance is a maximum width constraint such as widthIn(max = 300.dp) in Compose, combined with fillMaxWidth.

Buttons pushed off-screen. Google documents the case where Save or Login buttons at the bottom of a fixed, non-scrolling container render off-screen in landscape on a foldable or tablet, blocking the user completely. The documented fix is a vertical scroll modifier on the container.

Camera preview geometry. The most visible failure. Apps assume a fixed relationship between camera features — aspect ratio, sensor orientation — and device features such as device orientation and natural orientation. On a landscape foldable, or in multi-window or desktop windowing, that produces a preview that is stretched, rotated or cropped. Google's preferred fix is CameraX, whose PreviewView handles sensor orientation, rotation and scaling. The underlying mistake is sizing a viewfinder from screen size instead of window metrics — the camera may occupy only part of the screen.

Symptoms to look for

Android 17 compatibility testing checklist

Test on Android 17 with your app targeting API 37, because the behaviour is conditional on the target level. Two documented ways in: set targetSdkPreview = "CinnamonBun" against an Android 17 beta using Pixel Tablet and Pixel Fold emulators, or enable the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag through the app compatibility framework — the latter useful when your app does not yet target API 36.

Then work through these in order:

1. Portrait phone. Baseline — confirm nothing regressed where restrictions still apply.
2. Landscape phone. If your app was portrait-only, this is the first genuinely new state.
3. Rotate mid-flow. During a form fill, media playback, a download and a login.
4. Tablet, both orientations. Look for stretched content and off-screen actions.
5. Foldable folded, unfolded, and the transition between them.
6. Split-screen with your app on one side.
7. Freeform or desktop window, dragged from narrow-tall to wide-short.
8. Any camera, video or map surface, checked for geometry rather than mere presence.

Testing tablets, foldables and resizable windows

Each exposes a different assumption, so test them as separate scenarios rather than as "large screen".

Tablet. A wide window that stays wide. It exposes unconstrained widths and multi-column layouts that were never built.

Foldable. The interesting part is the transition, not the two endpoints. Folding and unfolding triggers a configuration change, and Google notes foldables introduce display capabilities that can trigger them — so the app must restore state when they occur. Test open, half-open (tabletop), and rotating while open. Camera previews are the most commonly documented casualty.

Split-screen and desktop windowing. The window can become very short, which is where fixed-height layouts break and where a verticalScroll on the main container earns its place. Dragging the divider beats any fixed size, because it produces intermediate widths you would never choose manually.

Google's core app quality guidelines name the behaviours worth checking: display orientation and fold states exposing the same features, the app filling the window in both orientations without letterboxing, and rapid transitions between orientations and fold states without rendering problems or lost state.

For device selection, the general guide to compatibility testing on different devices covers the matrix, and choosing minSdk covers version coverage.

Configuration changes and preserving state

Developers most often underestimate this part, because it fails intermittently and only in states nobody tests.

By default, a configuration change destroys and recreates the activity. Google describes the outcome directly: scroll positions reset to the top, half-filled forms are wiped clean, and navigation history is lost. With restrictions removed, the window changes shape far more often, so those failures go from rare to routine.

What to verify:

• Typed input survives a rotation — every field, not just the focused one.
• Scroll position and navigation history survive — pressing back after a rotation returns to the previous screen, not the start.
• Ongoing work survives — an upload, a download, a timer, a recording. This is about tasks, not only widgets.
• Dialogs and permission prompts behave — a dismissed dialog does not reappear, and a rotation does not trigger a second request loop.

Google's guidance is to save UI state properly. In Compose you can also opt out of recreation so window size changes recompose the UI instead of restarting it. Either approach is valid — assuming the activity stays alive is not.

Flutter-specific considerations

If your app is built with Flutter, the key fact is simple and documented: SystemChrome.setPreferredOrientations is ignored on large displays when your app targets Android 17 or higher. Flutter's breaking-change note states that if you rely on it to lock orientation, it will not hold on large screens.

Three practical implications:

• Remove the lock, do not just tolerate it. Flutter's guidance is to make the app adaptive rather than work around the platform.
• Check every call site. Orientation locks are often scattered — a splash screen, a video player, a form — and each behaves differently once ignored.
• Re-test on Android 16 too if you support it. Flutter notes that apps supporting Android 16 which did not opt out already behave this way, so the two versions can differ from your expectations.

When reporting a layout defect found this way, the bug report template is the fastest way to make it reproducible — include the window size and posture, not just the device model.

Emulator versus real devices

The emulator is good at reproducing specific window sizes and densities on demand, running tablet and foldable configurations without buying hardware, and iterating quickly across API levels. A real device remains better at physical folding and real posture changes, camera geometry and sensor orientation, and performance under real load.

Google provides two tools beyond the emulator: Compose UI Check, which audits your UI and suggests adaptive improvements, and DeviceConfigurationOverride, which simulates display characteristics inside tests. Neither substitutes for a physical foldable if fold behaviour is central to your app.

A pre-launch report surfaces crashes and layout problems on Google's test devices, but it will not tell you whether your login button is off-screen in landscape. That needs a human looking at a window shape you did not design for.

Practical pre-release checklist

• Decide your target level deliberately. Testing on Android 17 is urgent; moving to API 37 is a scheduled decision, with the Google Play deadline documented by Google.
• Inventory your restrictions. Search the manifest and codebase for screenOrientation, setRequestedOrientation, resizeableActivity, minAspectRatio, maxAspectRatio and, for Flutter, setPreferredOrientations.
• Constrain widths, not heights. Replace fill-width assumptions with maximum widths plus scrolling containers.
• Size surfaces from window metrics, never screen size, and check every camera, video and map surface.
• Save state, then break it. Rotate, fold, resize and split-screen through your four most important flows.
• Test the transitions, not just the endpoints — dragging a split-screen divider finds more than two fixed sizes.
• Note which build and target each result came from, because the behaviour depends on your target level.

None of this guarantees Play approval or perfect rendering on every device in existence. It does remove the failure mode where your app is shown in a window shape it was never built for — which is now the normal case on large screens.

Frequently asked questions

Do I have to target API 37 immediately?

No. Testing on Android 17 is separate from changing your target level, and Google's migration guidance notes you can often publish a compatible update without changing targetSdkVersion. The Google Play targeting requirement applies to new apps and updates from the date announced in the current documentation.

Why did my orientation lock stop working?

If your app targets Android 17 or higher and runs on a large display, screenOrientation and setRequestedOrientation() are ignored, including all eight fixed values. On screens smaller than sw600dp they still apply.

Is my game affected?

Games are a documented exception: the restrictions do not apply to apps categorised as games based on the android:appCategory flag. If your app is not classified that way, it is in scope.

Can I still cap the aspect ratio on a tablet?

Not for apps targeting API 37 on large displays. minAspectRatio and maxAspectRatio have no effect there, and pillarboxing is not used to compensate — the app fills the window.

How do I test this without changing my target level?

Enable the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag through the app compatibility framework, or target a preview build with targetSdkPreview = "CinnamonBun" against an Android 17 beta.

Conclusion

Android 17 does not add a new restriction; it stops pretending the old one can be avoided. On a tablet, a foldable or a resizable window, an app targeting API 37 is shown the window the user chose, not the one the manifest asked for.

The work is predictable: find your orientation and aspect-ratio assumptions, replace fill-everything layouts with constrained and scrollable ones, size surfaces from window metrics, and make sure state survives more frequent recreation. Test the transitions, not just the endpoints.

If you want real people exercising your app in landscape, split-screen and on a foldable before your users do, our team runs Google Play closed tests with progress you can watch. You can see how the 12 testers service works whenever it is useful.

Official sources

• Android Developers — Restrictions on orientation and resizability are ignored
• Android Developers Blog — Prepare your app for the resizability and orientation changes in Android 17
• Android Developers — Migrate apps to Android 17
• Android Developers Blog — Android 17 is here
• Flutter — Large screen orientation and resizability restrictions ignored on Android 17
• Android Developers — Core app quality guidelines

Platform behaviour and Google Play targeting requirements change over time. Verify current details in the documentation linked above before relying on them for a release decision.