---
title: "AUDIOFOCUS_REQUEST_FAILED in the background on Android 15: your cue needs a foreground service"
canonical: "https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15"
cluster: "Audio Coaching"
primary_query: "audiofocus_request_failed android 15"
last_reviewed: "2026-10-03"
description: "Apps targeting Android 15 can't request audio focus unless they are the top app or run a foreground service. Which service type a workout app should use."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"AUDIOFOCUS_REQUEST_FAILED in the background on Android 15: your cue needs a foreground service\", AIFitnessAPI, https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15"
---
# AUDIOFOCUS_REQUEST_FAILED in the background on Android 15: your cue needs a foreground service
> If your app targets Android 15 (API level 35) or higher, Google documents that it cannot request audio focus unless it's the top app or running a foreground service, and that the request returns AUDIOFOCUS_REQUEST_FAILED otherwise. A workout app speaking cues with the screen off is not the top app, so unless it started a foreground service its first background cue fails silently. The fix is to run the workout in a foreground service started when the user taps start: Google's foreground service types page lists health for long-running fitness use cases such as exercise trackers, and mediaPlayback for continuing audio or video playback in the background, each with its own manifest permission. A second, unrelated cause of the same return value is focus locked by a phone call.
- Canonical: https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15
- Last reviewed: 2026-10-03
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "AUDIOFOCUS_REQUEST_FAILED in the background on Android 15: your cue needs a foreground service", AIFitnessAPI, https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15
---
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`](https://developer.android.com/reference/android/media/AudioManager) reference, the [`AudioFocusRequest`](https://developer.android.com/reference/android/media/AudioFocusRequest) reference and the [Manage audio focus](https://developer.android.com/media/optimize/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."
| When it fails | Likely cause | What to do |
| --- | --- | --- |
| Only with the screen off or the app backgrounded, targeting API level 35 or higher | Not top app and no foreground service | Run the workout in a foreground service |
| During a phone call, in any state | Focus locked by another app | Skip the spoken cue; do not queue it for later |
| Always, even in the foreground with no call | Neither documented cause; we found no third one documented | Log the request and device state before guessing |
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](https://developer.android.com/develop/background-work/services/fgs/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.
| | Health | Media |
| --- | --- | --- |
| `android:foregroundServiceType` | `health` | `mediaPlayback` |
| Manifest permission | `FOREGROUND_SERVICE_HEALTH` | `FOREGROUND_SERVICE_MEDIA_PLAYBACK` |
| `startForeground()` constant | `FOREGROUND_SERVICE_TYPE_HEALTH` | `FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK` |
| Runtime prerequisite | At least one: declare `HIGH_SAMPLING_RATE_SENSORS`, or hold one of `BODY_SENSORS` (API 35 and lower), `READ_HEART_RATE`, `READ_SKIN_TEMPERATURE`, `READ_OXYGEN_SATURATION`, `ACTIVITY_RECOGNITION` | None |
| Google's description | "Any long-running use cases to support apps in the fitness category such as exercise trackers." | "Continue audio or video playback from the background." |
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](/watch-apps/wear-os-exerciseclient-kotlin) 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](https://developer.android.com/media/media3/session/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.
```xml
```
## 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](/engagement/android-live-updates-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](/audio-coaching/android-audio-focus-may-duck).
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.
## Sources
- [developer.android.com/reference/android/media/AudioManager](https://developer.android.com/reference/android/media/AudioManager) — Android 15 note on requestAudioFocus; return values (checked 2026-10-03)
- [developer.android.com/reference/android/media/AudioFocusRequest](https://developer.android.com/reference/android/media/AudioFocusRequest) — Android 15 note (checked 2026-10-03)
- [developer.android.com/media/optimize/audio-focus](https://developer.android.com/media/optimize/audio-focus) — Android 15 note; focus locked during calls (checked 2026-10-03)
- [developer.android.com/develop/background-work/services/fgs/service-types](https://developer.android.com/develop/background-work/services/fgs/service-types) — health and mediaPlayback types, permissions, prerequisites, Play Console declaration (checked 2026-10-03)
- [developer.android.com/media/media3/session/background-playback](https://developer.android.com/media/media3/session/background-playback) — MediaSessionService manifest declaration (checked 2026-10-03)
## FAQ
### Why does requestAudioFocus return AUDIOFOCUS_REQUEST_FAILED when my app is in the background?
If your app targets Android 15 or higher, that is the documented behaviour. Google's requestAudioFocus reference says such an app cannot request audio focus unless it's the top app or running a foreground service, and that the method returns AUDIOFOCUS_REQUEST_FAILED when the app does not meet those requirements. A screen-off workout is not the top app, so it needs a running foreground service. Google's audio focus guide documents a second cause of the same return value: focus locked by another app, such as during a phone call.
[Permalink](https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15#faq-1)
### Which foreground service type should a workout app use so its audio cues keep working?
Our recommendation is health, with mediaPlayback only for apps whose product is audio playback. Google's foreground service types page describes health as covering long-running use cases for fitness apps such as exercise trackers, with the FOREGROUND_SERVICE_HEALTH permission and a runtime prerequisite such as ACTIVITY_RECOGNITION. Google's audio focus note says running a foreground service and names no type, and we found no page limiting the exemption to mediaPlayback. Declare the type that describes what your app is actually doing.
[Permalink](https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15#faq-2)
### When should a workout app start its foreground service so background cues get audio focus?
When the user starts the workout, while the app is in front, not when the screen turns off. The focus request in the background only succeeds if the service is already running. Google also documents while-in-use limits for the health type: you cannot create a health foreground service that uses body sensors while your app is in the background unless you hold the background sensor or background health-data permission for your API level. Starting the service from the start button avoids both problems.
[Permalink](https://aifitnessapi.com/audio-coaching/audiofocus-request-failed-android-15#faq-3)