# Android 16 ignores portrait locks on tablets: test your app on large screens > Android 16 targeting API 36 ignores orientation and aspect-ratio locks on large screens. Test responsive layouts before your next release. > By Dave · 2026-10-13 > Source: https://otf-kit.dev/blog/android-16-orientation-locks-large-screens Your portrait lock may stop holding on a large Android screen. If the app was built for a narrow phone, a tablet or foldable can expose the layout before you planned to support it. Android 16 changes what a targeted app can assume. For apps targeting API level 36, Android ignores orientation, resizability and aspect-ratio restrictions on displays whose smallest width is at least 600 dp. Instead of staying letterboxed in a portrait frame, an app fills the display window. The user’s preferred orientation wins over the lock. That is the platform behavior. The design work is still yours. ![Byte examines a tablet as a narrow card flow opens into useful side-by-side panels.](https://cdn.otf-kit.dev/blog/android-16-orientation-locks-large-screens/inbody-20261013a.png) ## Check whether the change applies to your app Start with two facts: the app’s target SDK and the display width. Android’s change applies when the app targets Android 16 (API 36) or higher and runs on a qualifying large screen. Android names tablets, the inner display of large-screen foldables, and desktop windowing as examples. Screens below 600 dp smallest width are outside this change. Games and some user-selected compatibility settings are also exceptions. The 600 dp threshold is about the display’s smallest width in density-independent pixels, not a promise that every tablet is affected in the same way. A foldable can move between narrow and wide configurations as it opens. A resizable desktop window can cross layouts without a physical rotation. Check the actual app window, not only the device’s product label. The Android documentation lists the restrictions that no longer control the app on these screens: `screenOrientation`, `resizeableActivity`, `minAspectRatio`, `maxAspectRatio`, and the runtime orientation request APIs. Setting another portrait value does not restore a fixed phone-shaped window on a qualifying display. ## Why the first wide render can look broken A portrait-only screen often carries assumptions that were harmless while the operating system kept its window narrow. A fixed-width card can sit awkwardly in the middle of a wide canvas. A bottom action can drift away from the content it belongs to. A modal laid out for a short viewport can cover its own controls. A chart or workout timer can grow without a useful structure. ![Byte tests a foldable form in multiple window sizes while Dex points to its intact fields and Nova assists.](https://cdn.otf-kit.dev/blog/android-16-orientation-locks-large-screens/inbody-20261013b.png) Android calls out stretched layouts, off-screen animations and components as possible problems. Rotation and window resizing can also recreate an activity. If the screen keeps important state only in a transient view, a user may lose an unfinished form or workout when the window changes. This is why a portrait lock was never a substitute for checking the layout at more than one size. The update makes that shortcut visible on more large-screen configurations. ## Run a focused test before changing code Reproduce the condition in a build that targets API 36, then test on Android 16 with a display at or above the 600 dp threshold. Android’s compatibility framework includes the `UNIVERSAL_RESIZABLE_BY_DEFAULT` flag so teams can exercise the behavior during testing. The Android guidance also points to large-screen emulators. Use a small matrix rather than a single screenshot: | Run | What to inspect | |---|---| | Narrow phone, portrait | Existing screen still fits, scrolls and keeps primary actions reachable. | | Large screen, portrait | Content uses the available width intentionally; it does not become an oversized phone column by accident. | | Large screen, landscape | Navigation, charts, forms and sticky actions remain connected to the content. | | Fold or resize during input | Text, selected items, timers and in-progress work survive the window change. | | Multi-window or desktop window | The screen remains usable when the app window is narrower or shorter than the full display. | Test the screens with the strongest shape assumptions first: sign-in, onboarding, media capture, workout flows, charts, and any view with a bottom action. Check keyboard-open states and dialogs too. A layout that looks balanced without the keyboard may hide its submit button when the viewport shrinks. Include a case just below the 600 dp boundary and one at or above it. That isolates the policy change from unrelated device differences. Keep the target SDK, emulator profile, measured window size and compatibility flag in the test note. When a bug appears, record the screen and the exact resize or fold action that reproduces it; a “tablet layout” label alone is too broad to guide a fix. ## Make the layout respond to the window Treat available space as an input. A compact window can keep a single-column flow. A wider one can use a second pane, a wider grid, or a more useful chart without stretching every control. Keep maximum widths where a long line would hurt readability; let the surrounding layout use extra room. Keep navigation and actions near the content they control. Avoid anchoring every element to one portrait coordinate. When orientation changes or a user resizes a window, preserve the screen’s meaningful state and restore focus where it helps. For long forms, that means keeping entered values and the current step. For a live activity, it means retaining the timer and session context. Do not start by adding a stronger orientation lock. Android can ignore the lock on the large-screen case this change covers. Start by identifying which screen assumptions fail, then let the layout adapt to the window size. The lock can still express a product choice where the platform honors it; it cannot replace a large-screen design. ## Use a temporary opt-out only as a migration bridge Android 16 provides a compatibility property, `android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY`, that can temporarily restore the previous restriction behavior for an activity or the whole application. That can buy time if a release is not ready, but Android documents the opt-out as temporary: it will not apply when targeting API 37. A compatibility switch is not a long-term layout plan. Record where it is enabled, which screens remain untested, and the release that will remove it. Otherwise, the next target-SDK change can bring the same issue back with less time to fix it. ## A practical release checklist Before you ship a target API 36 build, answer these questions: 1. Which screens assume portrait or a fixed aspect ratio? 2. What happens to each screen at 600 dp and above, in both orientations? 3. Does a fold, resize, or rotation keep the user’s current task and entered data? 4. Can the keyboard, dialog, or bottom action make the main control unreachable? 5. Is a compatibility opt-out still present, and what is the plan to remove it before API 37? Keep the test evidence with the build: target SDK, device or emulator configuration, window size, and the screens checked. That gives the next engineer a reproducible failure case instead of “it looked odd on a tablet.” Android 15 edge-to-edge can expose another group of layout assumptions; see [the Android 15 inset checklist](/blog/android-15-edge-to-edge-insets) as a separate check. If you want a React Native and Expo starting point, review the [Fitness & Wellness Kit](/templates/fitness-kit) and its current feature list, then inspect its large-screen behavior for your own app before release. The listed kit price is on [OTF pricing](/pricing). ## Sources - [Android 16 behavior changes for apps targeting API 36](https://developer.android.com/about/versions/16/behavior-changes-16) — scope, large-screen threshold, exceptions, effects, compatibility testing, and the temporary opt-out; checked 13 October 2026.