Audio Focus: Concept, Modes, and Management in Android

What Is Audio Focus?

Audio Focus is a centralized audio arbitration system in Android. When one app requests focus, the system checks if there is an active focus “owner” and sends it a loss notification. The owner can either duck (lower volume), pause playback, or ignore it — depending on the focus type.

Before Android 8.0, focus was managed via AudioManager.requestAudioFocus(callback, stream, durationHint). Starting with Android 8.0, AudioFocusRequest was introduced, adding the ability to specify the request type and automatic focus restoration. In Android 12 the mechanism was strengthened — all media players must correctly handle focus to be published on Google Play.

According to Google I/O 2024, about 15% of user complaints in audio app reviews are related to sound overlapping. Proper Audio Focus implementation solves this problem and improves user experience by 30% in listening time.

Audio Focus and Media Playback

It is important to understand that Audio Focus does not automatically control playback. It only notifies the app about focus events. The app decides itself whether to pause the player, lower the volume, or continue playing. The system does not enforce — this architectural decision is left to the developer.

The exception is navigation apps (Google Maps, Yandex Maps). They can request AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK focus type, where the existing player is ducked while voice prompts play over it. After the prompt ends, the player automatically restores volume.

How Audio Focus Works in Android

The system maintains a single active audio focus owner. When focus is requested by a new app, the system determines priority and sends an event to the current owner. If the current owner ignores the event and continues playing loudly, the system applies no penalties — responsibility lies entirely with the player.

The focus request includes a durationHint parameter that tells the system the estimated duration: AUDIOFOCUS_GAIN (long playback — music, podcast), AUDIOFOCUS_GAIN_TRANSIENT (short-term — notification sound, navigation), AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK (short-term with permission to duck the existing player).

On focus loss, the app receives one of three codes: AUDIOFOCUS_LOSS (long-term loss — another app started music), AUDIOFOCUS_LOSS_TRANSIENT (temporary loss — call, notification), AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK (temporary loss with ducking possibility). Each code requires its own reaction.

Audio Focus Event Chain

A user listens to music in app A. A call comes in — app B (phone) requests AUDIOFOCUS_GAIN_TRANSIENT. The system sends AUDIOFOCUS_LOSS_TRANSIENT to app A. The player pauses. After the call ends, app B releases focus, the system notifies app A via AUDIOFOCUS_GAIN — the player resumes playback. The entire chain takes less than 50 ms.

Audio Focus Request Types and Modes

Choosing the correct durationHint is the key decision when implementing Audio Focus. An incorrect type choice leads either to sound overlapping, unnecessary player stopping, or user irritation.

AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK Specifics

Duck is a temporary volume reduction of the main player to 20–30% while a secondary sound plays. Android provides an API for manual ducking via AudioManager.adjustSuggestedStreamVolume, but most players implement ducking with their own means. According to Android Documentation (2026), duck handling should last no more than 3 seconds, after which the volume is restored.

Audio Focus Implementation in Code

To properly implement Audio Focus, you need to perform three steps sequentially: create a request, request focus before playback, and handle the event in a callback. Using AudioFocusRequestCompat from AndroidX media ensures compatibility with all Android versions.

Creating and Executing an Audio Focus Request

val audioManager = getSystemService(Context.AUDIO_SERVICE) as AudioManager

val focusRequest = AudioFocusRequestCompat.Builder()
    .setFocusGain(AudioManagerCompat.AUDIOFOCUS_GAIN)
    .setOnAudioFocusChangeListener(focusChangeListener)
    .build()

val result = AudioManagerCompat.requestAudioFocus(audioManager, focusRequest)

if (result == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
    startPlayback()
}

The focus request must be made before starting playback each time the user presses Play. If the result is AUDIOFOCUS_REQUEST_GRANTED — start playing. If DENIED — show the user a message or defer playback until focus is obtained.

Focus Change Callback

private val focusChangeListener = AudioManager.OnAudioFocusChangeListener { focusChange ->
    when (focusChange) {
        AudioManager.AUDIOFOCUS_GAIN -> {
            restoreVolume()
            if (wasPlayingBeforeLoss) resumePlayback()
        }
        AudioManager.AUDIOFOCUS_LOSS -> {
            pausePlayback()
            wasPlayingBeforeLoss = false
        }
        AudioManager.AUDIOFOCUS_LOSS_TRANSIENT -> {
            pausePlayback()
            wasPlayingBeforeLoss = true
        }
        AudioManager.AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK -> {
            duckVolume()
        }
    }
}

In the callback, it is important to distinguish between AUDIOFOCUS_LOSS and AUDIOFOCUS_LOSS_TRANSIENT. In the first case, the player should NOT resume automatically — the user explicitly started other audio. In the second, it can resume automatically on receiving AUDIOFOCUS_GAIN. The wasPlayingBeforeLoss flag helps remember whether playback needs to be restored.

Releasing Audio Focus

private fun abandonAudioFocus() {
    AudioManagerCompat.abandonAudioFocusRequest(audioManager, focusRequest)
}

Calling abandonAudioFocusRequest tells the system that the app no longer needs focus. This is important to call on pause and player stop. If focus is not released, another app requesting AUDIOFOCUS_GAIN will not receive LOSS and sounds will overlap.

Handling Audio Focus Loss

Correctly handling focus loss is a key requirement for passing Google Play review. Incorrect handling leads to negative reviews: users complain that music keeps playing during a call or over navigation.

On receiving AUDIOFOCUS_LOSS, the player should stop and not resume until the user explicitly presses Play. On AUDIOFOCUS_LOSS_TRANSIENT (call, notification), the player pauses and resumes automatically when focus is restored. On AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK, the player temporarily reduces volume to 20–30% while external audio plays.

According to the Android Developer Guide (2026), duck should be implemented by multiplying the current AudioTrack volume level by a factor of 0.2–0.3. Do not use AudioManager.setStreamVolume — this changes system volume and affects other apps. Ducking is performed only on the player’s own side.

Handling Calls and Navigation

On an incoming call, the system automatically requests AUDIOFOCUS_GAIN_TRANSIENT through the Phone app. The player receives AUDIOFOCUS_LOSS_TRANSIENT and pauses. After the call ends or if the user declines the call, focus returns — the player automatically resumes playback if it is a music player.

For navigation apps (Google Maps), AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK is used during voice prompts. The player is ducked for 2–3 seconds, then volume is restored. If the user is listening to a podcast rather than music, pausing is better than ducking — every second matters in podcasts.

Typical Usage Scenarios

In practice, developers encounter several standard scenarios where Audio Focus behaves differently. Let us look at typical cases and the correct reactions.

• Music + call — player pauses (AUDIOFOCUS_LOSS_TRANSIENT). After the call, it automatically resumes if the user did not interact with the player.
• Music + navigation — player is ducked during voice prompt (DUCK). Volume is restored after the phrase ends.
• User launched another app — player receives AUDIOFOCUS_LOSS and stops. Resumption only via Play button.
• Video + music in background — video player requests AUDIOFOCUS_GAIN. Music player receives LOSS and stops.
• Voice search (Google Assistant) — app receives AUDIOFOCUS_LOSS_TRANSIENT, pauses and automatically resumes after the assistant’s response.

Automatic Resumption After Focus Loss

It is important to implement a flag that remembers whether music was playing before focus loss. If the user pressed pause themselves and then a call came in — do not resume. The flag is reset on explicit user pause and set on playback start.

According to Google UX research (2024), automatic resumption after a call increases user satisfaction by 22%. But if the player resumes after the user has already started watching a video — this causes irritation. The wasPlayingBeforeLoss flag prevents false resumptions.