Priorité audio

Avant de démarrer un flux logique, une application demande le focus audio en utilisant les mêmes attributs audio que ceux utilisés pour le flux logique. L'application doit respecter les pertes de focus pour fonctionner comme prévu dans les cas d'utilisation automobile.

Bien qu'il soit recommandé d'envoyer une demande de sélection, le système ne l'impose pas. Par conséquent, considérez la mise au point comme un moyen de contrôler indirectement et d'éviter les conflits pendant la lecture, plutôt que comme un mécanisme de contrôle audio principal. Le véhicule ne doit pas dépendre du système de mise au point pour le fonctionnement du sous-système audio.

Interactions de sélection

Pour prendre en charge AAOS, les demandes de priorité audio sont traitées en fonction des interactions prédéfinies entre le CarAudioContext de la demande et celui des détenteurs de priorité actuels. Il existe trois types d'interactions :

  • Exclusif
  • Refuser
  • Concurrent

Interaction exclusive

Il s'agit du modèle d'interaction le plus couramment utilisé avec Android.

Dans les interactions exclusives, une seule application peut être au premier plan à la fois. Par conséquent, une demande de focus entrante est accordée, tandis que le détenteur du focus existant le perd. Étant donné que les deux applications lisent des contenus multimédias, une seule application est autorisée à conserver le focus. Par conséquent, la demande de priorité de l'application nouvellement lancée est renvoyée avec AUDIOFOCUS_REQUEST_GRANTED, tandis que l'application de musique en cours de lecture reçoit un événement de changement de priorité avec un état de perte correspondant au type de demande qui a été effectué.

Refuser l'interaction

Avec les interactions reject, la demande entrante est toujours refusée. Par exemple, lorsque vous essayez de lire de la musique pendant un appel. Dans ce cas, si le Dialer détient la priorité audio pour un appel et qu'une deuxième application demande la priorité pour lire de la musique, l'application de musique reçoit AUDIOFOCUS_REQUEST_FAILED en réponse à la demande. Étant donné que la demande de focus est refusée, aucune perte de focus n'est envoyée au détenteur actuel du focus.

Interaction simultanée

Les interactions simultanées sont propres à AAOS. Cela permet aux applications qui demandent la priorité audio dans la voiture de la conserver en même temps que d'autres applications. Pour qu'une interaction simultanée ait lieu, les conditions suivantes doivent être remplies. La

Si ces critères sont remplis, la requête de focus renvoie AUDIOFOCUS_REQUEST_GRANTED, tandis que le détenteur actuel du focus ne subit aucun changement de focus. Toutefois, si le détenteur actuel du focus choisit de recevoir des événements de ducking ou de mettre en pause le contenu lorsqu'il est ducké, il perd le focus, comme lors d'une interaction exclusive.

Gérer les flux simultanés

Bien que l'interaction simultanée ait de nombreuses utilisations, soyez prudent lors du mixage et de l'atténuation au niveau matériel sur les périphériques de sortie. Nous vous recommandons vivement de router les instances de CarAudioContext autorisées à être lues simultanément vers différents appareils de sortie.

En disposant de périphériques de sortie distincts pour les flux simultanés, le HAL peut réduire le volume de l'un des flux avant de les mixer, ou router les flux physiques vers différents haut-parleurs du véhicule. Si les flux logiques sont mélangés dans Android, les gains ne sont pas modifiés et sont diffusés dans le même flux physique.

Par exemple, lorsque la navigation et les contenus multimédias sont diffusés simultanément, le gain du flux multimédia peut être temporairement réduit (ou mis en sourdine) afin que les instructions de navigation puissent être entendues plus clairement. Il est également possible de rediriger le flux de navigation vers les haut-parleurs côté conducteur, tandis que le contenu multimédia continue d'être diffusé dans le reste de l'habitacle.

Matrice d'interaction

Ce tableau montre la matrice d'interaction telle que définie par CarAudioService. Chaque ligne représente le CarAudioContext du détenteur actuel du focus, et chaque colonne représente celui de la requête entrante.

Par exemple, lorsqu'une application multimédia musicale détient le focus et qu'une application de navigation le demande, la matrice indique que les deux interactions peuvent se produire simultanément, à condition que les autres critères pour les interactions simultanées soient remplis.

En raison des interactions simultanées, il est possible d'avoir plusieurs détenteurs du focus. Dans ce cas, une demande de focus entrante est comparée à chacun des détenteurs de focus actuels avant de déterminer l'interaction à appliquer. Dans ce cas, l'interaction la plus prudente l'emporte. Refuser, puis exclusif, et enfin simultané.

Matrice d'interaction de la priorité audio

Figure 1 : Matrice d'interaction de la priorité audio.

Dans Android 11, un nouveau paramètre utilisateur a été introduit pour permettre aux utilisateurs de modifier le comportement d'interaction entre la navigation et les appels téléphoniques. Lorsqu'il est défini, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifie l'interaction entre les demandes de focus NAVIGATION entrantes et les détenteurs de focus CALL actuels, en passant de concurrent à rejects. Si un utilisateur préfère que les instructions de navigation n'interrompent pas un appel, il peut activer le paramètre. Cette valeur est conservée pour l'utilisateur et peut être définie de manière dynamique afin que les demandes de focus ultérieures respectent le nouveau paramètre.

Priorité audio différable

Dans Android 11, AAOS a ajouté la prise en charge de la demande de focus audio différable. Cela permet de retarder les demandes de focus non transitoires lorsque leur interaction avec les détenteurs de focus actuels entraînerait normalement leur rejet. Une fois qu'un changement de focus entraîne un état dans lequel la requête différée peut gagner le focus, la requête est accordée.

Règles pour les demandes de focus audio différées

  • Requêtes non transitoires uniquement. Une demande différée ne peut être effectuée que pour des sources non transitoires afin d'éviter qu'un son transitoire ne soit lu longtemps après qu'il est pertinent.

  • Vous ne pouvez différer qu'une seule demande à la fois. Si une requête différable est effectuée alors qu'une requête différée est déjà en cours, la requête différée d'origine reçoit un événement de modification AUDIOFOCUS_LOSS et la nouvelle requête reçoit une réponse synchrone AUDIOFOCUS_REQUEST_DELAYED.

  • Les demandes différables doivent comporter OnAudioFocusChangeListener. Une fois une requête retardée, l'écouteur est utilisé pour informer le demandeur lorsque la requête est finalement accordée (AUDIOFOCUS_GAIN) ou si elle est refusée ultérieurement (AUDIOFOCUS_LOSS).

Demander la sélection différable

Pour créer une requête pouvant être différée :

  1. Utilisez AudioFocusRequest.Builder#setAcceptsDelayedFocusGain.

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();

mDelayedFocusRequest = new AudioFocusRequest
     .Builder(AudioManager.AUDIOFOCUS_GAIN)
     .setAudioAttributes(mMusicAudioAttrib)
     .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
     .setForceDucking(false)
     .setWillPauseWhenDucked(false)
     .setAcceptsDelayedFocusGain(true)
     .build();

  2. Lorsque vous effectuez la requête, gérez la réponse AUDIOFOCUS_REQUEST_DELAYED :

    int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
    // start audio playback
    return;
}
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
     // audio playback delayed to audio focus listener
     return;
}

  3. Lorsque la requête est retardée, l'écouteur de focus gère les changements de focus :

    private final class MediaWithDelayedFocusListener implements
OnAudioFocusChangeListener {
       @Override
       public void onAudioFocusChange(int focusChange) {
           synchronized (mLock) {
               switch (focusChange) {
                   case AudioManager.AUDIOFOCUS_GAIN:
                       … // Start focus playback
                   case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                       … // Pause media transiently
                   case AudioManager.AUDIOFOCUS_LOSS:
                       … // Stop media

Fondu forcé par le système

Android 15 introduit un fondu audio appliqué par le système sur AAOS. Dans Android, le système n'applique pas la priorité audio. Ainsi, bien que les développeurs d'applications soient encouragés à respecter les consignes concernant la priorité audio, le système ne peut pas empêcher une application de continuer à lire de l'audio à un volume élevé même après avoir perdu la priorité audio.

Dans les environnements automobiles critiques pour la sécurité, le respect de la priorité audio est essentiel pour minimiser la distraction du conducteur. Grâce à cette fonctionnalité, le framework audio atténue désormais automatiquement le volume des applications qui perdent le focus audio, pour une expérience audio plus contrôlée et prévisible.

Cette amélioration permet de s'assurer que les applications respectent la décision de perte de focus audio telle que définie par la matrice d'interaction, ce qui évite les conflits de lecture audio.

Conception de haut niveau

La figure suivante illustre la conception générale et la compatibilité avec la fonctionnalité de perte de focus dans les voitures :

Conception de haut niveau pour la fonctionnalité de fondu forcé par le système

Figure 2. Conception de haut niveau pour la fonctionnalité de fondu imposée par le système.

  • Baisse progressive ciblée : l'application système de la baisse progressive dans Android 15 est spécifiquement conçue pour les situations où une application perd la priorité audio, mais continue de lire du contenu audio.
  • Mécanisme de fondu sortant : lorsqu'une application perd le focus audio au profit d'une nouvelle application qui en fait la demande :
    • Le framework audio diminue automatiquement le volume de l'application perdante.
    • Une fois le son estompé, le flux audio est coupé par le système.
    • L'application reçoit ensuite une notification de perte de focus audio.
    • Les applications au comportement inapproprié sont mises en sourdine jusqu'à ce qu'elles récupèrent le focus audio.
    • La logique par défaut consiste à réafficher les applications masquées au bout de deux secondes. Toutefois, les OEM peuvent configurer cette valeur sur n'importe quel délai d'expiration.
    • Le framework audio utilise les configurations OEM pour les opérations de fondu enchaîné et de fondu en ouverture.

  • Fichier de configuration OEM : Android 15 inclut un nouveau fichier de configuration, car_audio_fade_configuration.xml :

    • Ce fichier permet aux OEM de définir des critères pour l'application de la priorité audio du système à une application perdante.
    • Le framework audio n'applique l'atténuation et la mise en sourdine que si l'application perdante correspond aux règles définies par l'OEM dans ce fichier XML.
    • Cela permet aux OEM de personnaliser le comportement de la fonctionnalité en fonction des caractéristiques de l'application ou des types d'utilisation audio.

  • Contrôle des fonctionnalités avec RRO : un nouveau flag de fonctionnalité de superposition de ressources d'exécution (RRO), audioUseFadeManagerConfiguration, a été introduit pour activer ou désactiver cette fonctionnalité :

    • Cette fonctionnalité est désactivée par défaut.
    • Pour activer la perte de focus audio appliquée par le système, les OEM doivent définir cet indicateur sur true.
    • Bien que le framework audio de la voiture s'attende à des définitions de configuration de fondu valides lorsque l'indicateur est activé, l'absence de telles définitions n'entraîne pas automatiquement une exception fatale.
    • Toutes les applications de configurations de fondu doivent avoir des définitions de fondu correspondantes. Il s'agit d'une erreur fatale que d'appeler une configuration de fondu (par son nom) dans le cadre de la configuration audio de la voiture sans fournir de définition valide.
    • Lorsque l'indicateur est désactivé, toutes les définitions de configuration de fondu et toutes les références de configuration sont ignorées.

Configuration du gestionnaire de fondu

Le framework audio d'Android 15 introduit un FadeManagerConfiguration unifié pour permettre aux OEM de contrôler précisément le comportement de fondu audio. Ce framework est illustré dans la figure 3 :

Configuration du gestionnaire de fondu

Figure 3. Configuration du gestionnaire de fondu.

Cette configuration inclut les éléments suivants :

  • Propriétés de la transition "Fondu" : paramètres pour le fondu sortant et le fondu entrant.
    • Peut être défini avec des utilisations ou des attributs audio spécifiques.
    • Permet de définir des durées personnalisées.
    • Ces paramètres permettent de créer VolumeShaper.Configuration.
  • Règles d'atténuation : règles régissant le moment où l'atténuation se produit.
    • Bouton permettant d'activer ou de désactiver le fondu de manière globale.
    • Liste configurable des utilisations audio pouvant être fondues (éligibles à la diminution du volume en cas de perte de focus).
    • Les listes d'exclusion (non fondues) empêchent la diminution du volume des sources audio critiques ou désignées. Ces listes peuvent être basées sur les éléments suivants :
      • Types de contenus
      • Attributs audio
      • UID d'application (ne peuvent être définis qu'au moment de l'exécution)

Configurations OEM

Dans cette section, nous allons examiner les personnalisations OEM disponibles.

Fichier XML de configuration du fondu audio de la voiture

Android 15 introduit un nouveau fichier de configuration, car_audio_fade_configuration.xml, qui permet aux OEM de personnaliser en détail le comportement de diminution du volume audio en cas de perte de focus.

  • Ce fichier XML permet de définir plusieurs configurations de fondu distinctes, chacune nécessitant un nom unique pour la référence croisée dans car_audio_configuration.xml.
  • Ces configurations peuvent être appliquées de manière flexible à différentes zones audio et configurations de zones.
  • Chaque configuration de fondu accepte uniquement les valeurs de durée en millisecondes, que le système utilise ensuite pour générer en interne le VolumeShaper.Configuration correspondant.

Pour obtenir des conseils pratiques sur l'implémentation, consultez les exemples de configurations fournis pour l'émulateur à l'adresse device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

Fichier XML de configuration audio de la voiture

Android 15 introduit une version 4 du fichier car_audio_configuration.xml, qui inclut de nouvelles balises applyFadeConfigs et fadeConfig. La balise applyFadeConfigs peut contenir plusieurs définitions fadeConfig, ce qui permet une configuration flexible des fondus. Chaque définition :

  • Doit inclure un fadeConfig par défaut désigné par isDefault = true.
  • Peut inclure plusieurs définitions fadeConfig transitoires. Ces configurations transitoires sont appliquées spécifiquement lors des interactions de perte de focus audio, et uniquement lorsque l'application qui gagne le focus audio correspond aux critères définis dans la configuration transitoire.

Pour obtenir des conseils pratiques sur l'implémentation, consultez les exemples de configurations fournis pour l'émulateur à l'adresse device/generic/car/emulator/audio/car_audio_configuration.xml.

Extension de service de focus audio OEM

Les OEM qui implémentent un service de mise au point audio personnalisé pour les voitures ont la possibilité de configurer les paramètres de fondu audio en les incluant dans OemCarAudioFocusResult. Pour ce faire, vous pouvez utiliser la méthode de création setAudioAttributesToCarAudioFadeConfigurationMap() :

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

En particulier, les OEM peuvent choisir d'utiliser des paramètres de fondu au démarrage préconfigurés ou d'appliquer des configurations de manière dynamique via leur service de gestion de la priorité audio personnalisé, ce qui leur offre un contrôle adaptable.

Diagramme de séquence

Ce diagramme de séquence illustre le comportement suite à l'attribution du focus audio à App2 et à la perte de focus audio par App1 :

  • Lorsque le service audio de la voiture envoie une perte de focus audio à App1, la lecture du lecteur App1 est atténuée, comme défini par les FadeManagerConfiguration actifs. Une fois l'opération d'atténuation terminée, App1 reçoit le rappel standard de perte de focus audio.
  • Si vous le souhaitez, le son de App1 peut être rétabli après une durée configurable. Les OEM peuvent définir cette durée via Builder#setFadeInDurationForUsage(int, long) en fonction des exigences spécifiques de leurs produits.

Schéma de séquence pour la fonctionnalité de fondu audio de la voiture

Figure 4. Diagramme séquentiel de la fonctionnalité de fondu audio de la voiture.

Gestion du focus multizone

Pour les véhicules comportant plusieurs zones audio, la priorité audio est gérée indépendamment pour chaque zone. Par conséquent, une requête envoyée à une zone ne tient pas compte de ce qui est sélectionné dans les autres zones et n'entraîne pas la perte de la sélection dans les autres zones. Cela permet de gérer la mise au point de la cabine principale séparément d'un système de divertissement à l'arrière, sans interrompre la lecture audio dans une zone en raison des modifications apportées à la mise au point dans une autre zone.

Pour toutes les applications, CarAudioService gère automatiquement la sélection. La zone audio d'une demande de focus est déterminée par son UserId ou UID associé (pour en savoir plus, consultez Routage audio multizone).

Demander de l'audio à partir de plusieurs zones simultanément

Si une application souhaite lire de l'audio dans plusieurs zones simultanément, elle doit demander le focus pour chaque zone en incluant AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID dans le bundle :

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

Ce paramètre de bundle permet au demandeur de remplacer les mappages de zones audio automatiques pour utiliser à la place l'ID de zone spécifié. Par conséquent, une application peut émettre des requêtes distinctes pour différentes zones audio.

Priorité audio HAL

À partir d'Android 11, la HAL est activée pour demander le focus au nom des flux externes. Bien que leur utilisation soit facultative, elle est fortement recommandée pour permettre aux sons externes de participer de manière optimale à l'écosystème Android et pour offrir une expérience utilisateur fluide.

La HAL décide en dernier ressort quels sons doivent être prioritaires. À cet égard, les sons critiques pour la sécurité et les sons d'urgence doivent être émis, que le HAL ait ou non obtenu le focus audio, et doivent continuer à être émis de manière appropriée, même si le HAL perd le focus audio. Il en va de même pour les sons requis par les réglementations gouvernementales.

La HAL doit couper le son des flux Android de manière proactive, le cas échéant, lors de la lecture de sons d'urgence ou critiques pour la sécurité afin de s'assurer qu'ils sont clairement entendus.

AudioControl@2.0

La version 2.0 d'AudioControl HAL introduit les nouvelles API suivantes :

API Objectif
IAudioControl#registerFocusListener Enregistre une instance de IFocusListener avec le HAL AudioControl. Ce listener permet à la HAL de demander et d'abandonner la priorité audio. Le HAL fournit une instance ICloseHandle à utiliser par Android pour annuler l'enregistrement de l'écouteur.
IAudioControl#onAudioFocusChange Avertit le HAL des changements d'état pour se concentrer sur les demandes de focus effectuées par le HAL via IFocusListener, y compris les réponses aux demandes de focus initiales.
IFocusListener#requestAudioFocus Les requêtes se concentrent au nom de HAL pour une utilisation, un ID de zone et un type de gain de focus spécifiés.
IFocusListener#abandonAudioFocus Abandonne les requêtes de mise au point HAL existantes pour l'utilisation et l'ID de zone spécifiés.

Le HAL peut avoir plusieurs demandes de focus en même temps, mais est limité à une demande par association d'ID d'utilisation et de zone. Android suppose que la HAL commence immédiatement à lire les sons pour une utilisation une fois qu'une demande a été faite et continue de le faire jusqu'à ce qu'elle abandonne la priorité.

En dehors de registerFocusListener, ces requêtes sont oneway pour s'assurer qu'Android ne retarde pas la HAL pendant le traitement d'une requête de mise au point. La HAL ne doit pas attendre de gagner le focus avant de lire les sons critiques pour la sécurité. Il est facultatif pour la HAL d'écouter et de répondre aux changements de focus audio via IAudioControl#onAudioFocusChange.

Service de priorité audio OEM pour les voitures

Dans Android 14, AAOS a introduit les services de plug-in OEM de voiture pour permettre la configurabilité de certains composants de voiture. Pour le service de plug-in audio de voiture, le service de plug-in permet aux OEM de gérer les demandes de focus interceptées par le service audio de voiture. Cela offre aux OEM plus de flexibilité pour gérer la mise au point, comme l'exigent les règles et réglementations. Par conséquent, l'interaction de la priorité audio peut varier d'un fabricant à l'autre et d'une région à l'autre. Le principe de base de la mise au point audio reste valable : les applications doivent toujours demander la mise au point pour une meilleure gestion de l'audio afin d'améliorer l'expérience utilisateur. En général, certaines règles s'appliquent toujours aux demandes de focus audio par les applications :

  • Sans aucun focus audio permanent de priorité élevée (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité), les applications doivent pouvoir obtenir le focus audio de manière transitoire ou permanente.

  • Lorsqu'une mise au point sur les contenus multimédias est active :

    • Les applications qui demandent à utiliser le focus d'appel doivent pouvoir recevoir l'appel de manière simultanée ou exclusive.

    • Les applications qui demandent à utiliser la navigation doivent pouvoir recevoir le focus de navigation de manière simultanée ou exclusive.

    • Les applications qui demandent à utiliser le focus de l'Assistant doivent pouvoir le recevoir simultanément ou exclusivement.

  • Lorsque des applications avec un focus audio de priorité élevée (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité) sont actives, toute demande de focus audio différée entrante doit être accordée ou différée selon les besoins.

Bien que ces suggestions ne soient pas exhaustives, elles peuvent aider les applications qui demandent la mise au point à l'obtenir s'il n'existe aucun son actif de haute priorité. Même lorsque des sons de haute priorité sont actifs, les demandes de focus différées doivent toujours être respectées et doivent pouvoir obtenir le focus lorsque le son de haute priorité s'arrête.