Google quietly dropped Android 17 Beta 4 last week (build CP21.260330.008) — the final scheduled beta before stable. If you've been meaning to test your app against Android 17 and kept pushing it down the backlog, the window just closed. Stable is weeks out, not months.
More importantly, Android 17 contains one of the most consequential breaking changes for indie developers in years: once your app targets Android 17, you can no longer opt out of large-screen resizability, orientation, and aspect-ratio constraints. That single rule will ship more broken app experiences on tablets and foldables in the next six months than any Android release since 12.
This guide is the practical walkthrough. You'll learn what's actually changing, what breaks in practice, how to fix it without rewriting your app, the other Android 17 APIs worth knowing about, and how to test compatibility before users find the bugs first.
why the large-screen change matters#
Tablets and foldables have been a quiet growth story for Android. Samsung, Pixel Fold, OnePlus Open, and the wave of Chinese foldable OEMs mean that "large-screen Android" is now a legitimate category with tens of millions of active users. Google has been pushing developers to support these form factors for five releases running, mostly through soft nudges: Play Store quality signals, tablet-specific rankings, gentle warnings in Android Studio.
Android 17 is the release where the nudges become requirements. Here's the exact change: for apps that target SDK 36, the resizableActivity="false" flag, the android:screenOrientation="portrait" lock, and the maxAspectRatio constraint are all no longer honored on large-screen devices. Your app will run in whatever configuration the system decides is appropriate for the device, regardless of what you've declared.
For developers who've been treating tablets as a rounding error, this is a problem. A portrait-locked phone app running full-screen on a 13-inch foldable tablet reads as broken — stretched layouts, terrible text sizing, interaction targets that don't make sense. Users don't forgive it. They leave reviews and uninstall.
what actually breaks#
In our testing against Beta 4, these are the patterns that fail most often:
Hard-coded portrait activities. Apps that declared android:screenOrientation="portrait" on their main activity now rotate freely on foldables and tablets. If your layouts weren't designed with landscape in mind, you get overflow, clipped views, and UI that was never intended to be seen in that aspect ratio.
Fixed-width layouts assuming phone dimensions. Layouts built with match_parent but designed around 360–420dp widths render as islands of content with huge empty margins on a 1200dp tablet. It's not broken per se, but it looks lazy and reviewers have started flagging it on Play Console's pre-launch reports.
Activity restart on configuration change. Apps that don't handle orientation|screenSize|smallestScreenSize|screenLayout in android:configChanges will restart their activity on every rotation, fold, and unfold. On foldables, this happens constantly. Users see loading spinners every time they unfold their phone.
Camera apps with hard aspect ratios. If your camera preview locked a 4:3 or 16:9 aspect ratio and positioned controls absolutely, the preview now stretches or letterboxes unpredictably on tablet form factors.
how to fix large-screen compatibility without rewriting#
The good news: Google has spent years building tooling for this, and most of it has been ignored. Pulling it off the shelf and using it gets you most of the way there.
Step 1: Adopt WindowSizeClass. If you're on Jetpack Compose, the WindowSizeClass API gives you Compact, Medium, and Expanded width categories. Switch between phone and tablet layouts with a single when expression at the top of your screen composables. For View-based UI, the equivalent is resource qualifiers (layout-sw600dp, layout-sw840dp) or the ConstraintLayout MotionLayout approach.
Step 2: Kill activity restarts on rotation. Add configChanges="orientation|screenSize|smallestScreenSize|screenLayout" to any activity that currently doesn't have it. Handle state preservation via ViewModel or onSaveInstanceState rather than letting the system nuke your process.
Step 3: Audit your AndroidManifest.xml for orientation locks. Remove screenOrientation="portrait" and screenOrientation="landscape" from every activity unless there's a specific reason it has to be locked (a game with fixed camera, a video player in fullscreen). For everything else, let the system decide.
Step 4: Use ResponsiveNavigationBar patterns. On large screens, the bottom tab bar is the wrong navigation pattern — it puts important controls an arm's length away from the user's thumbs. Google's guidance is to switch to a NavigationRail at Medium width and a persistent NavigationDrawer at Expanded. This is a four-hour refactor for most apps and a huge UX improvement.
Step 5: Test on real foldables. The Android emulator foldable presets are fine for layout verification but terrible for interaction testing. If you're shipping to foldables seriously, borrow a Pixel Fold or Galaxy Z Fold from someone or rent time on a device farm. Your app will feel different than you expect.
other android 17 apis worth knowing about#
The large-screen mandate is the headline, but Beta 4 includes several other APIs worth pulling into your app:
Contacts Picker. A system-level picker that grants session-scoped access to specific contact fields. This replaces the need for READ_CONTACTS permission for most use cases — if you just need one email or one phone number from the user, the picker gets you there without the permission grant. Users are much more likely to accept a one-time picker flow than a broad contacts permission, so this will improve your acceptance rates.
EyeDropper API. Lets apps read pixel colors from anywhere on the display without needing screen capture permissions. If you're building a design tool, note-taking app, or anything that involves color selection, this is a cleaner UX than the current MediaProjection approach.
ML-DSA Keystore support. Android Keystore now supports Module-Lattice-Based Digital Signature Algorithm, which is NIST-standardized post-quantum cryptography. For most apps this is irrelevant today, but if you're building anything in finance, healthcare, or identity verification, you probably want to start generating keys with this algorithm because the existing ECDSA keys will eventually need migration.
RAW14 image format. Professional camera apps can now capture 14-bit-per-pixel RAW images via ImageFormat.RAW14. Noteworthy if you're in photography tooling, probably not relevant otherwise.
System Bubbles. Users can now bubble any app by long-pressing the launcher icon. On large screens, a new bubble bar appears in the taskbar. If your app has a messaging-style interaction, consider implementing proper Notification.BubbleMetadata so your bubbles render correctly in the new layout.
how to test compatibility now#
You have three weeks, maybe four, before Android 17 ships stable. Here's the minimum test pass:
Install Beta 4 on a Pixel device if you have one. If you don't, use the Android Studio emulator with the Pixel Tablet and Pixel Fold profiles configured for Android 17. These are close enough to real-device behavior for layout testing, though not for performance profiling.
Run your app through every screen at phone orientation, phone landscape, tablet portrait, tablet landscape, and foldable unfold mid-session. Screenshot every screen. Look for: text that overflows, controls that cluster in the wrong corner, images that stretch, navigation that loses context on rotation.
Ship an internal track build targeting SDK 36 to Play Console. Let the pre-launch report run. Review every screenshot it produces. It'll catch things you'd never find manually.
how stora helps#
Stora's build repair agent runs a target-SDK audit as part of every submission check. When you flip your target SDK to 36, it inspects your manifest for the exact patterns that will break under Android 17 — hard-coded orientations, missing config change handlers, opt-out flags that will no longer be honored. You get a prioritized list of fixes before the submission ever reaches Play Console.
The screenshot generator automatically produces large-screen variants (tablet and foldable unfold states) alongside phone screenshots, which Google now weights in Play Store ranking for tablet users. If your current listing only has phone screenshots, your tablet conversion is silently lower than it should be.
the bottom line#
Android 17 Beta 4 is the last warning shot. Stable ships soon. The large-screen requirements are the biggest breaking change indie Android developers will face this year, and "we'll deal with it later" is increasingly not a viable answer — Play Store tablet rankings, Beta 4 pre-launch reports, and the growing foldable install base all push in the same direction.
The fix isn't hard, but it does require deliberate work. Adopt WindowSizeClass. Remove your orientation locks. Handle configuration changes gracefully. Test on real devices. Do it now, before Android 17 stable lands and users start filing one-star reviews because your app rotates into a broken layout on their Pixel Fold.
The developers who sort this out in the next month will look polished on day one of Android 17 stable. The ones who don't will spend the summer playing catch-up in public.