La version Android 10 inclut une refactorisation importante du gestionnaire de règles audio afin de proposer plus de flexibilité pour prendre en charge les cas d'utilisation automobiles complexes:
- Stratégies de routage spécifiques aux OEM.
- Groupes de volumes personnalisables pour les groupes d'anciens types de flux utilisant les mêmes courbes de volume.
- Stratégies de routage déclarées par le moteur de règles audio au lieu d'être codées en dur.
- Courbes de volume et groupes gérés par le moteur de règles audio.
- Refactoring interne en vue d'une future division entre le code commun et le code configurable, et offrant une gestion plus riche des appareils audio. Par exemple, l'utilisation de toutes les propriétés de l'appareil, et pas seulement de son type, dans les règles de stratégie.
Android 7.0 a introduit un format de fichier de configuration de règles audio (XML) pour décrire votre topologie audio.
Les versions précédentes d'Android devaient utiliser device/<company>/<device>/audio/audio_policy.conf pour déclarer les appareils audio présents dans votre produit (vous trouverez un exemple de ce fichier pour le matériel audio Galaxy Nexus dans device/samsung/tuna/audio/audio_policy.conf). Cependant, CONF est un format simple et propriétaire trop limité pour décrire des topologies complexes pour des secteurs tels que les téléviseurs et les automobiles.
Android 7.0 a abandonné audio_policy.conf et permet désormais de définir une topologie audio à l'aide d'un format de fichier XML plus lisible, doté d'un large éventail d'outils d'édition et d'analyse, et suffisamment flexible pour décrire des topologies audio complexes. Android 7.0 utilise l'indicateur de compilation USE_XML_AUDIO_POLICY_CONF pour choisir le format XML des fichiers de configuration.
Avantages du format XML
Comme dans le fichier CONF, le fichier XML permet de définir le nombre et les types de profils de flux de sortie et d'entrée, les appareils utilisables pour la lecture et la capture, ainsi que les attributs audio. En outre, le format XML offre les améliorations suivantes:
- Sous Android 10, plusieurs applications d'enregistrement actives sont autorisées simultanément.
- Le démarrage de l'enregistrement n'est jamais refusé en raison d'une situation de simultanéité.
- Le rappel
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)informe les clients des modifications apportées au chemin de capture.
- Dans les situations suivantes, un client reçoit des échantillons audio silencieux :
- Un cas d'utilisation sensible à la confidentialité (par exemple,
VOICE_COMMUNICATION) est actif. - Le client ne dispose pas d'un service ni d'une UI de premier plan.
- Les rôles spéciaux sont reconnus par le règlement :
- Service d'accessibilité: peut enregistrer même si un cas d'utilisation sensible à la confidentialité est actif.
- Assistant: considéré comme sensible à la confidentialité si l'UI est en haut.
- Un cas d'utilisation sensible à la confidentialité (par exemple,
- Les profils audio ont une structure semblable aux descripteurs audio simples HDMI, ce qui permet d'utiliser un ensemble différent de taux d'échantillonnage/masques de canaux pour chaque format audio.
- Des définitions explicites sont fournies pour toutes les connexions possibles entre les appareils et les flux. Auparavant, une règle implicite permettait de connecter tous les appareils connectés au même module HAL, ce qui empêchait la stratégie audio de contrôler les connexions demandées avec les API de patch audio. Au format XML, la description de la topologie définit les limites de connexion.
- La prise en charge des inclusions évite de répéter les définitions standards d'envoi A2DP, USB ou de redirection.
- Les courbes de volume sont personnalisables. Auparavant, les tables de volumes étaient codées en dur. Au format XML, les tableaux de volumes sont décrits et peuvent être personnalisés.
Le modèle frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml montre de nombreuses utilisations de ces fonctionnalités.
Format et emplacement du fichier
Le nouveau fichier de configuration des règles audio est audio_policy_configuration.xml et se trouve dans /system/etc. Les exemples suivants montrent une configuration simple des règles audio au format de fichier XML pour Android 12 et les versions antérieures.
La structure de premier niveau contient des modules qui correspondent à chaque module matériel HAL audio, où chaque module contient une liste de ports de mixage, de ports d'appareil et de routes:
- Les ports de mix décrivent les profils de configuration possibles pour les flux pouvant être ouverts au niveau de l'HAL audio pour la lecture et la capture.
- Les ports d'appareil décrivent les appareils pouvant être connectés avec leur type (et éventuellement leur adresse et leurs propriétés audio, le cas échéant).
- Les routes sont séparées du descripteur de port de combinaison, ce qui permet de décrire les routes d'un appareil à un autre ou d'un flux à un autre.
Les tables de volumes sont de simples listes de points définissant la courbe utilisée pour convertir un indice d'interface utilisateur en volume en dB. Un fichier d'inclusion distinct fournit des courbes par défaut, mais chaque courbe pour un cas d'utilisation et une catégorie d'appareil donnés peut être écrasée.
Inclusions de fichiers
La méthode d'inclusion XML (XInclude) permet d'inclure des informations de configuration des règles audio situées dans d'autres fichiers XML. Tous les fichiers inclus doivent suivre la structure décrite ci-dessus, avec les restrictions suivantes:
- Les fichiers ne peuvent contenir que des éléments de premier niveau.
- Les fichiers ne peuvent pas contenir d'éléments XInclude.
Utilisez des inclusions pour éviter de copier les informations de configuration du module HAL audio standard du projet Android Open Source Project (AOSP) dans tous les fichiers de configuration des stratégies audio (ce qui est sujet à des erreurs). Un fichier XML de configuration de règles audio standard est fourni pour les HAL audio suivants:
- A2DP:
a2dp_audio_policy_configuration.xml - Rerouter le sous-mix:
rsubmix_audio_policy_configuration.xml - USB:
usb_audio_policy_configuration.xml
Organisation des codes de règles audio
AudioPolicyManager.cpp est divisé en plusieurs modules pour faciliter sa maintenance et sa configuration. L'organisation de frameworks/av/services/audiopolicy comprend les modules suivants.
| Module | Description |
|---|---|
/managerdefault |
Inclut les interfaces génériques et l'implémentation du comportement commune à toutes les applications. Semblable à AudioPolicyManager.cpp, avec des fonctionnalités de moteur et des concepts courants abstraits. |
/common |
Définit les classes de base (par exemple, les structures de données pour les profils de flux audio d'entrée/sortie, les descripteurs d'appareil audio, les correctifs audio et les ports audio). Cela a déjà été défini dans AudioPolicyManager.cpp. |
/engine |
Elle met en œuvre les règles qui définissent l'appareil et les volumes à utiliser pour un cas d'utilisation donné. Il implémente une interface standard avec la partie générique, par exemple pour obtenir l'appareil approprié pour un cas d'utilisation de lecture ou de capture donné, ou pour définir des appareils connectés ou un état externe (c'est-à-dire un état d'appel d'utilisation forcée) qui peut modifier la décision de routage. Disponible en deux versions: configurable et default. Pour savoir comment sélectionner la version, consultez la section Configuration à l'aide du framework de paramètres. |
/engineconfigurable |
Implémentation du moteur de règles qui s'appuie sur le framework de paramètres (voir ci-dessous). La configuration est basée sur le framework de paramètres et sur la définition de la stratégie par des fichiers XML. |
/enginedefault |
Implémentation du moteur de règles basée sur les implémentations précédentes du Gestionnaire de règles audio Android. Il s'agit de la valeur par défaut et inclut des règles codées en dur qui correspondent aux implémentations Nexus et AOSP. |
/service |
Inclut les interfaces de liaison, l'exécution de threads et l'implémentation du verrouillage de l'interface avec le reste du framework. |
Configuration à l'aide du framework de paramètres
Le code de la stratégie audio est organisé pour être facile à comprendre et à gérer, tout en prenant en charge une stratégie audio définie entièrement par des fichiers de configuration. La conception de l'organisation et des règles audio est basée sur le Parameter Framework d'Intel, un framework basé sur des plug-ins et des règles pour gérer les paramètres.
L'utilisation de la stratégie audio configurable permet aux OEM de:
- Décrire la structure d'un système et ses paramètres au format XML
- Écrivez (en C++) ou réutilisez un backend (plug-in) pour accéder aux paramètres décrits.
- Définissez (en XML ou dans un langage spécifique au domaine) les conditions/règles sur lesquelles un paramètre donné doit prendre une valeur donnée.
AOSP inclut un exemple de fichier de configuration de règles audio qui utilise le framework de paramètres à l'adresse Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Pour en savoir plus, consultez la documentation Intel sur le framework de paramètres.
Sous Android 10 ou version antérieure, la stratégie audio configurable est sélectionnée à l'aide de l'option de compilation USE_CONFIGURABLE_AUDIO_POLICY.
Sous Android 11 ou version ultérieure, la version du moteur de règles audio est sélectionnée dans le fichier audio_policy_configuration.xml.
Pour sélectionner le moteur de règles audio configurables, définissez la valeur de l'attribut engine_library de l'élément globalConfiguration sur configurable, comme dans l'exemple suivant:
<audioPolicyConfiguration> <globalConfiguration engine_library="configurable" /> ... </audioPolicyConfiguration>
API de routage des règles audio
Android 6.0 a introduit une API d'énumération et de sélection publique qui se trouve au-dessus de l'infrastructure de patch/port audio et permet aux développeurs d'applications d'indiquer une préférence pour une sortie ou une entrée d'appareil spécifique pour les enregistrements ou les pistes audio connectés.
Dans Android 7.0, l'API Enumeration and Selection est validée par des tests CTS et est étendue pour inclure le routage des flux audio natifs C/C++ (OpenSL ES).
Le routage des flux natifs continue d'être effectué en Java, avec l'ajout d'une interface AudioRouting qui remplace, combine et abandonne les méthodes de routage explicites spécifiques aux classes AudioTrack et AudioRecord.
Pour en savoir plus sur l'API d'énumération et de sélection, consultez les sections Interfaces de configuration Android et OpenSLES_AndroidConfiguration.h.
Pour en savoir plus sur le routage audio, consultez la section AudioRouting.
Assistance multicanal
Si votre matériel et votre pilote sont compatibles avec l'audio multicanal via HDMI, vous pouvez envoyer le flux audio directement au matériel audio (cela contourne le mixeur AudioFlinger afin qu'il ne soit pas mixé à deux canaux). La HAL audio doit indiquer si un profil de flux de sortie est compatible avec les fonctionnalités audio multicanaux. Si le HAL expose ses fonctionnalités, le gestionnaire de règles par défaut autorise la lecture multicanal via HDMI. Pour en savoir plus sur l'implémentation, consultez device/samsung/tuna/audio/audio_hw.c.
Pour spécifier que votre produit contient une sortie audio multicanal, modifiez le fichier de configuration des règles audio afin de décrire la sortie multicanal de votre produit. L'exemple suivant de frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml montre un masque de canal dynamique, ce qui signifie que le gestionnaire de règles audio interroge les masques de canaux compatibles avec le collecteur HDMI après la connexion.
Vous pouvez également spécifier un masque de canal statique tel que AUDIO_CHANNEL_OUT_5POINT1. Le mixeur d'AudioFlinger convertit automatiquement le contenu en stéréo lorsqu'il est envoyé à un appareil audio qui n'est pas compatible avec l'audio multicanal.
Codecs multimédias
Assurez-vous que les codecs audio compatibles avec votre matériel et vos pilotes sont correctement déclarés pour votre produit. Pour en savoir plus, consultez la section Exposing Codecs to the Framework (Exposer les codecs au framework).