Audio Focus : concept, modes et gestion dans Android

Qu'est-ce qu'Audio Focus ?

Audio Focus est un système centralisé d'arbitrage audio dans Android. Lorsqu'une application demande le focus, le système vérifie s'il y a un « propriétaire » actif du focus et lui envoie une notification de perte. Le propriétaire peut soit réduire le volume (duck), soit mettre la lecture en pause, soit l'ignorer — selon le type de focus.

Avant Android 8.0, le focus était géré via AudioManager.requestAudioFocus(callback, stream, durationHint). À partir d'Android 8.0, AudioFocusRequest a été introduit, ajoutant la possibilité de spécifier le type de demande et la restauration automatique du focus. Dans Android 12, le mécanisme a été renforcé — tous les lecteurs multimédias doivent gérer correctement le focus pour être publiés sur Google Play.

Selon Google I/O 2024, environ 15 % des plaintes d'utilisateurs dans les avis d'applications audio sont liées à la superposition des sons. Une implémentation correcte d'Audio Focus résout ce problème et améliore l'expérience utilisateur de 30 % en temps d'écoute.

Audio Focus et lecture multimédia

Il est important de comprendre qu'Audio Focus ne contrôle pas automatiquement la lecture. Il notifie uniquement l'application des événements de focus. L'application décide elle-même : mettre le lecteur en pause, réduire le volume ou continuer à jouer. Le système ne force pas — cette décision architecturale est laissée au développeur.

L'exception concerne les applications de navigation (Google Maps, Yandex Maps). Elles peuvent demander le type de focus AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK, où le lecteur existant voit son volume réduit tandis que les instructions vocales sont lues par-dessus. Après l'instruction, le lecteur restaure automatiquement le volume.

Comment Audio Focus fonctionne dans Android

Le système maintient un seul propriétaire actif du focus audio. Lorsqu'une nouvelle application demande le focus, le système détermine la priorité et envoie un événement au propriétaire actuel. Si le propriétaire actuel ignore l'événement et continue à jouer fort, le système n'applique aucune sanction — la responsabilité incombe entièrement au lecteur.

La demande de focus inclut un paramètre durationHint qui indique au système la durée estimée : AUDIOFOCUS_GAIN (lecture longue — musique, podcast), AUDIOFOCUS_GAIN_TRANSIENT (courte durée — son de notification, navigation), AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK (courte durée avec permission de réduire le volume du lecteur existant).

En cas de perte de focus, l'application reçoit l'un des trois codes : AUDIOFOCUS_LOSS (perte prolongée — une autre application a lancé de la musique), AUDIOFOCUS_LOSS_TRANSIENT (perte temporaire — appel, notification), AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK (perte temporaire avec possibilité de réduction du volume). Chaque code nécessite sa propre réaction.

Chaîne d'événements Audio Focus

Un utilisateur écoute de la musique dans l'application A. Un appel arrive — l'application B (téléphone) demande AUDIOFOCUS_GAIN_TRANSIENT. Le système envoie AUDIOFOCUS_LOSS_TRANSIENT à l'application A. Le lecteur se met en pause. Après l'appel, l'application B libère le focus, le système notifie l'application A via AUDIOFOCUS_GAIN — le lecteur reprend la lecture. Toute la chaîne prend moins de 50 ms.

Types et modes de demande Audio Focus

Choisir le bon durationHint est la décision clé lors de l'implémentation d'Audio Focus. Un mauvais choix de type conduit soit à une superposition de sons, soit à un arrêt inutile du lecteur, soit à l'irritation de l'utilisateur.

Particularités d'AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK

Duck est une réduction temporaire du volume du lecteur principal à 20–30 % pendant la lecture d'un son secondaire. Android fournit une API pour le duck manuel via AudioManager.adjustSuggestedStreamVolume, mais la plupart des lecteurs implémentent le duck par leurs propres moyens. Selon la Documentation Android (2026), le traitement du duck ne doit pas durer plus de 3 secondes, après quoi le volume est restauré.

Implémentation d'Audio Focus dans le code

Pour implémenter correctement Audio Focus, vous devez effectuer trois étapes séquentiellement : créer une demande, demander le focus avant la lecture et gérer l'événement dans un callback. L'utilisation d'AudioFocusRequestCompat d'AndroidX media garantit la compatibilité avec toutes les versions d'Android.

Création et exécution d'une demande Audio Focus

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()
}

La demande de focus doit être effectuée avant le début de la lecture chaque fois que l'utilisateur appuie sur Play. Si le résultat est AUDIOFOCUS_REQUEST_GRANTED — commencez à jouer. Si DENIED — affichez un message à l'utilisateur ou reportez la lecture jusqu'à l'obtention du focus.

Callback de changement de focus

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()
        }
    }
}

Dans le callback, il est important de distinguer AUDIOFOCUS_LOSS et AUDIOFOCUS_LOSS_TRANSIENT. Dans le premier cas, le lecteur NE doit PAS reprendre automatiquement — l'utilisateur a explicitement lancé un autre audio. Dans le second, il peut reprendre automatiquement à la réception d'AUDIOFOCUS_GAIN. Le drapeau wasPlayingBeforeLoss aide à se souvenir si la lecture doit être restaurée.

Libération d'Audio Focus

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

L'appel à abandonAudioFocusRequest informe le système que l'application n'a plus besoin du focus. Il est important de l'appeler lors de la mise en pause et de l'arrêt du lecteur. Si le focus n'est pas libéré, une autre application demandant AUDIOFOCUS_GAIN ne recevra pas LOSS et les sons se superposeront.

Gestion de la perte du focus audio

La gestion correcte de la perte de focus est une exigence clé pour passer la révision Google Play. Une gestion incorrecte entraîne des avis négatifs : les utilisateurs se plaignent que la musique continue de jouer pendant un appel ou par-dessus la navigation.

À la réception d'AUDIOFOCUS_LOSS, le lecteur doit s'arrêter et ne reprendre que lorsque l'utilisateur appuie explicitement sur Play. En cas d'AUDIOFOCUS_LOSS_TRANSIENT (appel, notification), le lecteur se met en pause et reprend automatiquement lorsque le focus est restauré. En cas d'AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK, le lecteur réduit temporairement le volume à 20–30 % pendant la lecture de l'audio externe.

Selon le Guide du Développeur Android (2026), le duck doit être implémenté en multipliant le niveau de volume actuel d'AudioTrack par un facteur de 0,2–0,3. N'utilisez pas AudioManager.setStreamVolume — cela modifie le volume système et affecte les autres applications. Le duck est effectué uniquement du côté de son propre lecteur.

Gestion des appels et de la navigation

Lors d'un appel entrant, le système demande automatiquement AUDIOFOCUS_GAIN_TRANSIENT via l'application Téléphone. Le lecteur reçoit AUDIOFOCUS_LOSS_TRANSIENT et se met en pause. Après la fin de l'appel ou si l'utilisateur refuse l'appel, le focus revient — le lecteur reprend automatiquement la lecture s'il s'agit d'un lecteur de musique.

Pour les applications de navigation (Google Maps), AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK est utilisé pendant les instructions vocales. Le lecteur est atténué pendant 2–3 secondes, puis le volume est restauré. Si l'utilisateur écoute un podcast plutôt que de la musique, il est préférable de mettre en pause plutôt que d'atténuer — chaque seconde compte dans les podcasts.

Scénarios d'utilisation typiques

Dans la pratique, les développeurs rencontrent plusieurs scénarios standard où Audio Focus se comporte différemment. Examinons les cas typiques et les réactions correctes.

• Musique + appel — le lecteur se met en pause (AUDIOFOCUS_LOSS_TRANSIENT). Après l'appel, il reprend automatiquement si l'utilisateur n'a pas interagi avec le lecteur.
• Musique + navigation — le lecteur est atténué pendant l'instruction vocale (DUCK). Le volume est restauré après la fin de la phrase.
• L'utilisateur a lancé une autre application — le lecteur reçoit AUDIOFOCUS_LOSS et s'arrête. Reprise uniquement via le bouton Play.
• Vidéo + musique en arrière-plan — le lecteur vidéo demande AUDIOFOCUS_GAIN. Le lecteur de musique reçoit LOSS et s'arrête.
• Recherche vocale (Google Assistant) — l'application reçoit AUDIOFOCUS_LOSS_TRANSIENT, se met en pause et reprend automatiquement après la réponse de l'assistant.

Reprise automatique après une perte de focus

Il est important d'implémenter un drapeau qui mémorise si la musique était en cours de lecture avant la perte de focus. Si l'utilisateur a lui-même mis en pause puis qu'un appel est arrivé — ne pas reprendre. Le drapeau est réinitialisé lors de la pause explicite de l'utilisateur et est défini au démarrage de la lecture.

Selon les recherches UX de Google (2024), la reprise automatique après un appel augmente la satisfaction des utilisateurs de 22 %. Mais si le lecteur reprend après que l'utilisateur a déjà commencé à regarder une vidéo — cela provoque de l'irritation. Le drapeau wasPlayingBeforeLoss empêche les reprises intempestives.