Android 17 Is Out: The Behavior Changes That'll Actually Bite You, Not the Headline Features

Android 17 started rolling out to Pixel devices last week, and the coverage has been exactly what you'd expect: Bubbles, foldable gaming mode, a new screen recording toolbar. All fine, all consumer-facing, none of it is what's going to show up in your crash dashboard next quarter.

The changes that matter to you as a developer are buried in the behavior-changes pages, not the press release. Some of them are silent — your app keeps running, it just behaves differently in ways that don't throw an exception. Those are the dangerous ones. Here's what's actually in API level 37, and what I'd be checking before bumping targetSdkVersion.

1. Your Activity Stops Restarting on Config Changes You're Used To

This is the one most likely to bite you without a single line in a stack trace. The system no longer recreates an Activity for these configuration changes: keyboard presence/hidden state, navigation method, touchscreen, color mode, and UI mode transitions into/out of desk mode.

If any part of your app quietly relies on onCreate() running again to reload a resource, re-read a config qualifier, or reset some state — and plenty of older codebases do exactly that, even unintentionally — that code simply won't fire anymore once you target API 37. You won't get a crash. You'll get stale UI that someone reports as "the app looks wrong after I plugged in a keyboard," and you'll spend an hour confused about why onCreate() isn't being hit.

If you genuinely need the restart behavior, opt back in explicitly:

<activity
    android:name=".PlayerActivity"
    android:recreateOnConfigChanges="keyboard|navigation|touchscreen|colorMode|uiMode" />

I'd treat this as a one-time audit, not a reflexive add-everywhere fix. The whole point of the change is that most apps shouldn't need a full Activity restart for these — if you're storing state correctly in a ViewModel instead of relying on recreation, you're already fine. This is mainly a problem for code that pre-dates ViewModel-based state and never got cleaned up.

2. Background Audio Now Fails Silently, Not Loudly

If you've built anything with ExoPlayer — and I've built three apps around it, Musist, HailUp, and Samachar's video feed — this is the one to actually sit down and test, not skim past.

For apps targeting API 37, audio playback, audio focus requests, and volume changes are now hardened against being triggered from an invalid lifecycle state. If your app isn't in a state the system considers valid for background audio, the call doesn't throw — it just does nothing. Alarm audio is exempted, but regular media playback is not.

The practical failure mode: a user backgrounds your app mid-playback, your foreground service isn't wired up exactly right for the new enforcement, and audio just stops with zero error signal anywhere in your logs. That's a brutal one to debug from a support ticket months after release, because by the time someone reports it you've forgotten this changed.

3. App Memory Limits Are Real Now, and There's a New Way to See Them

Android 17 introduces conservative memory limits enforced by the system to protect overall device stability. If your app gets killed for exceeding them, that's now distinguishable from a generic low-memory kill: ApplicationExitInfo.getDescription() returns "MemoryLimiter" specifically.

Paired with that is a new profiling trigger you can hook into proactively rather than reactively:

// ProfilingManager — new trigger types in API 37
TRIGGER_TYPE_ANOMALY        // capture a heap dump when memory behavior looks abnormal
TRIGGER_TYPE_OOM
TRIGGER_TYPE_COLD_START
TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE

TRIGGER_TYPE_ANOMALY is the interesting one. Instead of waiting for a user to report a crash and trying to repro a memory issue blind, you can capture a heap dump automatically when the system detects anomalous memory growth — which is a much better signal than the LeakCanary-in-debug-builds-only workflow most teams (mine included, until recently) default to. If you've read my memory leaks post, this is the production-side complement to that — LeakCanary catches leaks in dev, anomaly-triggered profiling catches the ones that only show up at scale, in the field, on devices you don't have.

Maintaining a 99.6% crash-free rate across staged rollouts has meant treating OOM kills as seriously as crashes, even though they don't always surface the same way in Play Console. This finally gives a first-party hook to be proactive about it instead of inferring memory pressure from ANR reports after the fact.

4. SMS OTP Reads Are Delayed by 3 Hours — Migrate Now, Not Later

If any app you maintain reads SMS messages programmatically to auto-fill an OTP — a pattern I've seen in more login flows than I'd like to admit, mine included, early on — apps targeting API 37 now have that access delayed by three hours for security reasons. Three hours makes an OTP-based login flow completely unusable.

This isn't a "nice to have eventually" migration. If you're still on direct SMS reads, move to the SMS Retriever API or the SMS User Consent API before you bump target SDK, not after a support queue tells you login is broken. Both APIs were designed for exactly this OTP auto-fill case and don't carry the same security-driven restrictions, since they require an explicit user-visible consent or app-signature-matched message format.

5. Large-Screen Adaptivity Stops Being Optional

This one's been telegraphed for a couple of release cycles, and API 37 is where it becomes enforced rather than recommended. For apps targeting Android 17 running on devices with smallest width ≥ 600dp, the system now ignores these manifest attributes outright:

• android:screenOrientation
• android:resizeableActivity
• android:minAspectRatio
• android:maxAspectRatio

If your app has been quietly relying on locking orientation or blocking resize as a way to avoid dealing with tablet and foldable layouts, that escape hatch is gone on large screens once you target API 37. Devices under 600dp are unaffected, and apps with android:appCategory="game" are exempted — everyone else needs an adaptive layout story.

This is exactly the gap the new Compose Grid API and MediaQuery API are aimed at closing — if you haven't looked at either yet, this is the forcing function. Locking a phone-only layout into place was always going to be a temporary strategy; this release is where "temporary" runs out.

One More Worth a Mention: Cross-Profile Loopback Traffic Is Blocked

Smaller in scope but worth knowing if you support work profiles: cross-profile loopback traffic is now blocked by default on all apps running on Android 17, regardless of target SDK. Loopback traffic within the same profile is unaffected. If you've got any local debugging tooling, dev-only local servers, or inter-process communication that crosses the work/personal profile boundary via loopback, this is the line item that explains why it stopped working.

---

What I'd Actually Do This Week

Don't rush to bump targetSdkVersion to 37 the day it's available — Google gives you a runway before it's mandatory for Play Store submissions, and most of these changes only bite once you actually retarget. But don't wait until that deadline either. The SMS OTP delay and the background audio hardening are the two I'd verify against a real device build this week, independent of your target SDK timeline, because both produce silent failures that are miserable to diagnose after the fact from a support ticket instead of a stack trace.

The large-screen adaptivity enforcement is the one with the longest lead time to actually fix properly, so it's worth starting the audit now even if you're not retargeting for months. Everything else — the config change restart behavior, the memory limit signal, the cross-profile loopback block — is a quick check, not a project.

None of this is glamorous. None of it will make an I/O keynote. But it's the difference between a target SDK bump that ships clean and one that quietly breaks login for three hours after every OTP request.