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 concentration pour fonctionner comme prévu dans les cas d'utilisation automobile.

Bien que l’envoi d’une demande de focus soit recommandé, il n’est pas appliqué par le système. 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 devrait pas dépendre du système de mise au point pour le fonctionnement du sous-système audio.

Concentrer les interactions

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

  • Exclusif
  • Rejeter
  • Concurrent

Interaction exclusive

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

Dans les interactions exclusives , une seule application à la fois est autorisée à conserver le focus. Par conséquent, une demande de focus entrante se voit accorder le focus tandis que le détenteur du focus existant perd le focus. Étant donné que les deux applications lisent des médias, une seule application est autorisée à conserver le focus. Par conséquent, la demande de focus de l'application nouvellement démarré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 focus avec un statut de perte qui correspond au type de demande effectuée.

Rejeter l'interaction

Avec les interactions de rejet , la demande entrante est toujours rejetée. Par exemple, lorsque vous essayez d'écouter de la musique pendant qu'un appel est en cours. Dans ce cas, si le numéroteur détient le focus audio pour un appel et qu'une deuxième application demande le focus pour lire de la musique, l'application musicale reçoit AUDIOFOCUS_REQUEST_FAILED en réponse à la demande. Puisque la demande de focus est rejetée, aucune perte de focus n’est envoyée au détenteur de focus actuel.

Interaction simultanée

Les interactions simultanées sont uniques à AAOS. Cela donne aux applications qui demandent la mise au point audio dans la voiture la possibilité de maintenir la mise au point en même temps que d'autres applications. Pour qu’une interaction simultanée ait lieu, les conditions suivantes doivent être remplies. Le:

Si ces critères sont remplis, la demande de focus revient avec AUDIOFOCUS_REQUEST_GRANTED alors que le détenteur du focus actuel n'a aucun changement de focus. Cependant, si le détenteur du focus actuel choisit de recevoir des événements d'esquive ou de faire une pause lorsqu'il est esquivé, le détenteur du focus actuel perd le focus, comme cela se produit avec une interaction exclusive.

Gestion des 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 recommandons fortement que les CarAudioContext autorisés à jouer simultanément soient acheminés vers différents périphériques de sortie.

En disposant de périphériques de sortie séparés pour les flux simultanés, cela permet au HAL d'esquiver l'un des flux avant de les mélanger, ou d'acheminer les flux physiques vers différents haut-parleurs du véhicule. Si les flux logiques sont mélangés au sein d'Android, les gains restent inchangés et fournis dans le cadre du même flux physique.

Par exemple, lorsque la navigation et les médias sont diffusés simultanément, le gain du flux multimédia peut être temporairement réduit (ou esquivé) afin que les instructions de navigation puissent être entendues plus clairement. Alternativement, le flux de navigation pourrait être acheminé vers les haut-parleurs du côté conducteur tandis que les médias continuent de diffuser dans le reste de l'habitacle.

Matrice d'interaction

Le tableau ci-dessous montre la matrice d'interaction telle que définie par CarAudioService . Chaque ligne représente le CarAudioContext du détenteur du focus actuel et chaque colonne représente celui de la demande entrante.

Par exemple, lorsqu'une application multimédia musicale conserve le focus alors qu'une application de navigation demande le focus, la matrice indique que les deux interactions peuvent être lues simultanément, en supposant que les autres critères d' interactions simultanées sont remplis.

En raison des interactions simultanées, il est possible d'avoir plus d'un détenteur de focus. Dans ce cas, une demande de focus entrante est comparée à chacun des détenteurs de focus actuels avant de déterminer quelle interaction appliquer. Dans ce cas, l’interaction la plus conservatrice l’emporte. Rejet, puis exclusif, et enfin concurrent.

Matrice d'interaction de focus audio

Figure 1. Matrice d’interaction de focus 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 actuels du focus CALL de simultanées à rejetées . Si un utilisateur préfère que les instructions de navigation n'interrompent pas un appel, il peut activer ce paramètre. Ceci est conservé pour l'utilisateur et peut être défini de manière dynamique afin que les demandes de focus ultérieures respectent le nouveau paramètre.

Mise au point audio retardable

Dans Android 11, AAOS a ajouté la prise en charge de la demande de mise au point audio retardable . 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 d'orientation aboutit à un état dans lequel la demande retardée peut obtenir l'attention, la demande est accordée.

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

  • Demandes 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 joué longtemps après qu'il soit pertinent.

  • Une seule demande peut être retardée à la fois. Si une demande retardable est effectuée alors qu'il existe déjà une demande retardée, la demande retardée d'origine reçoit un événement de changement AUDIOFOCUS_LOSS et la nouvelle demande reçoit une réponse synchrone de AUDIOFOCUS_REQUEST_DELAYED .

  • Les demandes retardables doivent avoir un OnAudioFocusChangeListener Une fois qu'une demande est retardée, l'écouteur est utilisé pour avertir le demandeur lorsque la demande est finalement accordée ( AUDIOFOCUS_GAIN ), ou si elle est rejetée plus tard ( AUDIOFOCUS_LOSS ).

Demander une mise au point différée

Pour créer une requête qui peut ê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. Lors de la demande, 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 de la mise au point multizone

Pour les véhicules dotés de plusieurs zones audio, la focalisation audio est gérée indépendamment pour chaque zone. En tant que telle, une requête adressée à une zone ne prend pas en compte ce qui détient le focus dans d’autres zones, et n’entraîne pas non plus une perte de focus pour les détenteurs de focus dans d’autres zones. Grâce à cela, la mise au point de l'habitacle principal peut être gérée séparément du système de divertissement du siège arrière, n'interrompant ainsi pas la lecture audio dans une zone par les modifications apportées à la mise au point dans une autre.

Pour toutes les applications, le CarAudioService gère automatiquement le focus. La zone audio d'une demande de focus est déterminée par son UserId ou UID associé (pour plus de détails, voir Routage audio ).

Demander de l'audio à 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 automatiques de zones audio pour utiliser à la place l'ID de zone spécifié. Par conséquent, une application peut émettre des demandes distinctes pour différentes zones audio.

Focus audio HAL

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

Le HAL prend la décision finale quant aux sons qui doivent être prioritaires. Dans cette mesure, les sons d'urgence et critiques pour la sécurité doivent être diffusés, que la HAL reçoive ou non la focalisation audio et doivent continuer à être diffusés de manière appropriée même si la HAL perd la focalisation audio. Il en va de même pour tous les sons requis par les réglementations gouvernementales.

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

ContrôleAudio@2.0

La version 2.0 d'AudioControl HAL introduit ces nouvelles API :

API But
IAudioControl#registerFocusListener Enregistre une instance de IFocusListener auprès de AudioControl HAL. Cet écouteur permet au HAL de demander et d'abandonner le focus audio. Le HAl fournit une instance ICloseHandle à utiliser par Android pour désenregistrer l'écouteur.
IAudioControl#onAudioFocusChange Informe le HAL des changements d'état des 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 identifiant de zone et un type de gain de focus spécifiés.
IFocusListener#abandonAudioFocus Abandonne les demandes de focus HAL existantes pour l’utilisation et l’ID de zone spécifiés.

La HAL peut avoir plusieurs demandes de focus en même temps, mais est limitée à une demande par utilisation et par association d'identifiants de zone. Android suppose que HAL commence immédiatement à jouer des sons pour une utilisation une fois qu'une demande a été effectuée et continue de le faire jusqu'à ce qu'il abandonne le focus.

Outre registerFocusListener , ces requêtes sont oneway de garantir qu'Android ne retarde pas le HAL pendant le traitement d'une requête de focus. Le HAL ne doit pas attendre de se concentrer avant de diffuser des sons critiques pour la sécurité. Il est facultatif pour le HAL d'écouter et de répondre aux changements de focus audio via IAudioControl#onAudioFocusChange .

Service de mise au point audio de voiture OEM

Dans Android 14, AAOS a introduit les services de plug-in OEM de voiture pour permettre la configurabilité de certains composants de la voiture. Pour Car Audio Plugin Service , le service de plug-in permet aux constructeurs OEM de gérer les demandes de focus interceptées par le service audio de la voiture. Cela donne aux OEM plus de flexibilité en termes de gestion des priorités, comme l'exigent les règles et réglementations. En tant que telle, l’interaction audio peut différer selon les fabricants et d’une région à l’autre. Le principe de base de la concentration audio est toujours valable, à savoir que les applications doivent toujours demander la concentration pour une meilleure gestion audio afin d'améliorer l'expérience utilisateur. De manière générale, certaines règles s'appliquent toujours aux demandes de focus audio par les applications :

  • Sans aucun statut, les applications de mise au point audio hautement prioritaire (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité) devraient pouvoir obtenir une mise au point audio de manière transitoire ou permanente.

  • Lorsqu'un focus média est actif :

    • Les applications demandant le focus sur l’utilisation des appels doivent pouvoir recevoir l’appel simultanément ou exclusivement.

    • Les applications demandant le focus sur l’utilisation de la navigation doivent pouvoir recevoir le focus sur la navigation simultanément ou exclusivement.

    • Les applications demandant le focus sur l’utilisation de l’assistant doivent pouvoir recevoir le focus sur l’utilisation simultanément ou exclusivement.

  • Lorsque les applications de mise au point audio haute priorité (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité) sont actives, toute demande de mise au point audio retardée entrante doit être accordée ou retardée selon les besoins.

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