Android 17 reached Beta 4 on April 16, which Google designates as the final scheduled beta of the cycle. In practical terms, that means the platform APIs are now locked, the headline behavior changes are frozen, and everything between now and the stable release this summer is bug-fixing and polish. If you ship Android apps for a living — or as the indie half of a Play Console account you treat like a side project — this is the window where compatibility testing actually makes sense. Once the stable build is rolling out to Pixel devices in a few weeks, you don't get to be surprised by what's in it.
This is a practical readiness guide. It's not a feature tour. The goal is to walk you through the small set of behavior changes that will actually affect how your app behaves on Android 17 devices, what to test, what to fix, and what to leave alone.
what "platform stability" actually means for you#
Google's "platform stability" milestone is more useful than it sounds. It's the explicit commitment that the platform APIs you compile against and the behavior of system services will not change between now and the stable release. So any compatibility work you do today against Beta 4 will still be valid on launch day. That's the entire point of the milestone — it gives you a stable target to test against without being stuck on a fast-moving beta.
What it does not mean: that your existing Android 16 app is automatically compatible with Android 17 devices. The behavior changes are deliberately gated by targetSdkVersion, but several of them will apply to any app running on an Android 17 device once those devices ship. The first category is the urgent one. The second category is the "you have until your next targetSdk bump" category. Both matter.
the per-app memory cap#
Android 17 introduces a per-app memory limit that scales with the device's total RAM. The cap is set conservatively — Google's framing is that "most" app sessions won't notice — but the apps that will notice are exactly the ones running close to the line today. If your app loads large bitmap caches into memory, keeps decoded images around for fast scrolling, or routinely allocates large ByteArray buffers for media work, you are the audience for this change.
Three things to do, in order of effort:
- Profile your app on an Android 17 Beta 4 emulator under realistic conditions and watch the memory ceiling. Android Studio's profiler will surface OOM signals before the system actually kills you.
- Audit any place you hold onto a full-resolution image after the user is done viewing it. The pattern of "decode once, keep forever" was always sketchy. Now it's a crash.
- If you ship a media-heavy app — photo editor, video player, anything game-like — read the per-app memory cap docs in detail. The exact number depends on the device class, and you'll want to know it.
orientation and large screens are now mandatory#
This is the change that's going to surprise the most indie devs. Apps targeting Android 17 can no longer refuse to comply with screen orientation, resizability, and aspect ratio constraints on large screens. The override mechanisms that let portrait-only apps stay portrait on a tablet, or fixed-aspect apps avoid the letterbox, are gone for apps targeting Android 17.
The honest version of this: tablet and foldable users have been complaining about portrait-locked apps for a decade, and Google has decided not to defend the behavior anymore. If your app declares screenOrientation="portrait" in its manifest and you target Android 17, you're going to ship a tablet experience whether you planned for one or not.
What to do:
- If you target SDK 36 or below, you have time. The change applies when you target Android 17 (API level 37). Plan it into the work for your next target bump.
- If you're already on SDK 37, audit every Activity for hardcoded orientation, resizability, or aspect ratio settings. Decide which ones are genuinely needed (a camera viewfinder, a game) and which were defaults nobody questioned.
- Test on a foldable form factor, not just a tablet. The Android emulator has good foldable images now, and the layout breakage is almost always more obvious in the unfolded state.
The apps that ship cleanly through this transition are the ones that started using WindowSizeClass from the AndroidX Window library two years ago. The ones that hardcoded their layouts to a 360dp-wide phone screen are the ones that are about to find out.
post-quantum cryptography in Android 17#
Beta 4 enables a TLS handshake that defaults to post-quantum key exchange (ML-KEM) on connections to compatible servers. For most app developers this is invisible — the system handles it under the hood — but if your app does anything fancy with networking it's worth being aware of.
The places this can matter:
- You bundle your own TLS stack instead of using the system one. Most apps don't, but a non-trivial number of cross-platform frameworks do.
- You use certificate pinning. Post-quantum doesn't directly conflict with pinning, but the increased handshake size and additional negotiation steps can surface latent bugs in pinning implementations that assumed a smaller handshake.
- You log or proxy TLS traffic for debugging. Old MITM proxies may not understand the new handshake. Your CI may need updating.
If none of this applies to you, the answer is "test your app's network paths on an Android 17 device and confirm nothing broke." Which it probably won't have. But it's a five-minute check that catches the rare case where it did.
the Jetpack Compose v2 testing migration#
This is technically not Android 17 — it's the Jetpack Compose April '26 release — but the timing is close enough that it matters for the same audience. The v2 testing APIs are now the default. The v1 APIs are deprecated. The headline change is that run*ComposeUiTest and create*ComposeRule now use StandardTestDispatcher by default, which is a stricter coroutine execution model than the UnconfinedTestDispatcher used by v1.
What this means in practice: if you have a Compose UI test suite that depends on coroutines launching synchronously (which UnconfinedTestDispatcher allows), some of those tests will now fail with timing-related issues that didn't exist on v1. The fix is usually adding advanceUntilIdle() or runCurrent() calls in your test setup. The migration is well-documented in the AndroidX release notes.
You can opt back into the old behavior by using the deprecated API variants for now, but plan the migration. The deprecation will become removal at some point, and "I'll do it later" Compose tests have a way of accumulating.
the Google Play side of the readiness story#
Google Play also rolled out a stack of policy updates in mid-April that take effect 30 days after the April 15 announcement, which lands them right around the Android 17 stable release window. The big ones for indie devs:
- Contacts permissions. If your app accesses the user's contacts and doesn't strictly need broad access, Google now expects you to use the Android Contact Picker instead of declaring the broad permission. The Contact Picker is a system UI that returns just the contact the user explicitly chose — no permission grant required.
- Account transfer. If your app lets users transfer accounts between developers (this is rarer, but real), you now have to use the official Play Console "Transfer ownership" workflow.
- Location permissions. More restrictive defaults around what a "legitimate" use of background location is.
None of these are individually catastrophic, but stack them on top of an Android 17 readiness pass and there's a non-trivial amount of housekeeping to do before the summer.
a practical week-by-week plan#
If you have not started Android 17 readiness work yet, here is a realistic plan that doesn't require you to drop everything:
This week. Install Android Studio Hedgehog or later, pull down the Android 17 Beta 4 emulator image, run your app's top three user flows. Note what breaks. Don't fix anything yet.
Next week. Decide which of the broken things are blockers (crashes, OOM, layouts that are unusable) and which are cosmetic. Fix the blockers. File the cosmetic ones into your normal backlog.
Two weeks out from stable. Bump targetSdkVersion to 37 in a branch (not main). Run your full test suite. This is where the orientation/large-screen changes hit. Resolve them honestly, not by trying to keep the old behavior.
Stable release week. Push a build. Watch your crash dashboard. The first few days of any Android stable release surface the things you missed in beta.
the stora angle#
Stora's compliance engine watches for the things that go wrong at the boundary between your build and the Play Console: an unsupported targetSdkVersion, a manifest that declares a permission you no longer need under the new policy, a build that quietly broke 64-bit alignment on a native library. The Android 17 behavior changes are exactly the kind of "your build is technically valid, but it's going to crash on most devices in a way the static checker can't see" problem that's hard to catch without actually running the app on the new OS.
We can't replace the part where you open Android Studio and look at your own app. But the compliance engine can catch the obvious manifest, permission, and target-SDK regressions before they go to Play Console review. And the screenshot pipeline regenerates large-screen and tablet variants from your build, so you don't have to chase the "we updated the layout but forgot the store assets" failure mode.
closing#
Platform stability is the part of an Android release cycle where the work is highest leverage. Bugs you find now are bugs you fix on your own schedule. Bugs you find after the stable rollout are bugs you fix with users complaining in your reviews. The behavior changes in Android 17 are not catastrophic, but the ones that bite — orientation enforcement, the memory cap, the Play Console policy stack — are the ones that won't show up in a static analysis or a unit test. Run the app on the emulator. Do it this week. The summer will arrive faster than you expect.