Keep runtime version and target SDK separate
Google’s Android 15 targeted-behaviour guidance applies the new focus requirement to apps targeting API level 35. The app must be the top app or be running a foreground service to request focus. Do not describe this as an identical new restriction for every older-targeting app merely because a phone runs Android 15.
Record runtime version, target SDK and the user action that requested playback. These identify the conditions being reviewed. A reproduction from a visible activity and one triggered while the app is backgrounded are not equivalent test cases.
Observe focus results before starting audio
Log the return from the focus request and respect a failure rather than treating the call as a grant. Google’s audio-focus guide also describes delayed focus gain and its listener requirements for applicable requests. A delayed request needs the actual later grant callback before playback is treated as authorised by that focus flow.
Keep focus ownership separate from mute, destination and media decoding. A granted request does not prove the correct headset is selected or that the media resource is playable. A failed request likewise does not establish an unsupported codec or damaged speaker.
Do not use foreground service as a universal bypass
Meeting the audio-focus condition by running an appropriate foreground service does not remove Android’s separate rules for starting that service. Google documents restrictions on foreground-service launches from the background for apps targeting Android 12 or later, with specified exceptions.
Use the documented media-playback architecture and permitted launch context. Do not recommend repeatedly starting a service from arbitrary background callbacks, disabling protections or asking the viewer to grant unrelated permissions. Preserve the actual service-launch outcome separately from the focus-request result.
Let one component own focus management
Google advises that ExoPlayer can manage focus when setAudioAttributes is called with handleAudioFocus true, and that the app should then avoid its own competing focus request/response logic. Check that architecture before adding another layer of manual handlers.
No app was built or run for this article. A useful developer record contains the trigger, visibility/service state, focus result, callbacks and playback outcome. It supports a specific execution-state investigation without promising a universal user-facing switch for every silent Android app.
Sources and scope
Scope notes distinguish published documentation, supplied information and editorial methods. They do not report a hands-on service test.
- Android: API35 audio-focus requirement — Primary targeted change: top app or foreground service, otherwise failed request.
- Android: manage audio focus — Primary focus-result/delayed-listener and ExoPlayer ownership guidance.
- Android: foreground-service launch — Primary separate background-launch restrictions; indexed body inspected, no executable workaround claimed.
