AUDIOFOCUS_REQUEST_FAILED in the background on Android 15: your cue needs a foreground service

The symptom is specific. Cues work perfectly with the app open. Then, on a device where the app targets Android 15, the user turns the screen off, the first background cue never plays, and requestAudioFocus returns AUDIOFOCUS_REQUEST_FAILED. Nothing crashes and nothing is logged unless you log it.

The cause is one documented sentence, and the fix is the foreground service a workout app arguably should have been running anyway.

The sentence#

Google's requestAudioFocus reference, the AudioFocusRequest reference and the Manage audio focus guide all carry the same note:

"If an app targets Android 15 (API level 35) or higher, it cannot request audio focus unless it's the top app or running a foreground service. This requirement is similar to the existing requirements for audio playback. If an app requests audio focus when it does not meet these requirements, the method returns AUDIOFOCUS_REQUEST_FAILED."

Two conditions, either one sufficient: the app is the top app, or it is running a foreground service. A workout app with the screen off is not the top app. Unless it started a foreground service, it meets neither condition, and the focus request fails, quietly, by return value.

The other reason for AUDIOFOCUS_REQUEST_FAILED#

Do not assume every failure is this one. Google's guide documents a second cause that has nothing to do with targeting: "Sometimes the system cannot grant a request for audio focus because the focus is "locked" by another app, such as during a phone call. In this case, requestAudioFocus() returns AUDIOFOCUS_REQUEST_FAILED."

Log the return value with the app's state (foreground or background, foreground service running or not) and the first two rows separate themselves.

Choosing the foreground service type#

Google's Foreground service types page: "Beginning with Android 14 (API level 34), you must declare an appropriate service type for each foreground service." That means declaring the type in the manifest, requesting the type's permission in addition to FOREGROUND_SERVICE, and, for some types, holding runtime permissions before you start it.

Two types are candidates for a workout app that speaks.

For health, Google adds a while-in-use caution: "you cannot create a health foreground service that uses body sensors while your app is in the background, unless you've been granted the BODY_SENSORS_BACKGROUND (between API level 33 and API level 35) or READ_HEALTH_DATA_IN_BACKGROUND (API level 36) permissions." Start it when the user starts the workout, while the app is in front. For media: "Apps that target Android 15 or higher are not allowed to launch a media playback foreground service from a BOOT_COMPLETED broadcast receiver."

Which one, in our judgement#

Google's focus note says "running a foreground service" and names no type, and we did not find a page restricting the exemption to mediaPlayback. The evidence we have therefore says any running foreground service satisfies the condition.

On that basis, the type should describe what the app is doing. A workout app tracking an exercise matches Google's own description of health ("exercise trackers"), and most already run one to keep sensors and the session clock alive. The cues ride on that service. The Wear OS ExerciseClient walkthrough uses the same pattern for the exercise itself.

mediaPlayback fits an app whose product is audio: a guided-run or audio-class app with transport controls, a media session and a notification the user expects to control. Google's Media3 background playback guide says such an app "requires the FOREGROUND_SERVICE and FOREGROUND_SERVICE_MEDIA_PLAYBACK permissions" and a service declared "with an intent filter of MediaSessionService and a foregroundServiceType that includes mediaPlayback." Declaring mediaPlayback for an app that plays three-second cues makes a claim about the app that is not true.

Google also notes that if your app targets Android 14 or higher, "you'll need to declare your app's foreground service types in the Play Console's app content page," found under Policy, then App content. That is the store-facing half of the same decision.

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_HEALTH" />

<service
    android:name=".WorkoutService"
    android:foregroundServiceType="health"
    android:exported="false" />

Order of operations#

The service has to be running before the first background cue asks for focus, so its start belongs to the moment the workout starts, not the moment the screen turns off. Our sequence:

1. The user taps start, in the foreground. Check the health runtime prerequisite is met.
2. Start the foreground service with FOREGROUND_SERVICE_TYPE_HEALTH and its ongoing notification; the Android ongoing-workout surfaces are covered in Android live updates for a workout.
3. The cue scheduler lives in, or is owned by, that service.
4. Each cue requests AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK, plays only on AUDIOFOCUS_REQUEST_GRANTED, and abandons focus afterwards, as on the MAY_DUCK page.
5. The workout ends: stop the service, then shut down any TextToSpeech instance.

Monday morning#

Check your targetSdk. If it is 35 or higher, background cues need a running foreground service. Log every requestAudioFocus result with whether the app is in the foreground and whether your service is running. If the failures cluster in the background with no service, move the workout into a health foreground service started at workout start. Then run a full workout with the screen off from the first minute.