Priorité audio

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

Bien qu'il soit recommandé d'envoyer une demande de priorité, le système ne l'applique pas. Par conséquent, considérez la priorité 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 priorité pour le fonctionnement du sous-système audio.

Interactions de priorité

Pour prendre en charge AAOS, les demandes 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 à avoir la priorité à la fois. Par conséquent, une demande de priorité entrante est accordée, tandis que le détenteur de priorité existant perd la priorité. Étant donné que les deux applications lisent des contenus multimédias, une seule application est autorisée à avoir la priorité. Par conséquent, la demande de priorité de l'application nouvellement démarrée est renvoyée avec AUDIOFOCUS_REQUEST_GRANTED, tandis que l'application de musique en cours de lecture reçoit un événement de modification de la priorité avec un état de perte qui correspond au type de requête effectuée.

Interaction de refus

Avec les interactions de refus, 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 Dialer a 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 requête. Étant donné que la demande de priorité est refusée, aucune perte de priorité n'est envoyée au détenteur de priorité actuel.

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 simultanément avec 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 demande de priorité est renvoyée avec AUDIOFOCUS_REQUEST_GRANTED, tandis que la priorité du détenteur de priorité actuel ne change pas. Toutefois, si le détenteur de priorité actuel choisit de recevoir des événements de réduction ou de mettre en pause en cas de réduction, il perd la priorité, comme c'est le cas 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 de la réduction 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 périphériques de sortie.

En utilisant des périphériques de sortie distincts pour les flux simultanés, le HAL peut réduire 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 mixés dans Android, les gains ne sont pas modifiés et sont fournis 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 réduit) afin que les instructions de navigation soient plus claires. Vous pouvez également router le flux de navigation vers les haut-parleurs côté conducteur, tandis que les contenus multimédias continuent d'être diffusés 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 de priorité actuel, et chaque colonne représente celui de la requête entrante.

Par exemple, lorsqu'une application multimédia musicale a la priorité et qu'une application de navigation la demande priorité, 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 plusieurs détenteurs de priorité. Dans ce cas, une demande de priorité entrante est comparée à chacun des détenteurs de priorité actuels avant de déterminer l'interaction à appliquer. Dans ce cas, l'interaction la plus conservatrice est prioritaire. 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 priorité NAVIGATION entrantes et les détenteurs de priorité CALL actuels, en passant de simultané à refus. Si un utilisateur préfère que les instructions de navigation n'interrompent pas un appel, il peut activer le paramètre. Ce paramètre est conservé pour l'utilisateur et peut être défini de manière dynamique afin que les demandes de priorité ultérieures le respectent.

Priorité audio différable

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

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

  • Requêtes non transitoires uniquement. Une requête 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 soit pertinent.

  • Une seule requête peut être différée à la fois. Si une requête différable est effectuée alors qu'une requête différée existe déjà, 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 requêtes différables doivent avoir OnAudioFocusChangeListener. Une fois la requête différé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 ultérieurement (AUDIOFOCUS_LOSS).

Demander une priorité différable

Pour créer une requête qui peut ê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 différée, l'écouteur de priorité gère les modifications de priorité :

    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 le fondu audio forcé par le système dans AAOS. Dans Android, la priorité audio n'est pas appliquée par le système. Par conséquent, bien que les développeurs d'applications soient encouragés à respecter les consignes de priorité audio, si une application continue de lire à un volume élevé même après avoir perdu la priorité audio, le système ne peut pas l'empêcher.

Dans les environnements automobiles critiques pour la sécurité, le respect de la priorité audio est essentiel pour minimiser les distractions du conducteur. Grâce à cette fonctionnalité, le framework audio réduit automatiquement le volume des 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 priorité 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 de haut niveau et la prise en charge de la fonctionnalité de perte de priorité dans les voitures :

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

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

  • Fondu ciblé : l'application du fondu par le système dans Android 15 est spécifiquement conçue pour les situations où une application perd la priorité audio, mais continue de lire de l'audio.
  • Mécanisme de fondu : lorsqu'une application perd la priorité audio au profit d'une nouvelle application demandant la priorité :
    • Le framework audio réduit automatiquement le volume 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 priorité audio.
    • Les applications qui ne se comportent pas correctement sont coupées jusqu'à ce qu'elles récupèrent la priorité audio.
    • La logique par défaut consiste à effectuer un fondu des applications dont le volume a été réduit après deux secondes. Toutefois, les OEM peuvent configurer cette valeur sur n'importe quelle valeur de délai avant expiration.
    • Le framework audio utilise les configurations OEM pour les opérations de fondu et d'augmentation du volume.

  • 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 le fondu et la coupure du son 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 indicateur 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 priorité audio forcé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 ces définitions n'entraîne 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 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 Android 15 introduit un FadeManagerConfiguration unifié pour offrir aux OEM un contrôle précis sur le comportement du 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 transition du fondu : paramètres pour le fondu et l'augmentation du volume.
    • Peut être défini avec des utilisations ou des attributs audio spécifiques.
    • Permet des paramètres de durée personnalisés.
    • Ces paramètres sont utilisés pour construire VolumeShaper.Configuration.
  • Règles de fondu : règles régissant le moment où le fondu se produit.
    • Un bouton global permettant d'activer ou de désactiver le fondu.
    • Une liste configurable d'utilisations audio pouvant être fondues (éligibles au fondu en cas de perte de priorité).
    • Les listes d'exclusion (non fondues) empêchent le fondu 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 peut être défini que lors de l'exécution)

Configurations OEM

Dans cette section, nous examinons 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 une personnalisation OEM étendue du comportement de fondu audio en cas de perte de priorité.

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

Pour obtenir des conseils pratiques sur l'implémentation, consultez les exemples de configurations fournis pour l'émulateur situé dans 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 les nouvelles balises applyFadeConfigs et fadeConfig. La balise applyFadeConfigs peut contenir plusieurs définitions fadeConfig, ce qui permet une configuration de fondu flexible. 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 priorité audio, et uniquement lorsque l'application gagnante de la priorité 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 situé dans device/generic/car/emulator/audio/car_audio_configuration.xml.

Extension de service de priorité audio OEM

Les OEM qui implémentent un service de priorité audio de voiture personnalisé peuvent 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) {
}

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

Schéma de séquence

Ce schéma de séquence illustre le comportement suite à l'attribution de la priorité audio à App2 et à la perte de priorité audio par App1 :

  • Lorsque le service audio de la voiture envoie la perte de priorité audio à App1, la lecture du lecteur App1 subit un fondu tel que défini par les FadeManagerConfigurations actifs. Une fois l'opération de fondu terminée, App1 reçoit le rappel de perte de priorité audio standard.
  • Le son de App1 peut également être augmenté 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 leur produit.

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

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

Gestion de la priorité 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 adressée à une zone ne tient pas compte de ce qui a la priorité dans les autres zones et n'entraîne pas la perte de priorité des détenteurs de priorité dans les autres zones. Ainsi, la priorité de l'habitacle principal peut être gérée séparément d'un système de divertissement arrière, ce qui n'interrompt pas la lecture audio dans une zone en cas de modification de la priorité dans une autre.

Pour toutes les applications, CarAudioService gère automatiquement la priorité. La zone audio d'une demande de priorité est déterminée par son UserId ou UID (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 la priorité 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, le HAL est activé pour demander la priorité au nom des flux externes. Bien que facultative, l'utilisation de ces API est fortement recommandée pour permettre aux sons externes de participer de manière optimale à l'écosystème Android et offrir une expérience utilisateur fluide.

Le HAL détermine en dernier ressort les sons qui doivent être prioritaires. À cet égard, les sons d'urgence et critiques pour la sécurité doivent être lus, que le HAL ait ou non la priorité audio, et doivent continuer à être lus de manière appropriée, 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 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 auprès d' AudioControl HAL. Cet écouteur permet au HAL de demander et d'abandonner la priorité audio focus. Le HAL fournit une instance ICloseHandle à utiliser par Android pour annuler l'enregistrement de l'écouteur.
IAudioControl#onAudioFocusChange Avertit le HAL des modifications d'état des demandes de priorité effectuées par le HAL via IFocusListener, y compris les réponses aux demandes de priorité initiales.
IFocusListener#requestAudioFocus Demande la priorité au nom du HAL pour une utilisation, un ID de zone, et un type de gain de priorité spécifiés.
IFocusListener#abandonAudioFocus Abandonne les demandes de priorité HAL existantes pour l'utilisation et l'ID de zone spécifiés.

Le HAL peut avoir plusieurs demandes de priorité en même temps, mais il est limité à une demande par paire d'utilisation et d'ID de zone. Android suppose que le HAL commence immédiatement à lire des sons pour une utilisation une fois qu'une requête a été effectué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 demande de priorité. Le HAL ne doit pas attendre d'avoir la priorité avant de lire des sons critiques pour la sécurité. Il est facultatif pour le HAL d'écouter et de répondre aux modifications de la priorité audio via IAudioControl#onAudioFocusChange.

Service de priorité audio de voiture OEM

Dans Android 14, AAOS a introduit les services de plug-in OEM pour voiture afin de permettre la configuration 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 priorité interceptées par le service audio de la voiture. Cela offre aux OEM plus de flexibilité en termes de gestion de la priorité, conformément aux règles et réglementations. Par conséquent, l'interaction de priorité audio peut différer d'un fabricant à l'autre et d'une région à l'autre. Le principe de base de la priorité audio reste le même : les applications doivent toujours demander la priorité 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 priorité audio par les applications :

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

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

    • Les applications demandant la priorité d'utilisation des appels doivent pouvoir recevoir l'appel simultanément ou exclusivement.

    • Les applications demandant la priorité d'utilisation de la navigation doivent pouvoir recevoir la priorité de navigation simultanément ou exclusivement.

    • Les applications demandant la priorité d'utilisation de l'assistant doivent pouvoir recevoir la priorité d'utilisation simultanément ou exclusivement.

  • Lorsque des applications de priorité audio permanente et élevée (y compris un appel téléphonique, une alerte d'urgence ou une notification de sécurité) sont actives, toute demande de priorité 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 priorité à l'obtenir si aucun son actif de haute priorité n'existe. Même lorsque des sons de haute priorité sont actifs, les demandes de priorité différées doivent toujours être respectées et doivent pouvoir obtenir la priorité lorsque le son de haute priorité s'arrête.