Guide · 8 min read
Android 17 Resizability Requirement 2027: Fix Portrait-Only Apps Before the August Deadline
Android 17 silently discards the manifest flags developers have used for a decade to keep apps in portrait mode on large-screen devices. If your app targets API level 37 — which Google Play will require for all new submissions and updates by August 2027 — your <code>android:screenOrientation</code> lock, <code>resizeableActivity=false</code> declaration, and aspect-ratio constraints are ignored on every device with a smallest width above 600dp: tablets, foldables, and Chromebooks running the Play Store. The change is not optional, it is not gated behind a user preference, and the apps most likely to break are the ones nobody has touched in two years.
What Android 17 ignores on large screens — and why this change was coming
Android 17 (API level 37) overrides six manifest attributes and runtime APIs on devices whose smallest width exceeds 600dp: screenOrientation, setRequestedOrientation(), resizeableActivity=false, minAspectRatio, maxAspectRatio, and getRequestedOrientation(). Every specific orientation value — portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape — is treated as if it is not declared. The system fills the available display window regardless of what the manifest says.
This change was predictable. Google spent four years building the large-screen optimization ecosystem — the large-screen badge, Compose adaptive layout API, WindowSizeClass, and adaptive navigation patterns — all pointing the same direction. Orientation locks were the last developer escape hatch, producing visibly broken experiences on Galaxy Z Fold devices, large tablets, and Chromebooks where users expect apps to fill the screen. Android 17 closed the hatch. Games are exempt (identified by the android:appCategory="game" manifest flag), and phones with sw smaller than 600dp behave exactly as before.
The practical scope: any non-game app that has ever declared screenOrientation="portrait", relied on resizeableActivity=false to avoid window resizing, or used runtime orientation-lock calls will now behave differently on large-screen hardware. Most of these apps are not targeting API 37 yet — the August 2027 enforcement deadline is the forcing function.
The August 2027 deadline: what "targeting API 37" actually requires for Play Store distribution
Google Play API level requirements work on a rolling deadline: any app update submitted after August 2027 must target API 37 or it will be rejected. Apps that do not update are not removed from the store immediately, but they stop receiving new installs on Android 17 devices once Google enforces the distribution restriction — typically within three to six months of the submission deadline.
The sequence matters: August 2027 is the update submission cutoff. Waiting until July 2027 to start migration gives you one month for a change that typically requires three to eight weeks of testing, especially on large-screen hardware configurations most developers do not have in-house. Developers who fix this in Q4 2026 will spend four hours. Developers who fix it the week of the deadline will spend four days.
The analogous recent deadline was the Android API 36 requirement in August 2026, which required handling predictive back gesture and updated foreground service restrictions. That deadline caught a significant share of apps without preparation because the change involved runtime behavior rather than compile-time errors — exactly the same pattern as the resizability mandate. Treat the API 37 deadline with the same urgency, and start the migration work while the fix is still a four-hour task.
What breaks: portrait layouts, camera orientation bugs, and fixed-aspect-ratio UIs
Three categories of UI break most visibly when orientation locks are ignored. Portrait-only layouts — navigation bars that assume a tall aspect ratio, full-width image crops sized for 9:16 screens, onboarding flows where each step fills a vertically scrolling modal — render with large empty margins or clipped content when the same UI fills a 4:3 tablet window. The layout did not change; the container did, and the layout was never built to adapt.
Camera orientation bugs are the most common hidden failure. Apps that use the camera internally — QR scanners, document capture, AR surfaces — often call setRequestedOrientation() before opening the camera to guarantee a consistent orientation for their image processing pipeline. When that call is ignored, the camera preview renders at the device's current orientation, which can be landscape on a foldable, while the processing code assumes portrait. The result is rotated images, incorrect crop regions, and crashes when downstream bitmap operations receive unexpected dimensions.
Fixed-aspect-ratio UIs — common in reading apps, comic viewers, video players, and tools that letterbox content at a fixed 9:16 ratio — now get letterboxed by the system rather than being allowed to define their own bounds. The rendering is safe but the experience looks wrong: the app's internal letterboxing stacks with the system's, producing a window-within-a-window appearance that users file as a bug. If your app renders any canvas-based assets, also verify that your dimension calculations reference container size dynamically rather than hardcoded portrait pixel values — the same applies when exporting at any specific app store screenshot size.
How to test adaptive behavior without a physical foldable
Testing for Android 17 large-screen behavior does not require a physical tablet or foldable. Android Studio's Device Manager includes pre-configured large-screen emulator profiles: Pixel Tablet (sw 800dp), Pixel 9 Pro Fold in both open and closed states (sw 902dp open, sw 411dp closed), and a generic 7-inch tablet profile. All three exercise the sw>600dp condition that triggers the resizability enforcement. Set up all three and run your app's primary flows in each configuration before starting any layout fixes.
The most productive test is the multi-window test: on the Pixel Tablet emulator, enter split-screen mode alongside another app and resize the divider from 30% to 70% of the screen width. This exercises the full range of window widths your app may be assigned and is the fastest way to find layout components that hardcode pixel dimensions rather than using WindowSizeClass or constraint-based layouts. Any view that renders incorrectly in a 40/60 split will also render incorrectly on the open display of a foldable.
For camera-dependent flows, the Pixel 9 Pro Fold emulator in landscape orientation is the highest-priority test scenario — that is the exact configuration where setRequestedOrientation() calls are silently dropped and camera pipelines receive unexpected input. Run your full camera capture flow in this configuration before assuming your camera code is unaffected. The official reference at developer.android.com/about/versions/17/changes lists every API value that is ignored and every exception condition.
Free side effect: qualifying for Google Play's large-screen optimized badge
Fixing the resizability requirement earns an immediate secondary benefit: Google Play's large-screen optimized badge, which surfaces in search results and editorial placements for users on tablets and foldables. Apps displaying the badge appear above unoptimized competitors in search results for users on qualifying hardware. The Google Play large-screen optimization guide covers the full badge criteria — resizability compliance from the API 37 migration satisfies the foundational requirement without additional work.
The badge criteria beyond resizability are not substantial for most apps: support multi-window mode (addressed by removing resizeableActivity=false), ensure the app does not crash when resized, and provide a layout that actually uses the additional screen real estate rather than stretching a phone-sized layout. Compliance alone earns the badge; the badge alone improves search placement for a meaningful share of Play Store traffic coming from the 20% of Android device activations that are tablets or foldables.
The compound argument for acting now: the resizability work unlocks the large-screen badge, which improves visibility for large-screen users, which feeds the engagement-based ranking signals Google Play shifted to in 2026. See the Play Store retention algorithm guide for how DAU/MAU and Day-30 retention weight into search ranking — an app with stronger engagement from tablet users ranks better for all users, creating a compounding benefit that makes early compliance worth substantially more than last-minute compliance.
The 3-change migration checklist: what most apps need in 2 days
Most non-game apps need three changes, not a full rewrite. Remove resizeableActivity=false and screenOrientation locks from your manifest. Start by deleting these declarations — not adding new code, but removing the code that was preventing the system from doing its job. Once removed, run the emulator test described above to understand what actually breaks. Many apps built on Compose or with ConstraintLayout-based UIs render acceptably without further changes.
Migrate setRequestedOrientation() camera calls. For any flow that calls this API before opening the camera, remove the call and configure your CameraX use case to handle rotation through the setTargetRotation() method instead. CameraX's ImageCapture accepts a target rotation parameter that tells the processing pipeline the expected orientation without forcing the UI into a fixed mode. This typically affects one or two files and requires no changes to downstream image processing code.
Use WindowSizeClass for the single layout that breaks worst. Run the multi-window test, identify the one layout that looks worst at non-phone widths, and add WindowSizeClass from the Jetpack WindowManager library to that layout. Provide an alternate arrangement for WindowWidthSizeClass.EXPANDED. You do not need to rebuild your entire navigation architecture — a two-pane layout for the single highest-visibility screen is sufficient for badge qualification and for a usable tablet experience. Once your layout handles large screens correctly, update your Play Store listing with tablet-formatted screenshots using the screenshot editor; be sure to also produce the correctly-sized app icon assets if your icon references any in-app UI elements.
Start the migration this quarter, not the week of the deadline
August 2027 is eleven months away, which feels like plenty of time until you account for the testing cycle, any discovery of camera orientation bugs, and the screenshot updates your Play Store listing will need once your app renders correctly on a 12-inch display. Starting now means a four-hour fix. Starting in July 2027 means a four-day scramble during an already high-pressure period.
Once your app handles large-screen layouts correctly, use the AppsTemple editor to produce the updated screenshot sets your listing needs — tablet-formatted screenshots and the Play Store feature graphic — to communicate the improved experience to users on large-screen hardware.
Create large-screen screenshots in the editor →
Frequently asked questions
what is the android 17 resizability requirement?
Android 17 (API 37) ignores orientation locks, resizeableActivity=false, and aspect-ratio constraints on devices with smallest width above 600dp — tablets, foldables, and Chromebooks. Apps targeting API 37 must adapt their layout to any window size on large-screen hardware. Games (android:appCategory="game") are exempt. Standard phones with sw under 600dp are unaffected and portrait locks still work normally on them.
does android 17 affect portrait-only apps?
Yes — any app that uses android:screenOrientation="portrait" or calls setRequestedOrientation() will have that behavior overridden on large-screen devices (sw>600dp) when targeting API 37. On standard phones the portrait lock still works. The impact is limited to tablets, foldables, and large-screen Android devices.
when does api 37 become required on google play?
Google Play requires all new app submissions and updates to target API 37 starting August 2027. Apps that do not update are not removed from the store immediately, but they stop receiving new installs on Android 17 devices once the distribution restriction takes effect — typically a few months after the submission deadline.
how do i test for android 17 orientation changes without a physical tablet?
Use Android Studio Device Manager emulator profiles: Pixel Tablet (sw 800dp) and Pixel 9 Pro Fold (sw 902dp open). Test in multi-window split-screen mode at 30/70 and 50/50 splits to find layout components that hardcode dimensions. For camera flows, test in landscape orientation on the Pixel 9 Pro Fold emulator — that is the exact configuration where setRequestedOrientation() calls are ignored.
does fixing android 17 resizability earn the google play large screen badge?
Yes — removing resizeableActivity=false and ensuring your app does not crash when resized satisfies the foundational Google Play large-screen badge requirements. The badge surfaces in search results and editorial featuring for users on tablets and foldables, providing a ranking benefit alongside the API 37 compliance.