Android 17 ignores your orientation lock: the targetSdk 37 adaptive migration (2026)

Summary. Android 17 shipped on 16 June 2026, and for any app that targets API level 37 it ignores screenOrientation, setRequestedOrientation(), resizeableActivity="false", minAspectRatio and maxAspectRatio on every display whose smallest width is above 600 dp. There is no opt-out this time. Android 16 gave you a temporary one in 2025; Android 17 removed it. Google puts the installed base at "over 580 million large screen devices", Samsung unveils its next foldables at Galaxy Unpacked in London on 22 July 2026, and Google Play will require new apps and updates to target API level 37 in August 2027. Games, identified by the android:appCategory flag, stay exempt. Everyone else gets one job: make the app fill whatever window it is handed.

The change is small to describe and expensive to ignore. Four things break first: stretched layouts, buttons pushed off-screen, skewed camera previews, and lost user state. All four have fixes that are a few lines of Compose.

What Android 17 actually changed

Android 17 reached most supported Pixel devices on 16 June 2026, and the source went to the Android Open Source Project the same day. Matthew McCullough, VP of Product Management, Android Developer, framed the release this way: "Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance."

The mechanism is narrow. From Google's behaviour-change documentation: "For apps targeting Android 17 (API level 37) or higher, orientation, resizability, and aspect ratio restrictions no longer apply on displays whose smallest width is greater than 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used."

Read that once more. The trigger is your targetSdk, not the user's OS version. An app on an Android 17 device that still targets API 36 keeps the old behaviour, because Android 16 shipped a temporary opt-out and it still applies at that target level. The day you bump to 37, the opt-out is gone.

Android 17 is also in beta on handsets, tablets and foldables from Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo and Xiaomi, so this is not a Pixel-only concern.

The exact attributes that stop working

Google's February 2026 guidance lists the ignored attributes and their ignored values precisely. Nothing new was introduced after Android 16; what changed is that you can no longer decline it.

Two escape hatches survive, and neither is a strategy. Screens smaller than sw600dp are untouched, so a phone in portrait behaves as it always did. And users can explicitly opt in to your app's requested behaviour through the device's aspect ratio settings, which is a per-user choice you do not control.

Why this is landing now

Google's own number for the addressable base is "over 580 million large screen devices in the hands of users", cited alongside the forthcoming launch of Googlebooks, described in the same post as "the next generation of ChromeOS built on the Android stack". That is the commercial argument for the platform change: the large-screen surface is no longer a rounding error, so Google stopped letting apps pretend it does not exist.

The retail timing is sharper than the platform timing. Samsung will host Galaxy Unpacked in London on 22 July 2026 at 2 p.m. BST, and its own invitation says the next Galaxy devices "are set to deliver more personal and adaptive experiences". Samsung's current book-style foldable, the Galaxy Z Fold7, lists at ₹1,74,999 in India for the 12 GB/256 GB variant, with 512 GB and 1 TB options above it, and sells for about ₹1,67,999 after the standing ₹7,000 bank discount. Those are the devices where a portrait-locked app looks worst, in the hands of the customers who complain loudest.

The real cost is usually the migration, not the code.

The four failure modes, and the code that fixes them

Google's developer relations engineer Miguel Montemayor set out the common breakages: "For apps that have historically restricted orientation and aspect ratio, we commonly see issues with skewed or misoriented camera previews, stretched layouts, inaccessible buttons, or loss of user state when handling configuration changes."

Those four cover most of what a QA pass will surface in the first hour on a tablet emulator.

1. Stretched layouts

The pattern that causes it is fillMaxWidth or match_parent on a card, form or text field. On a phone it looks correct. On an unfolded foldable in landscape the same card runs the full width of the window, and a line of body text becomes unreadable. The fix is a maximum width, not a maximum aspect ratio:

            Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}
          

widthIn caps the component and fillMaxWidth still lets it breathe below the cap. The content stays legible at 300 dp on a phone and at 300 dp on a 12-inch tablet, with the surplus space becoming margin rather than stretched text.

2. Buttons pushed off-screen

Short windows are the problem, not wide ones. A Save or Login button anchored at the bottom of a non-scrollable column disappears when a foldable opens in landscape, and if nothing scrolls, the user is stuck mid-flow with no way to submit. One modifier fixes it:

            Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)
          

Google's guidance pairs the two directly: "By combining max-width constraints with vertical scrolling, you ensure your app remains functional and usable, regardless of how wide or short the app window size becomes." Treat that as the minimum bar for every screen with a primary action, not as an edge case.

3. Skewed camera previews

This one is the most expensive to retrofit, because the bug is arithmetic, not layout. Apps assume a fixed relationship between the sensor orientation and the device orientation, and once the window can be any shape, the assumption fails. Google ranks four options:

One line in that guidance is worth more than the rest of the section: "screen size should not be used to determine the dimensions of the camera viewfinder; use window metrics instead. Otherwise you risk a stretched camera preview." Your app may be running in a third of a split screen, in a desktop window, or on a connected display. The screen is not the window.

There is also a version floor. Google's note is blunt: "You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices." If you ship a camera and you have not moved CameraX, that is the first ticket.

4. Lost user state

Window size changes stop being rare events. As Google puts it: "Users may rotate their device, fold/unfold it, or resize your app dynamically in split-screen or desktop windowing modes." Each of those destroys and recreates the activity by default, and an app that never handled it properly resets scroll positions, wipes half-filled forms, and loses navigation history.

Android 17 quietly improves the default. The system no longer restarts activities for configuration changes that do not require a full redraw, specifically CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN and CONFIG_COLOR_MODE. Running activities get onConfigurationChanged() instead. If your app relied on the restart to reload resources, you now have to ask for it back with the new android:recreateOnConfigChanges manifest attribute.

The adaptive APIs Google wants you on

The launch post is specific about the target architecture, and it is Compose. Android 17 ships an AI-assisted "Jetpack Compose adaptive skill", and the components it steers you toward are worth knowing by name:

• NavigationSuiteScaffold from the Material 3 Adaptive library, which moves between bottom navigation on phones and edge-anchored navigation rails on large screens.

• Navigation 3 Scenes, specifically ListDetailSceneStrategy and SupportingPaneSceneStrategy, for multi-pane layouts. Google's wording is pointed: use them "instead of fragile fragment transactions".

• Compose 1.11 FlexBox and Grid APIs for adjusting row and column spans as the window changes.

• Compose 1.11 trackpad and mouse support, including TrackpadInjectionScope and performTrackpadInput, for testing laptop-class input on Googlebooks and Desktop Mode.

Behind those APIs sits a bigger decision that will outlast this migration. From the same post: "Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features."

If your app is Views and Fragments, the adaptive work and the Compose migration are the same project now, and pricing them separately will only mislead your own roadmap. Teams weighing that against a cross-platform rewrite should read our comparison of Jetpack Compose and Flutter before deciding, and the hiring-side view of React Native versus Flutter if staffing is the real constraint.

How to test this before the deadline

You do not need a foldable on your desk, and you do not need to bump targetSdk in production to find out what breaks.

The compat-flag route is the one most teams underuse. It decouples "does our UI survive an arbitrary window" from "are we ready to ship at API 37", and those are different questions with different owners. Wiring DeviceConfigurationOverride into the suite you already run is what stops the fix from regressing two sprints later; if that suite is thin, our QA and test automation service exists for exactly this shape of problem.

The Google Play timeline, and a gap worth knowing

Here the platform story and the store story diverge, and the difference is money.

The platform change binds when you target API 37, which is your choice and your schedule. The store change binds on a date. Miguel Montemayor, Developer Relations Engineer, Android, stated it directly in February 2026: "The deadlines for targeting a specific API level are app-store specific. For Google Play, new apps and updates will be required to target API level 37, making this behavior mandatory for distribution in August 2027."

Now the gap. As of 17 July 2026, Google Play's own published target API level requirement pages have not caught up. Both the Play Console Help article and the developer.android.com requirements page, the latter stamped "Last updated 2026-05-18 UTC", still describe the August 31 2025 deadline for Android 15 (API level 35) and say nothing about API level 37. The August 2027 date exists in a developer blog post, not yet in the policy page your compliance team will read.

Plan against the blog post. It is a Google engineer stating a Google Play requirement, and the platform behaviour it describes is already live in a shipped OS. But if your process requires the policy page to say it before a budget is approved, start that conversation now rather than in mid-2027, because roughly 13 months of runway is less than it sounds for an app that has never rendered a second pane.

India-specific considerations

Two things make this land differently for teams building out of India.

The first is device mix. Foldables are premium here in a way they are not in every market: the Galaxy Z Fold7 starts at ₹1,74,999, which is several times the price of the phones most of your users carry. That cuts both ways. The share of your install base on a large screen is small, so the failure is easy to miss in aggregate metrics; but the users on those devices skew toward exactly the high-value segment a D2C, fintech or B2B app cares about. A stretched checkout on a ₹1,74,999 device is not a long-tail bug.

The second is testing budget. Buying a foldable and a tablet per QA pod is real money against an Indian delivery cost base, and it is also unnecessary. The Pixel Fold and Pixel Tablet emulator images with targetSdkPreview = "CinnamonBun" reproduce the behaviour, and DeviceConfigurationOverride puts it in CI. Spend on one physical foldable for final acceptance, not on a device lab.

Where your app handles personal data, the adaptive work also touches your DPDP posture, because more configuration changes mean more state being saved, restored and sometimes logged. The Digital Personal Data Protection Act 2023 does not say anything about aspect ratios, but a form that silently repopulates from a cached bundle is a data question as much as a UX one. Teams working through that alongside a build should read our note on DPDP compliance costs for Indian startups.

For cross-platform teams, the same pressure arrives from the other side: Flutter's move to make Impeller mandatory on Android and iOS is covered in our Impeller migration guide, and Apple's parallel forcing function for iOS teams is the UISceneDelegate migration. The pattern across all three is the same: the platform removes an escape hatch that a generation of apps quietly depended on.

A migration order that works

Do it in this sequence. It front-loads the cheap wins and leaves the expensive rework where you can scope it.

1. Update CameraX to 1.5.2 or 1.6.0+ if you touch the camera at all. This is a crash, not a layout nit.

1. Turn on UNIVERSAL_RESIZABLE_BY_DEFAULT and run your existing regression pack on a Pixel Tablet emulator. Log what breaks; do not fix yet.

1. Fix state preservation first. Lost form data is the failure users report as "the app is broken", and it is independent of visual polish.

1. Cap widths with widthIn and make every primary-action screen scrollable. This clears most of the visual defects for a day of work.

1. Only then reach for NavigationSuiteScaffold and Navigation 3 Scenes. Real multi-pane layouts are a design decision, not a modifier, and they need a designer in the room.

1. Bump targetSdk to 37 last, once the first five are green.

Steps 1 through 4 are days. Step 5 is where the quarter goes.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified engineering organisation in Gurugram, and our senior-led mobile teams have been shipping adaptive Android work since the Android 16 opt-out made it optional. We audit an existing app against the API 37 behaviour on Pixel Fold and Pixel Tablet emulators, fix the state-loss and layout defects first, and scope the multi-pane work honestly rather than pretending a modifier replaces a design. If you are weighing that against a Flutter or Kotlin Multiplatform path, we will tell you when the rewrite is not worth it. Start with a conversation about your codebase.

References

1. Android 17 is here — Android Developers Blog, Matthew McCullough, 16 June 2026.

1. Restrictions on orientation and resizability are ignored — Android Developers behaviour changes, Android 17.

1. Prepare your app for the resizability and orientation changes in Android 17 — Android Developers Blog, Miguel Montemayor, 13 February 2026.

1. Target API level requirements for Google Play apps — Play Console Help.

1. Meet Google Play's target API level requirement — Android Developers, last updated 18 May 2026.

1. Invitation: Galaxy Unpacked July 2026, A New Shape Unfolds — Samsung Global Newsroom, 8 July 2026.

1. Buy Samsung Galaxy Z Fold7, price and offers — Samsung India.

1. Google launches Android 17, rolling out now to Pixel — 9to5Google, 16 June 2026.

1. Android 17 stable is officially rolling out to Google Pixels — Android Authority.

1. Android 17 update just went live on your Pixel phone — Droid Life, 16 June 2026.

Last updated: 17 July 2026.