Audio focus loss is not proof of silence

The prompt finishes. What should the music do?

Imagine reviewing a music app while a navigation prompt plays. The intended experience is simple: the driver hears the direction, then the music returns at its previous level. During the prompt, however, the app might pause, continue at reduced gain, or keep playing behind a system fade. A focus log alone cannot distinguish those outcomes.

This is a proposed integration scenario, not a report of a defect in a car. My recommendation is to review the policy decision, the player response and the output separately. Correlate their timestamps, but do not promote a callback into proof that a speaker became quiet.

Start by writing down the intended behavior for this interruption. Music can often tolerate reduced volume; spoken material may lose meaning when two voices overlap. Decide whether this product should pause or duck before judging a trace. Otherwise, two teams can agree that focus handling works while expecting different listening experiences.

The app's request describes an intention

AudioFocusRequest.Builder lets an app supply audio attributes, a focus-change listener and its preference to pause when ducked. setWillPauseWhenDucked(true) requires a listener; it declares how the app intends to respond. It does not implement the player's pause operation. [2]

For the proposed review, capture both the incoming event and the player action it triggers. A log entry at the listener's first line establishes receipt. A later player-state observation provides different evidence. Keep the original user request as well: a pause caused by an interruption should not erase a subsequent pause chosen by the user.

Delayed focus deserves its own state. AudioManager defines AUDIOFOCUS_REQUEST_DELAYED as a request that has not yet received its grant. Treating it like AUDIOFOCUS_REQUEST_GRANTED would start from the wrong premise. [3] In the UI, distinguish waiting to play from a failed request. If the user cancels while waiting, a later gain should not revive an intention that the user has withdrawn. That cancellation rule is a product recommendation, not a claim that Android maintains your app's intent state.

Concurrent focus still leaves a mixing problem

AAOS supports exclusive, rejected and concurrent interactions. Concurrent focus has specific prerequisites, including the incoming transient-may-duck request and the existing holder's ducking preferences. AOSP recommends separate output devices for streams that need independent downstream handling; mixing them together first limits that control. [1]

The Audio Control HAL documentation describes ducking notifications by zone and output-device address, with the usages holding focus. OEMs enable this path through audioUseHalDuckingSignals and implement the corresponding HAL behavior. Multiple usages can map to one device, which is why the active-usage information matters. [4]

For a navigation-over-music review, record the actual route mapping before blaming the app. If both streams share a path that cannot attenuate them independently at the relevant stage, a correct policy decision will not by itself produce the desired mix. This is a diagnostic possibility to inspect, not a finding about every shared route.

Choose the listening point deliberately. A recording at a digital tap answers a different question from a measurement near the driver's seat. Neither automatically describes a passenger zone. Keep the route, gain settings and observation location with the result so another reviewer can reproduce the same question.

Android 15 does not settle the configuration question

AOSP documents system-enforced fade for AAOS in Android 15. It uses OEM-defined rules to target eligible playback after focus loss. The audioUseFadeManagerConfiguration flag is disabled by default; enabling it and providing applicable configuration are separate from knowing the Android version. [1]

Ask the platform owner for the enabled configuration and the rule that covers the stream under review. Then test the intended behavior on that build. A version label, a configuration file found in a source tree, or a quiet speaker on one attempt does not establish that the expected rule ran.

Keep system intervention distinct from app cooperation. A system fade can reduce output while the player continues advancing. For an audiobook, restoring volume at a later position may mean the listener missed words. An app pause can preserve the position, but its resume behavior still needs review. These outcomes may sound equally quiet during the interruption and feel quite different afterward.

Read the evidence without overclaiming

These are proposed judgments for an integration review, not test results. Their purpose is to prevent a passing observation at one layer from hiding an unexamined outcome at another.

Include recovery in the acceptance result

An interruption review should finish after the prompt, not at its loudest moment. Check the return level, playback position and behavior when the user intervenes. Retain the evidence needed to distinguish app recovery from a change in system gain. Avoid a single success flag whose meaning differs between the app, audio and HMI teams.

For this scenario, I would accept the integration only when the chosen pause-or-duck behavior reaches the intended output and recovery respects the user's latest action. Set product-specific timing and audibility criteria with the responsible teams; this documentation analysis supplies neither safety thresholds nor a vehicle certification.

The official architecture image is reproduced without modification from work created and shared by the Android Open Source Project. AOSP's content-license page specifies Apache 2.0 for documentation and Creative Commons Attribution 4.0 for other site content, and requests image attribution. The separate observation diagram is original Yahagu work. [5]