Moteur de règles audio configurable

Dans Android 14, le système d'exploitation Android Automotive (AAOS) exploite le moteur de gestion audio de la voiture CAP (configurable audio policy) dans la zone audio principale. Plus précisément, le moteur CAP permet à l'AAOS de ne contrôler que le routage audio, le volume audio uniquement ou les deux à la fois. Vous pouvez utiliser les indicateurs suivants pour contrôler le comportement:

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

• Utilisez l'indicateur useCoreAudioRouting pour activer la gestion du routage audio CAP. Lorsque cette valeur est true, le service audio de la voiture utilise le routage configurable des règles 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 plug-ins et des règles pour gérer les 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 de produits audio
• Règles de 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 de gestion du volume et de la désactivation du son, ainsi que tableaux de volume

Initialisation de 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 le secteur automobile. 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 du moteur de règles audio configurables sont chargées dans le service de règles 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 règles audio.

Fichiers de structure CAP sous Android 15 ou version antérieure

Pour obtenir la structure et les paramètres, le service de stratégie 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"/>

Cela fait référence aux informations de structure du 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 stratégie audio. Cet exemple pour le secteur automobile fait référence aux fichiers de configuration des règles audio dans le dossier automobile. 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 sur Android 15 ou version antérieure

Comme pour la structure, les informations de paramétrage, 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 de framework de paramètres. Pour en savoir plus, consultez la section Configurations.

Initialisation de la capacité HAL audio AIDL

À partir d'Android 16, la définition de l'API HAL Audio AIDL 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 stratégie 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 complètement les informations concernant les stratégies de produits, les groupes de volumes et les critères.

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

Figure 5. API HAL audio AIDL

Dans cette configuration, le service de stratégie 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 audio 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 stratégie 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 de la configuration AIDL

Dans Android 16 et versions ultérieures, le service de stratégie audio obtient les informations de structure en lisant et en analysant le fichier ParameterFrameworkConfigurationCap.xml. Plus précisément, il récupère les informations du fichier de description de la structure:

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

Le framework place 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 produits, les structures sont configurées dans CapProductStrategies.xml.

Stratégies de produits par défaut

À partir des 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:

Stratégies produit définies par l'OEM

Le moteur configurable permet aux OEM de modifier la définition des stratégies produit. Pour continuer à y répondre, 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 de produits 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:

Stratégies produit

Les stratégies de produits permettent de personnaliser la façon dont les flux audio sont catégorisés et regroupés. Cela permet de configurer plus facilement les appareils audio, y compris la façon dont ils sont routés et la gestion de leur volume. 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 des contenus audio. Ils peuvent être un mélange des types suivants:

• Les types d'utilisation 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 d'indicateurs définissent différents comportements ou requêtes par rapport au flux.
• Les types de balises 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 présente un exemple de stratégie produit utilisée dans les émulateurs de voitures. Il contient deux attributs audio avec les valeurs "media" et "game", respectivement. Cette stratégie produit correspond au contexte audio MUSIC utilisé dans le service audio pour voitures, mais une telle mise en correspondance n'est pas obligatoire. L'un des principaux avantages pour les OEM qui utilisent 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é à tous les flux correspondant aux attributs audio appartenant au groupe d'attributs audio. L'exemple de stratégie de produits musicaux dans la section Stratégies de produits utilise 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:

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

Les courbes de groupe de volume contiennent un mappage point par point entre l'index du groupe de volume et le gain de volume en millibels. Les points fournis sont utilisés pour interpoler de manière linéaire le gain de correspondance 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 multimédia 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 lancé, le dernier index de volume défini pour le groupe de volume multimédia est utilisé. Dans ce cas, la courbe de la catégorie d'appareils correspondante est sélectionnée en fonction de l'appareil sélectionné, et le gain correspondant est défini lorsque le flux est lancé.

Configurations

Dans le moteur CAP, les configurations permettent de 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 illustré dans la figure 5, l'API contient plusieurs domaines, dont l'objectif est de diviser la logique en problèmes de routage plus petits à résoudre (par exemple, appareil 1, appareil 2).

Chaque domaine possède des configurations, et chaque configuration possède un ensemble de règles. Les règles sont établies en fonction des critères fournis par AudioPolicyManager:

• Mode audio
• Appareils 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
  • Audio du système HDMI
  • Son surround encodé
  • Sonnerie en mode vibreur

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 et qu'il est important de s'assurer 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 d'un 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 comment les différentes règles doivent être appliquées lors de la gestion de la sélection des appareils pour les stratégies de produits. 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électionner un appareil Bluetooth A2DP pour la stratégie de produits musicaux (ID 1000, vx_1000)
  • Si utilisé pour les contenus multimédias, n'exclut pas A2DP
  • Si utilisé pour la communication, n'est pas BT SCO
  • Si des appareils sont disponibles, incluez BT A2DP
• Sélectionner un appareil de bus
  • Si des appareils de bus sont disponibles
  • Si l'adresse est BUS00_MEDIA
• Sélectionnez un appareil de sortie par défaut

Pour générer le fichier XML du moteur de règles configurable correspondant, exécutez les fichiers de framework de paramètres (PFW) via le système de compilation en définissant une règle de compilation en procédant comme suit:

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 à d'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 domaines sont les suivants:

   Source	Description
   audio_policy_pfw_toplevel	Fichier de configuration de framework de paramètres de niveau supérieur.
   audio_policy_pfw_structure_files	Fichiers de structure de génération de domaine, 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 de fichiers de domaine unique (chacun contenant une seule balise <ConfigurableDomain>).

Après l'exécution de la règle de génération dans la compilation, 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>

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 OEM doivent autoriser le réglage sur l'appareil. Pour vérifier si l'appareil permet le réglage, utilisez la commande suivante:

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

Sous Android 15 et 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 de 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 fichier différent pour la version ou le débogage pour l'ancienne version). Un build définit TuningAllowed sur false sans port de socket (les sockets sont interdits à cet effet dans les builds). Les builds d'ingénierie et de 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 de compilation 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 de publication interdit explicitement les sockets:

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

Migration CAP dans Android 16

Compte tenu des modifications majeures apportées par le moteur HAL CAP audio AIDL et les versions précédentes, vous devez envisager différents scénarios de transition d'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 équipé d'Android 16 ou version ultérieure, aucune source précédente pour la configuration CAP de l'appareil

Un nouvel appareil doit se lancer avec le code Android 16 ou version ultérieure sur la partition vendor. Autrement dit, il doit exposer la configuration du moteur de règles audio configurable via l'interface HAL audio AIDL. La configuration du moteur CAP de l'appareil doit être copiée à partir des exemples. Aucune définition de domaine PfW CAP ne doit être définie 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 HAL audio AIDL. Il initialise donc PfW à l'aide de la définition de domaine CAP PfW à partir de l'image système et charge la configuration CAP de l'appareil reçue via AIDL.

Pour en savoir plus, consultez le dispositif virtuel Cuttlefish pour l'automobile, qui a été introduit dans cette modification et peut être référencé pour les fichiers, les règles de compilation et les fichiers de compilation requis pour configurer les fichiers de configuration requis. Cela fonctionne avec les chargeurs fournis dans le HAL audio AIDL par défaut.

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

Un nouvel appareil doit se lancer avec le code Android 16 ou version ultérieure sur la partition vendor. Toutefois, comme l'OEM dispose d'une configuration de moteur CAP d'appareil utilisable, il souhaite l'utiliser comme point de départ (ou la réutiliser entièrement). La version AIDL de la configuration CAP présente quelques modifications par rapport à la version Android 15 et versions antérieures. Le fournisseur doit donc convertir la configuration existante en AIDL. Pour connaître les modifications requises entre Android 16 et les versions antérieures, consultez la section Stratégies produit. En règle générale, 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 mise à jour de la partition système vers Android 16 avec CAP

Dans ce scénario, la partition vendor contient la version Android 15 et 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. Elle utilise donc toujours le HAL HIDL. 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 publié sur Android 15, avec CAP

CAP n'était pas compatible avec AIDL sur Android 15. Certains fournisseurs ont donc lancé de nouveaux appareils avec HAL Audio AIDL et CAP, qui étaient chargés par le framework audio. Ce mode hybride était non officiel, mais il est inclus dans Android 16. Notez que ce mode ne doit pas être utilisé pour lancer de nouveaux appareils sur Android 16, mais plutôt pour permettre la mise à jour des appareils existants avec le fournisseur Android 15 vers Android 16 (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 stratégie audio (framework audio) revient à charger 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 CAP

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