Motore di criteri audio configurabile

In Android 14, il sistema operativo Android Automotive (AAOS) sfrutta il motore di gestione dell'audio dell'auto con criteri audio configurabili (CAP) all'interno della zona audio principale. Nello specifico, il motore CAP consente ad AAOS di controllare solo il routing audio, solo il volume audio o contemporaneamente il routing e il volume. Per controllare il comportamento, puoi utilizzare i seguenti flag:

• Utilizza il flag useCoreAudioVolume per attivare la gestione del volume CAP. Quando questo valore è true, il servizio audio dell'auto utilizza le API di gestione audio per gestire i gruppi di volume.

• Utilizza il flag useCoreAudioRouting per attivare la gestione del routing audio CAP. Quando questo valore è true, il servizio audio per auto utilizza il routing del criterio audio configurabile per gestire il routing audio.

Il motore di criteri audio è supportato anche in Android per impostazione predefinita sotto forma di motore di criteri audio predefinito.

Sfondo

Il motore CAP si basa sul framework di parametri di Intel, che è un framework basato su plug-in e regole per la gestione dei parametri. In particolare, per la gestione dell'audio di Android, il motore CAP ha introdotto la possibilità di definire regole per i file XML per specificare quanto segue:

• Strategia per i prodotti audio
• Regole per la selezione del dispositivo di uscita audio
• Regole per la selezione del dispositivo di input audio
• Regole per gestire il volume e la disattivazione audio, oltre alle tabelle del volume

Inizializzazione del CAP prima di Android 16

La figura seguente mostra una panoramica di alto livello della gestione della configurazione del motore di criteri audio configurabile a partire da Android 6:

Figura 1. Gestione della configurazione del motore CAP a partire da Android 6.

Come mostrato nella figura, la configurazione del motore CAP viene ottenuta dal servizio di norme relative all'audio analizzando le informazioni del audio_policy_engine_configuration.xml file nella partizione vendor. Il file di configurazione del motore CAP utilizza lo schema definito in audio_policy_engine_configuration.xsd per ottenere le informazioni richieste. audio_policy_engine_configuration.xml è un esempio per il settore auto e motori. Esempi simili per altri fattori di forma sono disponibili nella cartella frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

La figura seguente mostra informazioni più dettagliate su come vengono caricate le informazioni del motore di criteri audio configurabili all'interno del servizio di criteri audio. In questo caso, il framework dei parametri carica la struttura e le impostazioni dai file XML.

Figura 2. Informazioni CAP caricate all'interno del servizio di norme audio.

File di struttura CAP in Android 15 e versioni precedenti

Per ottenere la struttura e le impostazioni, il servizio di norme relative all'audio legge il file ParameterFrameworkConfigurationPolicy.xml. Questo fa riferimento alle informazioni sulla struttura tramite la posizione del file descript della struttura:

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

Questo indica le informazioni sulla struttura nel file:

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

In Android è fornita una struttura scheletro. Le informazioni sulla struttura richiedono informazioni sulla struttura della strategia di prodotto, pertanto Android fornisce lo buildStrategiesStructureFile.py strumento di generazione, che può generare informazioni dal file XML della strategia di prodotto disponibile. A questo valore è possibile fare riferimento tramite genrule default buildstrategiesstructurerule come segue:

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

dove audio_policy_engine_configuration_files è il motore di criteri audio file di configurazione. Questo esempio per il settore auto e motori fa riferimento ai file di configurazione dei criteri audio nella cartella automotive. Altri esempi mostrano come configurare una build per inviare i file nella partizione del fornitore del dispositivo.

File di impostazioni CAP in Android 15 e versioni precedenti

Analogamente alla struttura, le informazioni di impostazione, che rappresentano le regole e i valori dei parametri, vengono richiamate nel file ParameterFrameworkConfigurationPolicy.xml come:

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

Android fornisce anche strumenti di compilazione per generare queste informazioni utilizzando la configurazione del motore di criteri audio e i file del framework dei parametri. Per ulteriori informazioni, consulta Configurazioni.

Inizializzazione del CAP HAL audio AIDL

A partire da Android 16, la definizione dell'API HAL Audio AIDL viene espansa con le configurazioni del motore di criteri audio, AudioHalCapConfiguration.aidl. La figura seguente mostra una panoramica generale della gestione della configurazione dell'engine CAP a partire da Android 16:

Figura 3. Gestione della configurazione del motore CAP a partire da Android 16.

Il servizio di norme audio ottiene le informazioni del motore CAP utilizzando direttamente le API HAL Audio AIDL anziché analizzare le informazioni dai file XML nella partizione del fornitore del dispositivo.

In questa configurazione, la struttura del framework dei parametri viene comunque caricata dal motore CAP lato server audio.

Figura 4. Struttura del motore CAP.

In ogni caso, la configurazione deve specificare completamente le informazioni relative alle strategie di prodotto, ai gruppi di volumi e ai criteri.

La figura seguente mostra una panoramica di alto livello delle API HAL audio AIDL che vengono utilizzate dal servizio di norme audio per ottenere la configurazione dell'engine CAP:

Figura 5. API HAL audio AIDL.

In questa configurazione, il servizio di criteri audio ottiene le seguenti informazioni dall'HAL audio AIDL:

• Configurazione
• Strategies
• Volumi
• Criteri
• Impostazioni

Caricatore HAL Audio AIDL predefinito

Per semplificare la transizione da HIDL ad AIDL, l'HAL Audio AIDL audio predefinito fornisce un caricatore dell'engine CAP XML. I fornitori possono utilizzare questo caricatore direttamente estendendo l'HAL audio con l'HAL audio predefinito o facendo riferimento alla raccolta libaudioserviceexampleimpl.

Il caricatore HAL audio AIDL predefinito utilizza audio_policy_engine_configuration.xml per ottenere le seguenti informazioni:

• Configurazione
• Strategies
• Volumi
• Criteri

Le informazioni sulla struttura vengono ottenute dal file PolicyConfigurableDomains.xml. La differenza principale rispetto al meccanismo precedente è che le informazioni sulla struttura vengono ottenute anche dall'HAL audio AIDL anziché dal framework dei parametri del servizio di criteri audio.

I fornitori possono utilizzare lo strumento domaingeneratorpolicyrule per generare i domini configurabili utilizzando le informazioni della configurazione del motore di criteri audio. L'esempio di dispositivo virtuale Cuttlefish per l'automotive può essere utilizzato come riferimento.

Struttura nella configurazione AIDL

In Android 16 e versioni successive, il servizio di norme audio ottiene le informazioni sulla struttura leggendo e analizzando il ParameterFrameworkConfigurationCap.xml file. In particolare, recupera le informazioni dal file di descrizione della struttura:

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

Il framework inserisce i file richiesti nella /etc/parameter-framework/ directory con le informazioni necessarie.

La struttura rappresenta i parametri che devono essere controllati, pertanto deve essere fatto riferimento a questi parametri nella configurazione o nei domini. Per questo, il motore AIDL debe usare un nome predeterminato per i parametri. Per le strategie di prodotto, le strutture sono configurate in CapProductStrategies.xml.

Strategie di prodotto predefinite

A partire dai valori predefiniti forniti nel motore predefinito, le strategie di prodotto iniziano con il prefisso STRATEGY_:

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

Questo formato è stato fornito per semplificare la transizione da HIDL ad AIDL per i dispositivi che utilizzavano le strategie predefinite. Questa modifica del formato ha alcune implicazioni per i file esistenti (ad esempio PfW, XML) utilizzati per configurare il motore. In particolare, tutti i riferimenti alla strategia di prodotto devono essere modificati in modo da utilizzare i nuovi nomi, ad esempio:

Strategie di prodotto definite dall'OEM

Il motore configurabile consente agli OEM di modificare la definizione delle strategie di prodotto. Per continuare a supportare questa funzionalità, il file di strategia per il prodotto CapProductStrategies.xml fornisce anche 40 strategie di prodotto estensibili dal fornitore da vx_1000 a vx_1039. Tutte le estensioni del fornitore devono iniziare con il prefisso vx_ e essere seguite da un numero che rappresenta l'ID strategia di prodotto nella definizione della strategia di prodotto HAL audio AIDL. Il resto delle definizioni (ad esempio gruppi di attributi audio, nome) viene ottenuto dall'oggetto AudioHALProductStrategy nella configurazione dell'audio HAL engine.

Analogamente alle strategie di prodotto predefinite, anche i riferimenti agli OEM definiti dal fornitore devono essere adattati tra la configurazione non AIDL e la configurazione AIDL, ad esempio:

Strategie di prodotto

Le strategie di prodotto consentono di personalizzare la classificazione e il raggruppamento degli stream audio. Ciò consente una maggiore flessibilità nella configurazione dei dispositivi audio, incluso il modo in cui vengono indirizzati e gestiti i relativi volumi. Ogni strategia di prodotto può avere uno o più gruppi di attributi audio che identificano gli stream da associare a quella strategia. Questi gruppi di attributi audio consentono un approccio più granulare alla classificazione dell'audio e possono essere una combinazione dei seguenti tipi:

• I tipi di utilizzo descrive il motivo per cui viene riprodotto un suono (ad esempio, contenuti multimediali, notifiche, chiamate).
• I tipi di contenuti descrivono cosa viene riprodotto (ad es. musica, voce, video, sonificazione).
• I tipi di flag definiscono comportamenti o richieste diversi rispetto allo stream.
• I tipi di tag supportano qualsiasi elenco arbitrario di valori di stringa del fornitore.
  • Ogni stringa deve iniziare con VX_ seguita da una stringa alfanumerica (ad es. 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>

Questo estratto mostra un esempio di strategia di prodotto utilizzata negli emulatori di auto. Contiene due attributi audio con rispettivamente media e gioco per l'utilizzo dell'audio. Questa strategia di prodotto corrisponde al MUSIC contesto audio utilizzato nel servizio audio per auto, ma non è necessario che sia così. Una delle utilità principali per gli OEM che utilizzano il CAP insieme ad Android è consentire definizioni di raggruppamento audio più flessibili.

Gruppi di volumi

Inoltre, ogni gruppo di attributi audio deve avere un gruppo di volumi associato. Questo gruppo di volumi è associato a qualsiasi stream che corrisponda agli attributi audio appartenenti al gruppo di attributi audio. La strategia di prodotto musicale di esempio nella sezione Strategie di prodotto ha il gruppo di volume media e la definizione del gruppo di volume dei contenuti multimediali è la seguente:

<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>

In questa definizione, il gruppo di volumi contiene:

• Nome del gruppo
• Indice minimo del gruppo
• Indice massimo del gruppo
• Curve del gruppo di volumi

Le curve del gruppo di volumi contengono una mappatura punto per punto tra l'indice del gruppo di volumi e il guadagno del volume in millibel. I punti forniti vengono utilizzati per interpolare linearmente il miglior guadagno di corrispondenza quando il volume viene gestito. Ogni curva del gruppo di volumi è associata a una categoria di tipo di dispositivo (ad esempio cuffie, altoparlanti, dispositivi multimediali esterni).

Il gruppo di volume gestisce il volume degli stream che fanno parte del gruppo di attributi audio. Ad esempio, quando viene avviato uno stream con attributi audio contenenti musica o giochi, viene utilizzato l'ultimo indice di volume impostato per il gruppo di volume dei contenuti multimediali. In questo caso, la curva della categoria del dispositivo corrispondente viene selezionata in base al dispositivo selezionato e il guadagno corrispondente viene impostato all'avvio dello stream.

Configurations (Configurazioni)

Nel motore CAP, le configurazioni vengono utilizzate per definire le condizioni o le regole che determinano il comportamento dell'audio. Queste configurazioni vengono valutate in fase di esecuzione per selezionare le regole appropriate da applicare in base allo stato attuale dell'impianto audio.

Come mostrato nella figura 5, l'API contiene più domini, il cui scopo è suddividere la logica in problemi di routing più piccoli da risolvere (ad esempio, dispositivo 1, dispositivo 2).

Ogni dominio ha configurazioni e ogni configurazione ha un insieme di regole. Le regole vengono stabilite in base a criteri forniti da AudioPolicyManager:

• Modalità audio
• Dispositivi di input e output disponibili
• Indirizzi dei dispositivi di input e output disponibili
• Da utilizzare per
  • Contenuti multimediali
  • Comunicazione
  • Registrazione in corso…
  • Dock
  • Sistema
  • Audio di sistema HDMI
  • Audio surround codificato
  • Vibrazione squillo

Ogni dominio contiene configurazioni che stabiliscono le regole che devono influire sul comportamento. Tieni presente che l'ordine di configurazione è importante ed è importante assicurarti che le configurazioni siano nell'ordine richiesto. Dopo la convalida delle regole per una configurazione, la configurazione viene selezionata.

Il seguente codice mostra un esempio di estratto di un file del framework dei parametri, che può essere utilizzato per generare il file XML necessario per la configurazione dei domini configurabili:

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

Il dominio DeviceForProductStrategies definisce come devono essere applicate regole diverse per gestire la selezione dei dispositivi per le strategie di prodotto. Le parti blu descrivono le regole da considerare e la parte verde è la configurazione applicata. Questo esempio specifico contiene le seguenti configurazioni:

• Seleziona il dispositivo Bluetooth A2DP per la strategia di prodotto musicale (ID 1000, vx_1000)
  • Se utilizzato per i contenuti multimediali, non esclude A2DP
  • Se utilizzato per la comunicazione, non è BT SCO
  • Se sono disponibili dispositivi, includi BT A2DP
• Seleziona il dispositivo bus
  • Se sono disponibili dispositivi di bus
  • Se l'indirizzo è BUS00_MEDIA
• In caso contrario, seleziona il dispositivo di uscita predefinito

Per generare il file XML del motore di criteri configurabile corrispondente, esegui i file del framework di parametri (PFW) tramite il sistema di compilazione, definendo una regola di compilazione seguendo questi passaggi:

1. Nel file Android.bp, crea un gruppo di file per il file:

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

2. Aggiungi il file ad altri file PfW (se presenti).

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

3. Crea la regola di generazione del dominio corrispondente:

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

   dove domaingeneratorpolicyrule è una regola di generazione fornita dal framework per generare il PolicyConfigurableDomains.xml file. Gli altri file di origine (scrs) inclusi nelle regole di generazione del dominio sono:

   Fonte	Descrizione
   audio_policy_pfw_toplevel	File di configurazione del framework di parametri di primo livello.
   audio_policy_pfw_structure_files	File di struttura di generazione del dominio, utilizzati per generare i file di configurazione.
   audio_policy_engine_criterion_types	File XML dei tipi di criteri che descrive i criteri utilizzati durante la generazione.
   edd_files	Elenco di singoli file di dominio (ciascuno contenente un singolo tag <ConfigurableDomain>).

Dopo aver eseguito la regola di generazione nella compilazione, viene generato il file PolicyConfigurableDomains.xml con tutti i domini. Di seguito è riportato un estratto del file generato utilizzando le regole dell'esempio 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>

Debug CAP

Puoi utilizzare il comando remote-process per eseguire il dump delle configurazioni CAP:

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

Vengono visualizzati tutti i domini e le configurazioni, incluse le condizioni di applicabilità. Di seguito è riportato un estratto del dispositivo auto Cuttlefish che utilizza il protocollo Bluetooth A2DP, il dispositivo bus e le configurazioni predefinite. Consulta Configurazioni:

- 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

Per ulteriori informazioni sugli altri comandi disponibili per eseguire il debug del framework del parametro CAP, utilizza questo strumento:

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

Per utilizzare lo strumento, i produttori OEM devono consentire la sintonizzazione sul dispositivo. Per verificare se il dispositivo consente la sintonizzazione, utilizza il seguente comando:

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

In Android 15 e versioni precedenti, il file potrebbe essere diverso, quindi utilizza il seguente comando:

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

Il file deve contenere TuningAllowed="true" insieme alla porta del server corrispondente:

<?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>

Questo file viene generato automaticamente in base al tipo di immagine di compilazione (oppure puoi utilizzare un file diverso per release o debug per la compilazione precedente). Una release build imposta TuningAllowed su false senza una porta socket (le socket sono vietate per questo nelle release build). Le compilazioni di engineering e userdebug lo impostano su true con la porta socket utilizzata. Tieni presente che questo è il file a cui fa riferimento audio_policy_pfw_toplevel. Lo strumento di elaborazione remota deve essere incluso anche nel file make o di compilazione del dispositivo:

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

Deve essere incluso anche il corrispondente criterio SELinux per consentire le socket. Questo funziona solo per la modalità di debug perché la modalità di rilascio non consente esplicitamente le socket:

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

Migrazione a CAP in Android 16

Date le modifiche significative apportate dal motore CAP HAL audio AIDL e dalle versioni precedenti, esistono vari scenari di transizione dei dispositivi da prendere in considerazione. Questa sezione illustra gli scenari di transizione più importanti e fornisce consigli per le operazioni necessarie per attivare la configurazione dell'engine CAP.

Scenario 1: nuovo dispositivo che utilizza Android 16 o versioni successive, nessuna origine precedente per la configurazione del CAP del dispositivo

Un nuovo dispositivo deve essere lanciato con codice Android 16 o versioni successive nella partizione vendor. Ciò significa che deve esporre la configurazione del motore di criteri audio configurabile tramite l'interfaccia HAL audio AIDL. La configurazione del motore Device Agent Protocol (CAP) deve essere copiata dagli esempi. Non deve essere presente alcuna definizione del dominio CAP PfW nella partizione vendor.

L'immagine di sistema utilizzata per il dispositivo è Android 16 o superiore. Il framework del servizio audio rileva la configurazione CAP tramite l'interfaccia HAL audio AIDL, quindi inizializza PfW utilizzando la definizione del dominio CAP PfW dall'immagine di sistema e carica la configurazione CAP del dispositivo ricevuta tramite AIDL.

Per un esempio, consulta il dispositivo virtuale Cuttlefish per l'automotive, introdotto in questa modifica e a cui è possibile fare riferimento per i file, le regole di compilazione e i file make necessari per la configurazione dei file di configurazione richiesti. Questo funziona con i caricatori forniti nell'HAL audio AIDL predefinito.

Scenario 2: nuovo dispositivo con Android 16 o versioni successive, da un dispositivo precedente che utilizza CAP

Un nuovo dispositivo deve essere lanciato con codice Android 16 o versioni successive nella partizione vendor. Tuttavia, poiché l'OEM dispone di una configurazione del motore CAP del dispositivo utilizzabile, vorrebbe utilizzarla come punto di partenza (o riutilizzarla completamente). La versione AIDL della configurazione CAP presenta alcune modifiche rispetto alla versione Android 15 e precedenti, pertanto il fornitore deve convertire la configurazione esistente in AIDL. Consulta la discussione in Strategie di prodotto per le modifiche tra Android 16 e le versioni precedenti per le modifiche richieste. In generale, il framework audio rileva e carica la configurazione CAP allo stesso modo dello scenario 1.

Scenario 3: dispositivo esistente con CAP che esegue l'aggiornamento ad Android 16 solo della partizione di sistema

In questo scenario, la partizione vendor contiene la versione Android 15 e precedenti della configurazione CAP del dispositivo e la definizione del dominio CAP PfW. La partizione vendor non viene modificata, quindi utilizza ancora l'HAL HIDL. Il framework segue lo scenario di Android 15 e versioni precedenti e carica tutta la configurazione relativa al CAP dalla partizione vendor.

Scenario 4: dispositivo esistente rilasciato su Android 15, con CAP

CAP non era supportato in AIDL su Android 15, pertanto alcuni fornitori hanno rilasciato nuovi dispositivi con HAL Audio AIDL e CAP, caricati dal framework audio. Questa modalità ibrida non era ufficiale, ma è inclusa in Android 16. Tieni presente che questa modalità non deve essere utilizzata per il rilascio di nuovi dispositivi su Android 16, ma per consentire l'aggiornamento ad Android 16 dei dispositivi esistenti con il fornitore Android 15 (l'aggiornamento della partizione system).

Il framework audio rileva la configurazione audio HAL audio AIDL senza la configurazione CAP. Per la configurazione del CAP, il servizio di criteri audio (audio framework) ricorre al caricamento della configurazione del CAP dalla partizione vendor. In questo caso, sia la definizione del dominio CAP PfW sia la configurazione del CAP del dispositivo devono essere caricate dalla partizione vendor.

Riepilogo della migrazione CAP

La seguente tabella riassume le configurazioni e i requisiti del sistema e del fornitore compatibili per la configurazione del CAP: