Priorité audio

Avant de démarrer un flux logique, une application demande la sélection audio à l'aide des 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 requête de sélection, le système ne l'applique 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 requêtes de priorité audio sont gérées en fonction d'interactions prédéfinies entre le CarAudioContext de la requête 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 est autorisée à conserver la sélection à la fois. Par conséquent, une requête de focus entrante reçoit le focus, tandis que le détenteur du focus existant le perd. Étant donné que les deux applications diffusent des contenus multimédias, une seule d'entre elles est autorisée à conserver la sélection. Par conséquent, la requête de mise au premier plan de l'application nouvellement lancée est renvoyée avec AUDIOFOCUS_REQUEST_GRANTED, tandis que l'application musicale en cours de lecture reçoit un événement de changement de focus avec un état de perte correspondant au type de requête effectuée.

Refuser l'interaction

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

Interaction simultanée

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

Si ces critères sont remplis, la requête de mise au point renvoie AUDIOFOCUS_REQUEST_GRANTED, tandis que le détenteur actuel de la mise au point ne change pas. Toutefois, si le détenteur actuel du focus choisit de recevoir des événements de masquage ou de suspendre son activité lorsqu'il est masqué, il perd le focus, comme cela se produit avec 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 du masquage au niveau matériel sur les appareils de sortie. Nous vous recommandons vivement de router les instances de CarAudioContext autorisées à être lues simultanément vers différents périphériques de sortie.

En disposant de périphériques de sortie distincts pour les flux simultanés, le HAL peut couper l'un des flux avant de les mélanger ou acheminer 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 masqué) afin que les instructions de navigation soient entendues plus clairement. Le flux de navigation peut également être acheminé vers les haut-parleurs du côté conducteur, tandis que les contenus multimédias continuent de se lire dans le reste de l'habitacle.

Matrice d'interaction

Ce tableau présente 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 celui de la requête entrante.

Par exemple, lorsqu'une application multimédia musicale conserve la sélection alors qu'une application de navigation demande la sélection, la matrice indique que les deux interactions peuvent être exécutées simultanément, à condition que les autres critères des interactions simultanées soient remplis.

En raison des interactions simultanées, il est possible d'avoir plusieurs détenteurs de focus. Dans ce cas, une requête 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 conservatrice l'emporte. Rejet, puis exclusif, puis simultané.

Matrice d'interactions avec la priorité audio

Figure 1 : Matrice d'interactions avec 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 requêtes de focus NAVIGATION entrantes et les détenteurs de focus CALL actuels, passant de concurrent à rejects. Si un utilisateur préfère que les instructions de navigation n'interrompent pas un appel, il peut activer ce paramètre. Cette valeur est conservée pour l'utilisateur et peut être définie de manière dynamique afin que les requêtes de mise au point ultérieures respectent le nouveau paramètre.

Priorité audio retardable

Dans Android 11, AAOS a ajouté la possibilité de demander un focus audio retardable. Cela permet de retarder les requêtes de focus non temporaires lorsque leur interaction avec les détenteurs de focus actuels les ferait normalement rejeter. Une fois qu'un changement de focus entraîne un état dans lequel la requête différée peut être sélectionnée, la requête est accordée.

Règles concernant les requêtes de mise au point audio différée

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

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

  • Les requêtes retardables 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 plus tard (AUDIOFOCUS_LOSS).

Demander la sélection retardée

Pour créer une requête pouvant être retardé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 imposé par le système

Android 15 introduit le fondu audio appliqué par le système dans AAOS. Sur Android, la sélection audio n'est pas appliquée par le système. Par conséquent, même si les développeurs d'applications sont encouragés à respecter les consignes sur la priorité audio, le système ne peut pas empêcher une application de continuer à jouer du contenu audio fort même après avoir perdu la priorité audio.

Dans les environnements automobiles critiques pour la sécurité, le respect de la concentration audio est essentiel pour réduire la distraction du conducteur. Grâce à cette fonctionnalité, le framework audio atténue désormais automatiquement les applications qui perdent la priorité 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 la sélection 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 montre la conception générale et la prise en charge de la fonctionnalité de perte de focus dans les voitures:

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

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

  • Évanouissement ciblé:l'application du système d'atténuation dans Android 15 est conçue spécifiquement pour les situations où une application perd la priorité audio, mais continue de diffuser du contenu audio.
  • Mécanisme de fondu:lorsqu'une application perd la sélection audio au profit d'une nouvelle application à l'origine de la requête :
    • Le framework audio atténue automatiquement l'audio de l'application perdante.
    • Après le fondu, le flux audio est coupé par le système.
    • L'application reçoit ensuite une notification de perte de la priorité audio.
    • Les applications qui ne se comportent pas correctement sont mises en sourdine jusqu'à ce qu'elles récupèrent le focus audio.
    • La logique par défaut consiste à faire apparaître les applications qui sont atténué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 et de fondu.

  • 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 déterminer quand l'application perdant l'attention audio est appliquée.
    • Le framework audio n'applique le fondu et le masquage 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 de l'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 ne génère pas automatiquement une exception fatale.
    • Toutes les applications des configurations de fondu doivent avoir des définitions de fondu correspondantes. Il s'agit d'une erreur fatale d'appeler une configuration de fondu (par son nom) dans 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 Android 15 introduit un FadeManagerConfiguration unifié pour fournir aux OEM un contrôle précis sur 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 comprend les éléments suivants:

  • Propriétés de transition "Fondu":paramètres de fondu et de fondu avant.
    • 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 de fondu:règles qui déterminent quand le fondu se produit.
    • Bouton d'activation/de désactivation de la transition.
    • Liste configurable des utilisations audio pouvant être atténués (peuvent être atténués en cas de perte de focus).
    • Les listes d'exclusion (non atténuables) empêchent l'atténuation 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 de l'application (peut être défini uniquement au moment de l'exécution)

Configurations OEM

Dans cette section, nous examinons les personnalisations OEM disponibles.

Fichier XML de configuration de la transition audio de la voiture

Android 15 introduit un nouveau fichier de configuration, car_audio_fade_configuration.xml, qui permet aux OEM de personnaliser de manière extensive le comportement de fondu du son 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 les recoupements dans car_audio_configuration.xml.
  • Ces configurations peuvent être appliquées de manière flexible à différentes zones audio et configurations de zones.
  • Notamment, chaque configuration de fondu n'accepte que des 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 fournies pour l'émulateur situé à device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

Fichier XML de configuration audio de la voiture

Android 15 introduit un fichier car_audio_configuration.xml mis à jour, désormais en version 4, qui intègre de nouvelles balises applyFadeConfigs et fadeConfig. La balise applyFadeConfigs peut contenir plusieurs définitions fadeConfig, ce qui permet de configurer de manière flexible le fondu. Chaque définition:

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

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

Extension de service de mise au point 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, utilisez la méthode de compilation setAudioAttributesToCarAudioFadeConfigurationMap():

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

Plus précisément, 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 mise au point audio personnalisé, offrant ainsi un contrôle adaptable.

Diagramme de séquence

Ce diagramme de séquence illustre le comportement après l'attribution de la sélection audio à App2 et la perte ultérieure de la sélection audio par App1:

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

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

Figure 4. Schéma de séquence de la fonctionnalité de fondu audio de la voiture.

Gestion du ciblage multizone

Pour les véhicules dotés de plusieurs zones audio, la sélection 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 d'autres zones, ni ne fait perdre la sélection aux éléments sélectionnés dans d'autres zones. Ainsi, la sélection de la cabine principale peut être gérée séparément d'un système de divertissement sur les sièges arrière, ce qui permet de ne pas interrompre la lecture audio dans une zone en raison de modifications apportées à une autre.

Pour toutes les applications, CarAudioService gère automatiquement la sélection. La zone audio d'une requête de mise au point est déterminée par son UserId ou UID associé (pour en savoir plus, consultez la section Acheminement 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 la sélection 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 lot permet à l'auteur de la requête de remplacer les mappages automatiques des zones audio pour utiliser l'ID de zone spécifié. Par conséquent, une application peut envoyer des requêtes distinctes pour différentes zones audio.

Priorité audio HAL

À partir d'Android 11, le HAL est activé pour demander la sélection au nom des flux externes. Bien que facultative, l'utilisation de ces API est vivement 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.

Le HAL détermine les sons qui doivent être prioritaires. À cet égard, les sons d'urgence et de sécurité critique doivent être diffusés, que le HAL dispose ou non de la priorité audio, et doivent continuer à être diffusés si nécessaire, même si le HAL perd la priorité audio. Il en va de même pour tous les sons requis par les réglementations gouvernementales.

Le HAL doit couper de manière proactive les flux Android, le cas échéant, lors de la lecture de sons d'urgence ou essentiels à la sécurité pour s'assurer qu'ils sont entendus clairement.

AudioControl@2.0

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

API Objectif
IAudioControl#registerFocusListener Enregistre une instance de IFocusListener avec le HAL AudioControl. Cet écouteur permet au HAL de demander et d'abandonner la priorité audio. HAl fournit une instance ICloseHandle à utiliser par Android pour désenregistrer l'écouteur.
IAudioControl#onAudioFocusChange Informe le HAL des modifications d'état des requêtes de mise au point effectuées par le HAL via le IFocusListener, y compris les réponses aux requêtes de mise au point initiales.
IFocusListener#requestAudioFocus Les requêtes de mise au point sont effectuées au nom du HAL pour une utilisation, un ID de zone et un type de gain de mise au point 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 recevoir plusieurs requêtes de mise au point en même temps, mais il est limité à une seule requête par utilisation et association d'ID de zone. Android suppose que le HAL commence immédiatement à lire des sons pour une utilisation une fois une requête envoyée et continue de le faire jusqu'à ce qu'il abandonne la priorité.

À l'exception de registerFocusListener, ces requêtes sont oneway pour s'assurer qu'Android ne retarde pas le HAL pendant le traitement d'une requête de mise au point. Le HAL ne doit pas attendre d'être en mode actif avant de diffuser des sons critiques pour la sécurité. Il est facultatif pour le HAL d'écouter et de répondre aux modifications de la sélection audio via IAudioControl#onAudioFocusChange.

Service de priorité audio pour les voitures OEM

Dans Android 14, AAOS a introduit les services de plug-in OEM pour les voitures afin de permettre la configuration de certains composants de voiture. Pour le service de plug-in audio pour voiture, le service de plug-in permet aux OEM de gérer les requêtes de mise au point interceptées par le service audio pour voiture. Cela offre aux OEM une plus grande flexibilité en termes de gestion de la mise au point, comme l'exigent les règles et les règlements. Par conséquent, l'interaction de la sélection audio peut varier d'un fabricant à l'autre et d'une région à l'autre. La prémisse 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 règle générale, certaines règles s'appliquent toujours aux requêtes de mise au point audio par les applications:

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

  • Lorsqu'une priorité multimédia est active:

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

    • Les applications qui demandent à être sélectionnées pour l'utilisation de la navigation doivent pouvoir recevoir la sélection de navigation simultanément ou exclusivement.

    • Les applications qui demandent à être sélectionnées pour l'utilisation de l'Assistant doivent pouvoir l'être simultanément ou exclusivement.

  • Lorsque les applications de priorité audio élevée (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité) sont actives, toute requête entrante de mise au point audio différée doit être accordée ou retardée si nécessaire.

Bien que ces suggestions ne soient pas exhaustives, elles peuvent aider les applications qui demandent la mise au premier plan à l'obtenir si aucun son de priorité élevée n'est actif. Même lorsque des sons de priorité élevée sont actifs, les requêtes de mise au point différée doivent être respectées et doivent pouvoir être mises au point lorsque le son de priorité élevée s'arrête.