La version Android 10 inclut une refactorisation importante du gestionnaire de politiques audio pour offrir plus de flexibilité pour prendre en charge des cas d'utilisation automobiles complexes :
- Stratégies de routage spécifiques aux OEM.
- Groupes de volumes personnalisables pour les groupes de types de flux existants utilisant les mêmes courbes de volume.
- Stratégies de routage déclarées par le moteur de politique audio au lieu d'être codées en dur.
- Courbes et groupes de volumes gérés par le moteur de politique audio.
- Refactorisation interne préparant une future scission entre code commun et code configurable et offrant une gestion plus riche des périphériques 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 politique audio (XML) pour décrire votre topologie audio.
Les versions précédentes d'Android nécessitaient l'utilisation device/<company>/<device>/audio/audio_policy.conf pour déclarer les périphériques audio présents sur votre produit (vous pouvez voir un exemple de ce fichier pour le matériel audio du 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 verticaux comme la télévision et l'automobile.
Android 7.0 a rendu audio_policy.conf obsolète et a ajouté la prise en charge de la définition d'une topologie audio à l'aide d'un format de fichier XML plus lisible par l'homme, doté d'une large gamme d'outils d'édition et d'analyse et suffisamment flexible pour décrire des topologies audio complexes. Android 7.0 utilise l'indicateur de build 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 périphériques utilisables pour la lecture et la capture, ainsi que les attributs audio. De plus, 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 rejeté en raison d'une situation de concurrence.
- Le rappel
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)informe les clients des modifications du chemin de capture.
- Dans les situations suivantes, un client obtient des échantillons audio silencieux :
- Un cas d'utilisation sensible à la confidentialité (par exemple,
VOICE_COMMUNICATION) est actif. - Le client ne dispose pas de service de premier plan ni d’interface utilisateur de premier plan.
- Les rôles spéciaux sont reconnus par la politique :
- 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'interface utilisateur est au premier plan.
- Un cas d'utilisation sensible à la confidentialité (par exemple,
- Les profils audio ont une structure similaire aux descripteurs audio simples HDMI, permettant un ensemble différent de taux d'échantillonnage/masques de canal pour chaque format audio.
- Il existe des définitions explicites 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, empêchant la politique 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 limitations de connexion.
- La prise en charge des inclusions évite de répéter les définitions de soumission standard 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 tables de volumes sont décrites et peuvent être personnalisées.
Le modèle sur frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml montre bon nombre de ces fonctionnalités utilisées.
Format et emplacement du fichier
Le nouveau fichier de configuration de la politique audio s'appelle audio_policy_configuration.xml et se trouve dans /system/etc . Les exemples suivants montrent une configuration simple de stratégie audio au format de fichier XML pour Android 12 et pour les versions inférieures à Android 12.
La structure de niveau supérieur contient des modules qui correspondent à chaque module matériel audio HAL, où chaque module possède une liste de ports de mixage, de ports de périphérique et de routes :
- Les ports de mixage décrivent les profils de configuration possibles pour les flux qui peuvent être ouverts sur le HAL audio pour la lecture et la capture.
- Les ports de périphérique décrivent les périphériques qui peuvent ê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 mixage, permettant la description des routes d'un appareil à l'autre ou d'un flux à l'autre.
Les tables de volumes sont de simples listes de points définissant la courbe utilisée pour traduire d'un indice d'interface utilisateur en un 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 de périphérique donnés peut être écrasée.
Inclusions de fichiers
La méthode XML Inclusions (XInclude) peut être utilisée pour inclure des informations de configuration de stratégie 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 niveau supérieur.
- Les fichiers ne peuvent pas contenir d'éléments XInclude.
Utilisez les inclusions pour éviter de copier les informations de configuration du module HAL audio standard du projet Android Open Source (AOSP) dans tous les fichiers de configuration de stratégie audio (ce qui est sujet aux erreurs). Un fichier XML de configuration de politique audio standard est fourni pour les HAL audio suivantes :
- A2DP :
a2dp_audio_policy_configuration.xml - Rediriger le sous-mix :
rsubmix_audio_policy_configuration.xml - USB :
usb_audio_policy_configuration.xml
Organisation du code de politique 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 la mise en œuvre du comportement commun à toutes les applications. Semblable à AudioPolicyManager.cpp avec les fonctionnalités du moteur et les concepts communs abstraits. |
/common | Définit les classes de base (par exemple, les structures de données pour les profils de flux audio d'entrée et de sortie, les descripteurs de périphériques audio, les correctifs audio et les ports audio). Cela a été précédemment défini dans AudioPolicyManager.cpp . |
/engine | Implémente les règles qui définissent quel périphérique et quels volumes doivent être utilisés pour un cas d'utilisation donné. Il implémente une interface standard avec la partie générique, par exemple pour obtenir le périphérique approprié pour un cas d'utilisation de lecture ou de capture donné, ou pour définir des périphériques connectés ou un état externe (c'est-à-dire un état d'appel d'utilisation forcée) qui peut modifier le routage. décision. Disponible en deux versions : configurable et par défaut . Pour plus d’informations sur la sélection de la version, consultez Configuration à l’aide de Parameter Framework . |
/engineconfigurable | Implémentation d'un moteur de politique qui s'appuie sur Parameter Framework (voir ci-dessous). La configuration est basée sur le Parameter Framework et où la politique est définie par des fichiers XML. |
/enginedefault | Implémentation du moteur de stratégie basée sur les implémentations précédentes d'Android Audio Policy Manager. 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 | Comprend les interfaces de classeur, le threading et l'implémentation du verrouillage avec l'interface avec le reste du framework. |
Configuration à l'aide du framework de paramètres
Le code de la politique audio est organisé pour le rendre facile à comprendre et à maintenir tout en prenant en charge une politique audio entièrement définie par des fichiers de configuration. L'organisation et la conception de la politique audio sont basées sur le Parameter Framework d'Intel, un cadre basé sur des plugins et des règles pour la gestion des paramètres.
L'utilisation de la politique audio configurable permet aux fournisseurs OEM de :
- Décrire la structure d'un système et ses paramètres en XML.
- Écrivez (en C++) ou réutilisez un backend (plugin) pour accéder aux paramètres décrits.
- Définir (en XML ou dans un langage spécifique au domaine) les conditions/règles selon lesquelles un paramètre donné doit prendre une valeur donnée.
AOSP inclut un exemple de fichier de configuration de stratégie audio qui utilise Parameter Framework dans Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Pour plus de détails, reportez-vous à la documentation Intel sur Parameter Framework .
Sous Android 10 ou version antérieure, la politique audio configurable est sélectionnée à l'aide de l'option de construction USE_CONFIGURABLE_AUDIO_POLICY . Sous Android 11 ou version ultérieure, la version du moteur de politique audio est sélectionnée dans le fichier audio_policy_configuration.xml . Pour sélectionner le moteur de stratégie audio configurable, 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 publique d'énumération et de sélection qui se trouve au-dessus de l'infrastructure de patch audio/port audio et permet aux développeurs d'applications d'indiquer une préférence pour une sortie ou une entrée de périphérique spécifique pour les enregistrements ou pistes audio connectés.
Dans Android 7.0, l'API d'énumération et de sélection est vérifié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 déprécie les méthodes de routage explicites spécifiques aux classes AudioTrack et AudioRecord .
Pour plus de détails sur l'API d'énumération et de sélection, reportez-vous aux interfaces de configuration Android et à OpenSLES_AndroidConfiguration.h . Pour plus de détails sur le routage audio, reportez-vous à AudioRouting .
Prise en charge multicanal
Si votre matériel et votre pilote prennent en charge l'audio multicanal via HDMI, vous pouvez émettre le flux audio directement vers le matériel audio (cela contourne le mélangeur AudioFlinger afin qu'il ne soit pas mixé sur deux canaux.) Le HAL audio doit indiquer si un profil de flux de sortie prend en charge les capacités audio multicanaux. Si le HAL expose ses capacités, le gestionnaire de politiques par défaut autorise la lecture multicanal via HDMI. Pour plus de détails sur la mise en œuvre, consultez device/samsung/tuna/audio/audio_hw.c .
Pour spécifier que votre produit contient une sortie audio multicanal, modifiez le fichier de configuration de la stratégie audio pour 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 politique audio interroge les masques de canal pris en charge par le récepteur HDMI après la connexion.
Vous pouvez également spécifier un masque de canal statique tel que AUDIO_CHANNEL_OUT_5POINT1 . Le mélangeur d'AudioFlinger sous-mixe automatiquement le contenu en stéréo lorsqu'il est envoyé à un périphérique audio qui ne prend pas en charge l'audio multicanal.
Codecs multimédias
Assurez-vous que les codecs audio pris en charge par votre matériel et vos pilotes sont correctement déclarés pour votre produit. Pour plus de détails, consultez Exposition des codecs au Framework .