What's New in Android 17 for Developers

By Michael Samuel Naeem · May 3, 2026 · 5 min read

Every Android release lands in two buckets for a working developer: the shiny new APIs you can adopt, and the behavior changes that happen to you whether you like it or not the moment you bump targetSdk. Android 17 (API level 37) is no different, and the second bucket is the one that shows up as one-star reviews if you skip the release notes. This is a practitioner's read — what actually changes in day-to-day app work, what to test, and where the sharp edges are — rather than a marketing recap.

The single most important habit hasn't changed: compileSdk unlocks the APIs, targetSdk opts you into the behavior. You can compile against API 37 to use new capabilities while staying on an older targetSdk, but you don't inherit the mandatory behavior changes until you raise targetSdk to 37. Do that deliberately, with a test pass, not as a reflex.

Adaptive layouts are now the baseline, not a bonus

The clearest through-line across recent releases and into Android 17 is that adaptive UI is no longer optional. Foldables, tablets, desktop windowing, and Chromebooks mean your app runs at sizes and aspect ratios you didn't design for, and the platform increasingly ignores orientation and resize restrictions on large screens. If your app still locks to portrait or assumes a phone-width layout, expect it to be letterboxed or stretched in ways users notice.

The fix is to design around window size classes rather than device types. In Compose that means driving layout from WindowSizeClass and using the adaptive navigation components — the same approach I detail in adaptive layouts with Compose grids and flexbox thinking. Treat "phone in portrait" as one configuration among many, not the default the rest degrade from.

val windowSizeClass = calculateWindowSizeClass(activity)
when (windowSizeClass.widthSizeClass) {
    WindowWidthSizeClass.Compact -> BottomNavScaffold()
    else -> NavigationRailScaffold() // tablets, foldables, desktop windows
}

Edge-to-edge and insets, enforced harder

Recent releases pushed edge-to-edge rendering from opt-in to expected, and Android 17 continues tightening it. Apps that don't handle window insets correctly get content drawn under the status bar or navigation area. If you haven't already, stop assuming a fixed system bar height and consume insets explicitly. I covered the migration in detail in edge-to-edge on Android 16, and the guidance holds: use the insets APIs, test with gesture navigation and three-button navigation, and check the camera-cutout areas on real hardware.

Background and foreground service limits keep tightening

The platform's long march toward battery discipline continues. Expect stricter enforcement around foreground service types, more aggressive limits on what an app can do while cached, and tighter windows for launching activities from the background. Practically, this means:

• Declare accurate foreground service types — a mismatch is increasingly a hard failure, not a warning.
• Move deferrable work to WorkManager rather than clinging to a service; it's the sanctioned path and it adapts to platform limits for you (see WorkManager for reliable background work).
• Re-test any "wake up and do something" flow — geofencing, sync, alarms — because the timing guarantees drift with each release.

Privacy: less ambient access, more explicit intent

The privacy trajectory is consistent: give apps the narrowest data access that satisfies the user's intent. Expect more granular permissions, more use of system photo/media pickers instead of broad storage access, and continued nudging toward the Credential Manager and passkeys over bespoke auth. If your app still requests broad storage or location permissions it doesn't strictly need, Android 17 is a good forcing function to narrow them — users see the scope, and reviewers increasingly reject over-broad requests. This lines up with the broader privacy engineering for mobile direction the whole ecosystem is moving in.

The compatibility checklist I run

When I take an app to a new targetSdk, I work through the same list before shipping:

That last row bites teams with native code: as devices adopt larger memory page sizes, native libraries that assumed 4 KB alignment can fail to load. If you ship NDK code or depend on libraries that do, rebuild and test on a 16 KB device or emulator image.

How to adopt it sanely

Don't chase the release the week it drops. My sequence:

1. Bump compileSdk to 37 and fix deprecations while staying on your current targetSdk. This is low-risk and lets you start using new APIs.
2. Read both behavior-change lists — the "all apps" one and the "targetSdk 37" one. Note what applies to you.
3. Test against an Android 17 device or emulator with your current build to catch the all-apps changes.
4. Raise targetSdk to 37 on a branch, run the checklist above, and ship behind a staged rollout so a regression hits 1% of users, not 100%.

Android releases reward teams that treat the upgrade as a small, tested project rather than a version-number bump. The APIs are worth adopting — adaptive UI and the privacy primitives genuinely make apps better — but the behavior changes are what protect your rating. Read the notes, run the checklist, roll out gradually.

Resources

• Android releases and platform overview
• Behavior changes: apps targeting the latest API
• Support 16 KB page sizes
• Window size classes and adaptive layouts
• Foreground service types
• Display content edge-to-edge