A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Motore di criteri audio configurabile

In Android 14, il sistema operativo Android Automotive (AAOS) sfrutta la gestione dell'audio dell'auto del motore Configurable Audio Policy (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 sia il routing che il volume contemporaneamente. 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 Audio Manager per gestire i gruppi di volumi.
Utilizza il flag useCoreAudioRouting per attivare la gestione del routing audio CAP. Quando questo valore è true, il servizio audio dell'auto utilizza il routing dei criteri 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 dei parametri di Intel, che è un framework basato su plug-in e regole per la gestione dei parametri. Per la gestione dell'audio di Android in particolare, 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 il silenziamento insieme alle tabelle del volume

Inizializzazione CAP prima di Android 16

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

Architettura del motore CAP pre-Android 16

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

Come mostrato in figura, la configurazione del motore CAP viene ottenuta dal servizio di policy 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 automobilistico. Esempi simili per altri fattori di forma si trovano 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 policy audio configurabile all'interno del servizio di policy audio. In questo caso, il framework dei parametri carica la struttura e le impostazioni dai file XML.

Percorso di caricamento del motore CAP pre-Android 16

Figura 2. Informazioni CAP caricate nel servizio norme audio.

File di struttura CAP in Android 15 e versioni precedenti

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

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

Indica le informazioni sulla struttura nel file:

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

In Android viene fornita una struttura scheletrica. Le informazioni sulla struttura richiedono le 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. È possibile fare riferimento a questo valore tramite genrule default buildstrategiesstructurerule nel seguente modo:

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

dove audio_policy_engine_configuration_files sono i file di configurazione del motore delle policy audio. Questo esempio per il settore automobilistico fa riferimento ai file di configurazione delle norme audio nella cartella automotive. Altri esempi mostrano come configurare una build per trasferire i file nella partizione del fornitore del dispositivo.

File delle impostazioni CAP in Android 15 e versioni precedenti

Analogamente alla struttura, le informazioni sulle impostazioni, che rappresentano regole e valori dei parametri, vengono indicate 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 delle norme audio e i file del framework dei parametri. Per ulteriori informazioni, consulta la sezione Configurazioni.

Inizializzazione di AIDL audio HAL CAP

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

Architettura AIDL del motore CAP

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

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

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

Percorso di caricamento AIDL del motore CAP

Figura 4. Struttura del motore CAP.

In tutti i casi, la configurazione deve specificare completamente le informazioni relative alle strategie per i prodotti, ai gruppi di volume e ai criteri.

La figura seguente mostra una panoramica di alto livello delle API HAL audio AIDL utilizzate dal servizio di policy audio per ottenere la configurazione del motore CAP:

API AIDL del motore CAP Figura 5. API HAL audio AIDL.

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

Configurazione
Strategies
Volumi
Criteri
Impostazioni

Default AIDL Audio HAL loader

Per semplificare la transizione da HIDL ad AIDL, l'HAL audio AIDL predefinito fornisce un caricatore del motore CAP XML. I fornitori possono utilizzare questo caricatore direttamente estendendo l'HAL audio con l'HAL audio predefinito o facendo riferimento alla libreria 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 nel servizio delle norme audio.

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

Struttura nella configurazione AIDL

In Android 16 e versioni successive, il servizio di criteri audio ottiene le informazioni sulla struttura leggendo e analizzando il ParameterFrameworkConfigurationCap.xml [file](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). In particolare, ottiene le informazioni dal file di descrizione della struttura:

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

Il framework rilascia i file richiesti nella cartella /etc/parameter-framework/ con le informazioni necessarie.

La struttura rappresenta i parametri da controllare, quindi deve essere indicata nella configurazione o nei domini. A questo scopo, la configurazione del motore AIDL deve utilizzare 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 facilitare la transizione da HIDL ad AIDL per i dispositivi che utilizzavano 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:

Nome del parametro di configurazione non AIDL
`/Policy/policy/product_strategies/media/device_address` `/Policy/policy/product_strategies/media/selected_output_devices/mask`

Nome del parametro di configurazione AIDL
`/Policy/policy/product_strategies/STRATEGY_MEDIA/device_address` `/Policy/policy/product_strategies/STRATEGY_MEDIA/selected_output_devices/mask`

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 per il prodotto estendibili dal fornitore da vx_1000 a vx_1039 . Tutte le estensioni del fornitore devono iniziare con il prefisso vx_ e proseguire con un numero che rappresenta l'ID strategia di prodotto nella definizione della strategia di prodotto AIDL audio HAL. Il resto delle definizioni (ad esempio, gruppi di attributi audio, nome) viene ottenuto dall'oggetto AudioHALProductStrategy nella configurazione del motore HAL audio.

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

Nome del parametro di configurazione non AIDL
`/Policy/policy/product_strategies/oem_extension_strategy/device_address` `/Policy/policy/product_strategies/oem_extension_strategy/selected_output_devices/mask`

Nome del parametro di configurazione AIDL
`/Policy/policy/product_strategies/vx_1037/device_address` `/Policy/policy/product_strategies/vx_1037/selected_output_devices/mask`

Strategie per il prodotto

Le strategie per prodotto consentono di personalizzare la modalità di classificazione e raggruppamento dei flussi audio. Ciò consente una maggiore flessibilità nella configurazione dei dispositivi audio, inclusi il routing e la gestione dei volumi. Ogni strategia per prodotto può avere uno o più gruppi di attributi audio, che identificano gli stream da associare a quella strategia per prodotto. Questi gruppi di attributi audio consentono un approccio più granulare alla categorizzazione dell'audio e possono essere una combinazione dei seguenti tipi:

I tipi di utilizzo descrivono il motivo per cui viene riprodotto un suono (ad es. contenuti multimediali, notifica, chiamata).
Tipo di contenuti I tipi descrivono ciò che viene riprodotto (musica, parlato, video, sonificazione).
I tipi di flag definiscono comportamenti o richieste diversi rispetto allo stream.
I tipi di tag supportano qualsiasi elenco arbitrario di valori stringa del fornitore.
- Ogni stringa deve iniziare con VX_ seguito da una stringa alfanumerica (ad esempio, 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 i media di utilizzo audio e il gioco rispettivamente. Questa strategia di prodotto corrisponde al MUSIC contesto audio utilizzato nel servizio audio per auto, ma non è necessario che ci sia una corrispondenza. Una delle principali utilità per gli OEM che utilizzano CAP insieme ad Android è quella di consentire definizioni di raggruppamento audio più flessibili.

Gruppi di volumi

Inoltre, ogni gruppo di attributi audio deve avere un gruppo di volume associato. Questo gruppo di volumi è associato a qualsiasi flusso che corrisponda agli attributi audio appartenenti al gruppo di attributi audio. La strategia di esempio per i prodotti musicali nella sezione Strategie di prodotto ha il gruppo di volumi media e la definizione del gruppo di volumi 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 volume contengono una mappatura puntuale tra l'indice del gruppo di volume e il guadagno di volume in millibel. I punti forniti vengono utilizzati per interpolare linearmente il guadagno di corrispondenza migliore quando il volume viene gestito. Ogni curva del gruppo di volumi è associata a una categoria di tipo di dispositivo (ad esempio cuffie, speaker, contenuti multimediali esterni).

Il gruppo di volumi 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 un gioco, viene utilizzato l'ultimo indice di volume impostato per il gruppo di volume dei contenuti multimediali. In questo caso, la curva della categoria di 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 runtime per selezionare le regole appropriate da applicare in base allo stato attuale del sistema audio.

Come mostrato nella figura 5, l'API contiene più domini, lo scopo di ogni dominio è quello di dividere 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 sono stabilite in base ai criteri forniti da AudioPolicyManager:

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

Ogni dominio contiene configurazioni che dettano le regole che devono influire sul comportamento. Tieni presente che l'ordine di configurazione è importante e che le configurazioni devono essere nell'ordine richiesto. Una volta convalidate le regole per una configurazione, quest'ultima viene selezionata.

Il seguente codice mostra un esempio di estratto di un file framework dei parametri, che può essere utilizzato per generare il file XML richiesto per configurare i 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 le diverse regole quando si gestisce la selezione dei dispositivi per le strategie di prodotto. Le parti blu descrivono le regole da considerare, mentre la parte verde indica la configurazione applicata. Questo esempio specifico contiene le seguenti configurazioni:

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

Per generare il file XML del motore delle policy configurabile corrispondente, esegui i file parameter-framework (PFW) tramite il sistema di build definendo una regola di build utilizzando i seguenti passaggi:

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"],
}

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",
    ],
}

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 file PolicyConfigurableDomains.xml. Gli altri file di origine (scrs) inclusi nelle regole di generazione del dominio sono i seguenti:

Fonte	Descrizione
`audio_policy_pfw_toplevel`	File di configurazione del framework dei parametri di primo livello.
`audio_policy_pfw_structure_files`	File di struttura per la generazione di domini, 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 file di un singolo dominio (ognuno contenente un singolo tag <ConfigurableDomain>).

Dopo aver eseguito la regola di generazione nella build, viene generato il 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 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 automobilistico Cuttlefish che utilizza le configurazioni Bluetooth A2DP, del dispositivo bus e predefinite. Consulta la sezione 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 su altri comandi disponibili per eseguire il debug dell'utilizzo del framework dei parametri 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 regolazione nel dispositivo. Per verificare se il dispositivo consente la regolazione, 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 è generato automaticamente in base al tipo di immagine di build (o utilizza un file diverso per release o debug per la build legacy). Una build di release imposta TuningAllowed su false senza una porta socket (i socket sono vietati per questo nelle build di release). Engineering and userdebug builds set it to true with the socket port used. 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 di make o di build del dispositivo:

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

Deve essere inclusa anche la policy SELinux corrispondente per consentire i socket. Questo funziona solo per la modalità di debug perché la modalità di rilascio non consente esplicitamente i socket:

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

Migrazione di CAP in Android 16

Date le modifiche significative apportate dal motore HAL CAP audio AIDL e dalle versioni precedenti, esistono vari scenari di transizione dei dispositivi da considerare. Questa sezione illustra gli scenari di transizione più importanti e fornisce consigli per il lavoro da svolgere per abilitare la configurazione del motore CAP.

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

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

L'immagine di sistema utilizzata per il dispositivo è Android 16 o versioni successive. Il framework del servizio audio rileva la configurazione CAP tramite l'interfaccia AIDL audio HAL, 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, vedi il dispositivo virtuale Cuttlefish per il settore automobilistico, introdotto in questa modifica e a cui è possibile fare riferimento per i file richiesti, le regole di compilazione e i file make necessari per configurare i file di configurazione richiesti. 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 Android 16 o versioni successive nella partizione vendor. Tuttavia, poiché l'OEM dispone di una configurazione del motore CAP del dispositivo utilizzabile, vorrà 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 sezione Strategie di prodotto per le modifiche tra Android 16 e 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 aggiornamento CAP ad Android 16 solo della partizione di sistema

In questo scenario, la partizione vendor contiene la configurazione CAP del dispositivo per Android 15 e versioni precedenti e la definizione del dominio CAP PfW. La partizione vendor è rimasta invariata, quindi continua a utilizzare HIDL HAL. Il framework segue lo scenario Android 15 e versioni precedenti e carica tutta la configurazione correlata a CAP dalla partizione vendor.

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

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

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

Riepilogo della migrazione CAP

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

Partizione di sistema	Scenario	Versione del codice di partizione del fornitore	Tipo di HAL audio principale	Posizione della definizione del dominio PfW CAP	Configurazione CAP dispositivo
Android 15	4	Android 14 o versioni precedenti	HIDL	`vendor`	Versione HIDL
Android 16	3	Android 14 o versioni precedenti	HIDL	`vendor`	Versione HIDL
Android 16	4	Android 15	AIDL	`vendor`	Versione HIDL
Android 16	2	Android 16	AIDL	`system`	Versione AIDL convertita da HIDL
Android 16	1	Android 16	AIDL	`system`	Versione AIDL dell'esempio