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 mise au point

Pour prendre en charge AAOS, les requêtes de priorité audio sont gérées en fonction des 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 en cours de lecture de musique reçoit un événement de changement de mise au premier plan 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 CarAudioContext autorisés à être lus 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

Le tableau ci-dessous présente la matrice d'interaction telle que définie par CarAudioService. Chaque ligne représente l'CarAudioContext du détenteur actuel du focus, et chaque colonne celle 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, et enfin simultané.

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 rejetterait normalement. 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

  • Demandes 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 lu 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 un OnAudioFocusChangeListener. Une fois qu'une requête est retardée, l'écouteur est utilisé pour avertir le demandeur lorsque la requête est finalement accordée (AUDIOFOCUS_GAIN) ou si elle est refusée plus tard (AUDIOFOCUS_LOSS).

Demander un focus retardable

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

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 zone principale de la cabine 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 l'audio 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é critiques 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 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 un focus audio temporairement ou de manière permanente.

  • Lorsqu'un focus multimédia est actif:

    • Les applications qui demandent à utiliser la priorité d'utilisation des appels 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 être sélectionnées 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 les suggestions ci-dessus ne soient pas exhaustives, elles peuvent aider les applications qui demandent la sélection à 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.