Background

To be honest, when I first adapted to targetSdk 35, I really didn't notice the audio changes. My energy was completely taken up by 16 KB page sizes and edge-to-edge. It wasn't until recently, when user feedback online was full of complaints about the app cutting to the background and the audio they were playing suddenly becoming inaudible, that I shifted my subjective thinking from "maybe your phone's system memory needs cleaning" to "it seems like all these problems started after I upgraded to targetSdk 35 — I'm going to take the blame again." So I went back and checked the official documentation, and sure enough, there are some audio changes.

Android 15 — Audio Focus Request Restrictions

Core Change

Android 15 introduces a key restriction for apps targeting SDK version 35 and above: The app must be a top app or be running a foreground service to request audio focus. If these conditions are not met, requestAudioFocus() returns AUDIOFOCUS_REQUEST_FAILED.

Other Related Changes

• BOOT_COMPLETED Restriction: Starting foreground services of types such as mediaPlayback, phoneCall, or microphone from the boot broadcast is prohibited; otherwise, a ForegroundServiceStartNotAllowedException is thrown.
• New mediaProcessing Type: A new mediaProcessing FGS type has been added for scenarios like media transcoding, sharing a 6h/24h time quota with dataSync.
• Direct/Offload Resource Management: When resources are constrained, the system actively discards old AudioTrack instances to allow new requests to succeed.

Android 17 — Background Audio Hardening

There is also an audio-related update in Android 17, which imposes more restrictions on top of Android 15. The changes are as follows:

Main Changes

Android 17 implements silent blocking for three types of background audio interactions:

Interaction Type	Affected APIs	Failure Behavior
Audio Playback	AudioTrack.write(), AAudioStream_write, OpenSL ES, and higher-level libraries such as Media3, ExoPlayer, Oboe	Silent failure, playback is silent, no exceptions, no logs
Audio Focus Request	AudioManager.requestAudioFocus()	Returns AUDIOFOCUS_REQUEST_FAILED
Volume/Ringer Mode Adjustment	setStreamVolume(), setStreamMute(), adjustStreamVolume(), etc.	Silently ignored

Unaffected Conditions

In the following scenarios, regardless of the target SDK, audio restrictions do not apply as long as any one condition is met:

1. There is a visible Activity (including PiP picture-in-picture mode)
2. A foreground service (FGS) is running, and the foreground service type is not SHORT_SERVICE

Additional Restrictions for targetSdk 37

For apps targeting platform 37, if running in the background, they must run a foreground service (FGS) with a "When In Use" (WIU) capability. However, apps that have obtained the exact alarm permission (SCHEDULE_EXACT_ALARM) and are operating a USAGE_ALARM stream are exempt from the WIU requirement.

What is WIU

• Standard FGS: Services started when the app is visible or granted background activity launch capability are granted WIU access.
• Background-started FGS (BFSL): Most are not granted WIU. Exceptions include cases triggered by explicit user intent, such as notification clicks, widget interactions, and media key events.
• System-initiated FGS: Scenarios such as Telecom Jetpack library delegation or VoiceInteractionService can obtain WIU.

So, Android 17's control scope is broader. Originally, Android 15 only required a foreground service when requesting audio focus; now, the entire audio interaction chain requires a foreground service, such as playing audio, requesting focus, and adjusting volume.

Impact on Our App

If these features are not adapted, possible impacts include but are not limited to the following:

Short-term Impact

For apps targeting platform 35 that are already using a foreground service to play audio, the focus request restriction has a minor impact, but the following scenarios require attention:

• Automatic Playback at Startup: If the app tries to request focus when starting in the background (e.g., BOOT_COMPLETED), it will fail.
• Lax Focus Management: Logic that previously relied on the return value of requestAudioFocus needs to handle AUDIOFOCUS_REQUEST_FAILED.
• Background Preloading: Preloading audio content and acquiring focus before the user opens the app will be rejected.

Long-term Impact

For Android 17's background audio hardening, the difficulty escalates:

1. Background Playback Fully Restricted

   • Even with an FGS, it must have WIU capability.
   • If SHORT_SERVICE is used as the foreground service, playback in the background is directly impossible.

2. Background Restrictions on Volume APIs

   • setStreamVolume(), adjustStreamVolume(), etc., silently fail in the background.
   • This significantly impacts apps with independent volume control features.

3. Silent Failures Are Hard to Troubleshoot

   • Playback failures and focus failures do not throw exceptions; they can only be caught during debugging using adb shell cmd audio set-enable-hardening throw.
   • Production environments require log analysis and dumpsys audio for troubleshooting.

4. MediaSessionService Becomes a Hard Requirement

   • The official recommendation is to use the Media3 Jetpack library's MediaSessionService — this is not a suggestion; under Android 17, it is almost the only correct path.

Adaptation Strategies and Best Practices

Migrate to Media3 MediaSessionService

Correctly Handle Foreground Service Lifecycle

Audio Focus Management (Manual Handling Required if Not Using Media3)

Testing and Debugging

Example in logcat output

Summary

As you can see, from Android 15 restricting the conditions for audio focus requests to Android 17 comprehensively hardening background audio interaction rules, Google is once again doing things that optimize the user experience (at the expense of developers). They intend to build an audio playback control system where "the user must have clear intent." In future Android systems, you will no longer be able to freely play audio in the background at will; the system will actively block audio behavior that is not running in the foreground. However, there is a silver lining: our Q3 technical improvement requirements won't have to be a blank sheet anymore.