Moteur de règles audio configurable

Dans Android 14, Android Automotive OS (AAOS) utilise le moteur de stratégie audio configurable (CAP) pour gérer l'audio de la voiture dans la zone audio principale. Plus précisément, le moteur CAP permet à AAOS de contrôler uniquement le routage audio, uniquement le volume audio, ou à la fois le routage et le volume simultanément. Les indicateurs suivants peuvent être utilisés pour contrôler le comportement :

• Utilisez l'indicateur useCoreAudioVolume pour activer la gestion du volume CAP. Lorsque cette valeur est true, le service audio de la voiture utilise les API du gestionnaire audio pour gérer les groupes de volume.

• Utilisez l'indicateur useCoreAudioRouting pour activer la gestion du routage audio CAP. Lorsque cette valeur est définie sur true, le service audio de la voiture utilise le routage configurable de la stratégie audio pour gérer le routage audio.

Le moteur de règles audio est également compatible avec Android par défaut sous la forme du moteur de règles audio par défaut.

Arrière-plan

Le moteur CAP est basé sur le framework de paramètres d'Intel, qui est un framework basé sur des règles et des plug-ins pour la gestion des paramètres. Pour la gestion audio Android en particulier, le moteur CAP a introduit la possibilité de définir des règles de fichiers XML pour spécifier les éléments suivants :

• Stratégie produit audio
• Règles concernant la sélection des périphériques de sortie audio
• Règles concernant la sélection des périphériques d'entrée audio
• Règles pour gérer le volume et le mode silencieux, ainsi que les tableaux de volume

Initialisation du CAP avant Android 16

La figure suivante présente une vue d'ensemble de la gestion de la configuration du moteur de règles audio configurable à partir d'Android 6 :

Figure 1 : Gestion de la configuration du moteur CAP à partir d'Android 6.

Comme illustré dans la figure, la configuration du moteur CAP est obtenue par le service de stratégie audio en analysant les informations du fichier audio_policy_engine_configuration.xml dans la partition vendor. Le fichier de configuration du moteur CAP utilise le schéma défini dans audio_policy_engine_configuration.xsd pour obtenir les informations requises. audio_policy_engine_configuration.xml est un exemple pour Automotive. Des exemples similaires pour d'autres facteurs de forme se trouvent dans le dossier frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

La figure suivante fournit des informations plus détaillées sur la façon dont les informations configurables du moteur de stratégie audio sont chargées dans le service de stratégie audio. Dans ce cas, le framework de paramètres charge la structure et les paramètres à partir des fichiers XML.

Figure 2. Informations CAP chargées dans le service de stratégie audio.

Fichiers de structure CAP dans Android 15 et versions antérieures

Pour obtenir la structure et les paramètres, le service de règles audio lit le fichier ParameterFrameworkConfigurationPolicy.xml. Il fait référence aux informations de structure via l'emplacement du fichier de description de la structure :

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Il pointe vers les informations de structure dans le fichier :

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Une structure squelette est fournie dans Android. Les informations de structure nécessitent les informations de structure de la stratégie produit. Android fournit donc l'outil de génération buildStrategiesStructureFile.py, qui peut générer des informations à partir du fichier XML de stratégie produit disponible. Vous pouvez y faire référence via la valeur par défaut de genrule buildstrategiesstructurerule comme suit :

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Où audio_policy_engine_configuration_files correspond aux fichiers de configuration du moteur de règles audio. Cet exemple pour Automotive fait référence aux fichiers de configuration des règles audio dans le dossier Automotive. D'autres exemples montrent comment configurer une compilation pour transférer les fichiers dans la partition du fournisseur de l'appareil.

Fichiers de paramètres CAP dans Android 15 et versions antérieures

Comme pour la structure, les informations de paramètre, qui représentent les règles et les valeurs des paramètres, sont référencées dans le fichier ParameterFrameworkConfigurationPolicy.xml comme suit :

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android fournit également des outils de compilation pour générer ces informations à l'aide de la configuration du moteur de règles audio et des fichiers du framework de paramètres. Pour en savoir plus, consultez Configurations.

Initialisation du CAP du HAL audio AIDL

À partir d'Android 16, la définition de l'API AIDL Audio HAL est étendue avec les configurations du moteur de règles audio, AudioHalCapConfiguration.aidl. La figure suivante présente une vue d'ensemble de la gestion de la configuration du moteur CAP à partir d'Android 16 :

Figure 3. Gestion de la configuration du moteur CAP à partir d'Android 16.

Le service de règles audio obtient les informations du moteur CAP à l'aide des API HAL Audio AIDL directement au lieu d'analyser les informations à partir de fichiers XML dans la partition du fournisseur de l'appareil.

Dans cette configuration, la structure du framework de paramètres est toujours chargée par le moteur CAP côté serveur audio.

Figure 4. Structure du moteur CAP.

Dans tous les cas, la configuration doit spécifier entièrement les informations concernant les stratégies produit, les groupes de volume et les critères.

La figure suivante présente une vue d'ensemble des API HAL audio AIDL utilisées par le service de règles audio pour obtenir la configuration du moteur CAP :

Figure 5. API AIDL audio HAL.

Dans cette configuration, le service de règles audio obtient les informations suivantes auprès du HAL audio AIDL :

• Configuration
• Stratégies
• Volumes
• Critères
• Paramètres

Chargeur HAL audio AIDL par défaut

Pour faciliter la transition de HIDL vers AIDL, le HAL audio AIDL par défaut fournit un chargeur de moteur CAP XML. Les fournisseurs peuvent utiliser ce chargeur directement en étendant leur HAL audio avec le HAL audio par défaut ou en référençant la bibliothèque libaudioserviceexampleimpl.

Le chargeur HAL audio AIDL par défaut utilise audio_policy_engine_configuration.xml pour obtenir les informations suivantes :

• Configuration
• Stratégies
• Volumes
• Critères

Les informations de structure sont obtenues à partir du fichier PolicyConfigurableDomains.xml. La principale différence avec le mécanisme précédent est que les informations de structure sont également obtenues par le HAL audio AIDL au lieu du framework de paramètres du service de règles audio.

Les fournisseurs peuvent utiliser l'outil domaingeneratorpolicyrule pour générer les domaines configurables à l'aide des informations de la configuration du moteur de règles audio. Vous pouvez utiliser l'exemple d'appareil virtuel Cuttlefish pour l'automobile comme référence.

Structure dans la configuration AIDL

Sous Android 16 et versions ultérieures, le service de règles audio obtient les informations de structure en lisant et en analysant le fichier ParameterFrameworkConfigurationCap.xml[file](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). Plus précisément, il obtient les informations à partir du fichier de description de la structure :

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

Le framework dépose les fichiers requis dans le dossier /etc/parameter-framework/ avec les informations nécessaires.

La structure représente les paramètres à contrôler. Ils doivent donc être référencés dans la configuration ou les domaines. Pour ce faire, la configuration du moteur AIDL doit utiliser un nom prédéterminé pour les paramètres. Pour les stratégies de produit, les structures sont configurées dans CapProductStrategies.xml.

Stratégies de produit par défaut

En commençant par les valeurs par défaut fournies dans le moteur par défaut, les stratégies produit commencent par le préfixe STRATEGY_ :

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Ce format a été fourni pour faciliter la transition de HIDL vers AIDL pour les appareils qui utilisaient des stratégies par défaut. Ce changement de format a des implications pour les fichiers existants (par exemple, PfW, XML) utilisés pour configurer le moteur. En particulier, toutes les références à la stratégie produit doivent être modifiées pour utiliser les nouveaux noms, par exemple :

Nom du paramètre de configuration non AIDL
/Policy/policy/product_strategies/media/device_address /Policy/policy/product_strategies/media/selected_output_devices/mask

Nom du paramètre de configuration AIDL
/Policy/policy/product_strategies/STRATEGY_MEDIA/device_address /Policy/policy/product_strategies/STRATEGY_MEDIA/selected_output_devices/mask

Stratégies produit définies par l'OEM

Le moteur configurable permet aux OEM de modifier la définition des stratégies produit. Pour que cela reste possible, le fichier de stratégie produit CapProductStrategies.xml fournit également 40 stratégies de produits extensibles par le fournisseur, de vx_1000 à vx_1039. Toutes les extensions du fournisseur doivent commencer par le préfixe vx_, suivi d'un nombre représentant l'ID de stratégie produit dans la définition de la stratégie produit HAL audio AIDL. Le reste des définitions (par exemple, les groupes d'attributs audio, le nom) est obtenu à partir de l'objet AudioHALProductStrategy dans la configuration du moteur HAL audio.

Comme pour les stratégies produit par défaut, les références OEM définies par le fournisseur doivent également être adaptées entre la configuration non-AIDL et la configuration AIDL. Par exemple :

Nom du paramètre de configuration non AIDL
/Policy/policy/product_strategies/oem_extension_strategy/device_address /Policy/policy/product_strategies/oem_extension_strategy/selected_output_devices/mask

Nom du paramètre de configuration AIDL
/Policy/policy/product_strategies/vx_1037/device_address /Policy/policy/product_strategies/vx_1037/selected_output_devices/mask

Stratégies produit

Les stratégies de produit permettent de personnaliser la façon dont les flux audio sont classés et regroupés. Cela permet une plus grande flexibilité dans la configuration des appareils audio, y compris dans la façon dont ils sont routés et dont leurs volumes sont gérés. Chaque stratégie produit peut comporter un ou plusieurs groupes d'attributs audio, qui identifient les flux à associer à cette stratégie produit. Ces groupes d'attributs audio permettent une approche plus précise de la catégorisation de l'audio et peuvent être un mélange des types suivants :

• Les types Usage décrivent pourquoi un son est diffusé (par exemple, multimédia, notification, appel).
• Les types Content type décrivent ce qui est lu (musique, voix, vidéo, sonification, etc.).
• Les types Flag définissent différents comportements ou requêtes par rapport au flux.
• Les types Tags acceptent toute liste arbitraire de valeurs de chaîne du fournisseur.
  • Chaque chaîne doit commencer par VX_, suivi d'une chaîne alphanumérique (par exemple, VX_OEM, VX_NAVIGATION).

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

Cet extrait montre un exemple de stratégie produit utilisée dans les émulateurs de voiture. Il contient deux attributs audio avec les utilisations audio "média" et "jeu", respectivement. Cette stratégie produit correspond au contexte audio MUSIC utilisé dans le service audio pour voiture, mais cette correspondance n'est pas obligatoire. L'un des principaux utilitaires pour les OEM utilisant le CAP avec Android est de permettre des définitions de regroupement audio plus flexibles.

Groupes de volumes

De plus, chaque groupe d'attributs audio doit être associé à un groupe de volume. Ce groupe de volume est associé à tout flux correspondant aux attributs audio appartenant au groupe d'attributs audio. L'exemple de stratégie produit musicale de la section Stratégies produit comporte le groupe de volume media. La définition du groupe de volume multimédia est la suivante :

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

Dans cette définition, le groupe de volumes contient les éléments suivants :

• Nom du groupe
• Index minimal du groupe
• Index maximal du groupe
• Courbes de groupe de volumes

Les courbes du groupe de volume contiennent un mappage ponctuel entre l'index du groupe de volume et le gain de volume en millibels. Les points fournis sont utilisés pour interpoler linéairement le gain le plus adapté lorsque le volume est géré. Chaque courbe de groupe de volume est associée à une catégorie de type d'appareil (par exemple, casque, enceinte, support externe).

Le groupe de volume gère le volume des flux qui font partie du groupe d'attributs audio. Par exemple, lorsqu'un flux avec des attributs audio contenant de la musique ou un jeu est démarré, le dernier index de volume défini pour le groupe de volume multimédia est utilisé. Dans ce cas, la courbe de catégorie d'appareil correspondante est sélectionnée en fonction de l'appareil sélectionné, et le gain correspondant est défini lorsque le flux est démarré.

Configurations

Dans le moteur CAP, les configurations sont utilisées pour définir les conditions ou les règles qui déterminent le comportement de l'audio. Ces configurations sont évaluées au moment de l'exécution pour sélectionner les règles appropriées à appliquer en fonction de l'état actuel du système audio.

Comme le montre la figure 5, l'API contient plusieurs domaines. L'objectif de chaque domaine est de diviser la logique en problèmes de routage plus petits à résoudre (par exemple, appareil 1, appareil 2).

Chaque domaine comporte des configurations, et chaque configuration comporte un ensemble de règles. Les règles sont établies sur la base de critères fournis par AudioPolicyManager :

• Mode audio
• Périphériques d'entrée et de sortie disponibles
• Adresses des périphériques d'entrée et de sortie disponibles
• Utiliser pour
  • Contenus multimédias
  • Communication
  • Enregistrement
  • Station d'accueil
  • Système
  • Système audio HDMI
  • Son surround encodé
  • Vibreur de la sonnerie

Chaque domaine contient des configurations qui dictent les règles qui doivent avoir un impact sur le comportement. Notez que l'ordre de configuration est important. Assurez-vous que les configurations sont dans l'ordre requis. Une fois les règles d'une configuration validées, la configuration est sélectionnée.

Le code suivant présente un extrait d'exemple de fichier de framework de paramètres, qui peut être utilisé pour générer le fichier XML requis pour configurer les domaines configurables :

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

Le domaine DeviceForProductStrategies définit la manière dont les différentes règles doivent être appliquées lors de la sélection des appareils pour les stratégies produit. Les parties bleues décrivent les règles à prendre en compte, et la partie verte correspond à la configuration appliquée. Cet exemple particulier contient les configurations suivantes :

• Sélectionnez l'appareil Bluetooth A2DP pour la stratégie produit musical (ID 1000, vx_1000).
  • Si utilisé pour le contenu multimédia, n'exclut pas A2DP
  • Si utilisé pour la communication, n'est pas BT SCO
  • Si des appareils sont disponibles, inclut BT A2DP
• Sélectionner un appareil de bus
  • Si les appareils de bus sont disponibles
  • Si l'adresse est BUS00_MEDIA
• Sélectionnez un autre appareil de sortie par défaut.

Remarque : Ces configurations sont prises en compte dans l'ordre. Dans ce cas, la configuration de sélection d'A2DP est la première à être prise en compte et est appliquée si les règles correspondent.

Pour générer le fichier XML du moteur de règles configurable correspondant, exécutez les fichiers du framework de paramètres (PFW) via le système de compilation en définissant une règle de compilation à l'aide des étapes suivantes :

1. Dans le fichier Android.bp, créez un groupe de fichiers pour le fichier :

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Ajoutez le fichier aux autres fichiers PfW (le cas échéant).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. Créez la règle de génération de domaine correspondante :

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Où domaingeneratorpolicyrule est une règle de génération fournie par le framework pour générer le fichier PolicyConfigurableDomains.xml. Les autres fichiers sources (scrs) inclus dans les règles de génération de domaine sont les suivants :

   Source	Description
   audio_policy_pfw_toplevel	Fichier de configuration du framework de paramètres de premier niveau.
   audio_policy_pfw_structure_files	Fichiers de structure de génération de domaine, qui sont utilisés pour générer les fichiers de configuration.
   audio_policy_engine_criterion_types	Fichier XML des types de critères, décrivant les critères utilisés lors de la génération.
   edd_files	Liste des fichiers à domaine unique (chacun contenant une seule balise <ConfigurableDomain>).

Une fois la règle de génération exécutée dans la compilation, le fichier PolicyConfigurableDomains.xml est généré avec tous les domaines. Voici un extrait du fichier généré à l'aide de l'exemple de règles PfW :

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Remarque : Le PolicyConfigurableDomains.xml peut être lu par le service de règles audio ou par le nouveau HAL audio AIDL par défaut. Pour en savoir plus sur le chemin d'accès réel et la prise en charge d'Android, consultez la section Initialisation du CAP avant Android 16.

Débogage CAP

Vous pouvez utiliser remote-process pour vider les configurations CAP :

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Tous les domaines et configurations s'affichent, y compris les conditions d'application. Vous trouverez ci-dessous un extrait de l'appareil automobile Cuttlefish utilisant le Bluetooth A2DP, l'appareil de bus et les configurations par défaut. Consultez la section Configurations :

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Pour en savoir plus sur les autres commandes disponibles pour déboguer le framework de paramètres CAP, utilisez cet outil :

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Pour utiliser l'outil, les fabricants d'équipement d'origine doivent autoriser le réglage sur l'appareil. Pour vérifier si l'appareil autorise le réglage, utilisez la commande suivante :

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

Dans Android 15 et les versions antérieures, le fichier peut être différent. Utilisez donc la commande suivante :

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

Le fichier doit contenir TuningAllowed="true" ainsi que le port du serveur correspondant :

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Ce fichier est généré automatiquement en fonction du type d'image de compilation (ou utilisez un autre fichier pour release ou debug pour l'ancienne compilation). Un build de version définit TuningAllowed sur false sans port de socket (les sockets sont interdits pour cela dans les builds de version). Les versions Engineering et userdebug le définissent sur true avec le port de socket utilisé. Notez qu'il s'agit du fichier référencé par audio_policy_pfw_toplevel. L'outil de processus à distance doit également être inclus dans le fichier make ou build de l'appareil :

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

La règle SELinux correspondante pour autoriser les sockets doit également être incluse. Cela ne fonctionne que pour le mode débogage, car le mode Release interdit explicitement les sockets :

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Migration du CAP dans Android 16

Compte tenu des changements majeurs apportés par le moteur CAP du HAL audio AIDL et les versions précédentes, vous devez tenir compte de différents scénarios de transition des appareils. Cette section couvre les scénarios de transition les plus importants et fournit des recommandations pour activer la configuration du moteur CAP.

Scénario 1 : Nouvel appareil utilisant Android 16 ou version ultérieure, sans source précédente pour la configuration CAP de l'appareil

Un nouvel appareil doit être lancé avec Android 16 ou version ultérieure code sur la partition vendor. Cela signifie qu'il doit exposer la configuration configurable du moteur de règles audio via l'interface AIDL audio HAL. La configuration du moteur CAP de l'appareil doit être copiée à partir des exemples. Il ne doit pas y avoir de définition de domaine CAP PfW sur la partition vendor.

L'image système utilisée pour l'appareil est Android 16 ou version ultérieure. Le framework de service audio détecte la configuration CAP via l'interface AIDL audio HAL. Il initialise donc PfW à l'aide de la définition du domaine CAP PfW à partir de l'image système et charge la configuration CAP de l'appareil reçue via AIDL.

Pour obtenir un exemple, consultez l'appareil virtuel Cuttlefish pour l'automobile, qui a été introduit dans cette modification et peut être utilisé comme référence pour les fichiers, les règles de compilation et les fichiers Make requis pour configurer les fichiers de configuration nécessaires. Cela fonctionne avec les chargeurs fournis dans le HAL audio AIDL par défaut.

Scénario 2 : Nouvel appareil utilisant Android 16 ou version ultérieure, à partir d'un ancien appareil utilisant CAP

Un nouvel appareil doit être lancé avec Android 16 ou version ultérieure code sur la partition vendor. Toutefois, comme l'OEM dispose d'une configuration du moteur CAP utilisable, il peut l'utiliser comme point de départ (ou la réutiliser entièrement). La version AIDL de la configuration CAP présente quelques différences par rapport à la version Android 15 et antérieure. Le fournisseur doit donc convertir la configuration existante en AIDL. Consultez la section Stratégies produit pour connaître les modifications requises entre Android 16 et les versions antérieures. En général, le framework audio détecte et charge la configuration CAP de la même manière que dans le scénario 1.

Scénario 3 : Appareil existant avec CAP passant à Android 16 uniquement pour la partition système

Dans ce scénario, la partition vendor contient la version Android 15 ou antérieure de la configuration CAP de l'appareil, ainsi que la définition du domaine CAP PfW. La partition vendor n'est pas modifiée et continue donc d'utiliser HIDL HAL. Le framework suit le scénario Android 15 et versions antérieures, et charge toute la configuration liée à CAP à partir de la partition vendor.

Scénario 4 : Appareil existant lancé sur Android 15, avec CAP

Le CAP n'était pas compatible avec AIDL sur Android 15. Certains fournisseurs ont donc lancé de nouveaux appareils avec AIDL Audio HAL et CAP, qui étaient chargés par le framework audio. Ce mode hybride n'était pas officiel, mais il est inclus dans Android 16. Notez que ce mode ne doit pas être utilisé pour lancer de nouveaux appareils sous Android 16, mais plutôt pour permettre la mise à jour vers Android 16 des appareils existants avec le fournisseur Android 15 (mise à jour de la partition system).

Le framework audio détecte la configuration audio HAL audio AIDL sans la configuration CAP. Pour la configuration CAP, le service de règles audio (framework audio) revient au chargement de la configuration CAP à partir de la partition vendor. Dans ce cas, la définition du domaine CAP PfW et la configuration CAP de l'appareil doivent être chargées à partir de la partition vendor.

Récapitulatif de la migration des CAP

Le tableau suivant récapitule les configurations et exigences système et fournisseur compatibles avec la configuration CAP :

Partition système	Scénario	Version du code de partition du fournisseur	Type de HAL audio principal	Emplacement de la définition du domaine CAP PfW	Configuration du CAP de l'appareil
Android 15	4	Android 14 ou version antérieure	HIDL	vendor	Version HIDL
Android 16	3	Android 14 ou version antérieure	HIDL	vendor	Version HIDL
Android 16	4	Android 15	Aidl	vendor	Version HIDL
Android 16	2	Android 16	Aidl	system	Version AIDL convertie à partir de HIDL
Android 16	1	Android 16	Aidl	system	Version AIDL de l'exemple