Android 17 was released on 16 June 2026 as API level 37. Behaviour changes of this kind only bite when you raise your targetSdk — which Google Play's rolling target-API policy will eventually force you to do. That makes this a planning problem, not an emergency. The five changes below are the ones I expect to break production apps, ordered by how much work they will cost you.
1. The large-screen resizability opt-out is gone
For apps targeting API 37, orientation, resizability and aspect-ratio restrictions no longer apply on displays whose smallest width exceeds 600dp. The system ignores the legacy escape hatches: the screenOrientation manifest attribute, runtime calls to setRequestedOrientation(), resizeableActivity set to false, and minAspectRatio and maxAspectRatio constraints. On Android 16 you could opt out; on API 37 you cannot.
This is the expensive one. A portrait-locked app that has never been rotated will suddenly render at tablet width, in landscape, and in resizable windows. Expect hardcoded dimensions to overflow, single-column lists to stretch into unreadable full-width rows, and dialogs sized for a 360dp phone to look absurd. Test on a large-screen emulator before you raise targetSdk, not after. The good news is that this is the same work as supporting foldables and Googlebook, so it is not throwaway effort.
2. Certificate transparency is on by default
If your app targets API 37, certificate transparency is enabled by default. On Android 16 it existed but required opting in. Certificate transparency requires that the TLS certificates your app encounters have been published to public CT logs, which defends against a certificate authority issuing a certificate for your domain without your knowledge.
For traffic to well-run public endpoints this changes nothing. It will break connections to internal services using privately issued certificates that were never submitted to a CT log — corporate APIs, on-premise deployments, staging environments behind a private CA. Inventory every host your app talks to, including SDKs you did not write, and confirm each one presents a CT-logged certificate.
3. Native libraries must be read-only
The Safer Dynamic Code Loading protection that Android 14 introduced for DEX and JAR files now extends to native libraries. Every native file loaded through System.load() must be marked read-only. If your app downloads a native library at runtime, or extracts one to a writable location before loading it, that will fail. The fix is straightforward — set the file read-only before loading — but the failure mode is a crash on a code path many apps only exercise in production, so grep for System.load() rather than trusting your test suite to find it.
4. static final fields become genuinely final
Apps targeting SDK 37 or higher can no longer modify static final fields, which lets the runtime optimise more aggressively. Almost no application code does this deliberately. Reflection-heavy test frameworks and mocking libraries do it constantly, as do a handful of older dependency-injection and serialisation libraries. This is unlikely to break your app and reasonably likely to break your instrumentation tests. Update your test dependencies before you raise targetSdk.
5. Local network access now requires a permission
Access to devices on the local network now requires declaring the ACCESS_LOCAL_NETWORK permission. If your app discovers a printer, a Chromecast, a smart bulb, an IoT device, or a development server over the LAN, it must ask. If you do none of those things, ignore this. If you do, note that a runtime permission prompt in the middle of a device-pairing flow is a conversion cliff — request it with context, at the moment the user has asked to find a device, not on first launch.
The performance changes you get for free
Not everything requires work. Android 17 introduces a lock-free MessageQueue architecture for apps targeting SDK 37, and tunes the garbage collector toward more frequent young-generation collections, which reduces pause times for the short-lived allocations that dominate UI code. There is also a system-level contact picker and a customisable photo picker, which let you read a single contact or image without holding the broad, scary permission that makes users abandon onboarding. Adopting the pickers is one of the highest-return privacy changes available: less permission friction, less compliance surface, better conversion.
How to sequence this
Do not raise targetSdk and ship. Raise compileSdk first so you can see deprecation warnings without opting into behaviour changes. Then, on a branch, raise targetSdk and run the app on a large-screen emulator in landscape and in a resizable window — that single test surfaces most of change one. Audit your network hosts for certificate transparency, grep for System.load(), update test dependencies, and only then merge. Check the Play Console for the exact target-API deadline that applies to your app, because that date is what determines how much runway you actually have.