A partire da Android 16, l'interfaccia AIDL Audio HAL supporta completamente le norme audio configurabili (CAP).
Questa pagina fornisce le informazioni tecniche necessarie per aiutare i partner e i fornitori di SoC nella migrazione delle configurazioni dei criteri audio.
Il framework dei parametri
L'implementazione del CAP si basa sul Framework di parametri di Intel. Il CAP è stato introdotto in Android 6. Il framework di parametri (PfW) consente di descrivere un sistema in termini di parametri. Utilizzando un file XML di configurazione, PfW lega i parametri alle azioni utilizzando i plug-in e fornisce regole per modificarli in base ai criteri correnti.
Struttura del CAP in HIDL
In HIDL, tutta la configurazione per il CAP è stata specificata in XML. Per ulteriori informazioni, consulta Parameter Framework e Configurazione utilizzando Parameter Framework. I file XML sono stati utilizzati per specificare quanto segue:
- Descrizione della struttura dei parametri (ovvero la descrizione del dominio audio per il PfW)
- Definizioni per i criteri
- Regole per le strategie di routing (selezione dei dispositivi di input e output)
- Specifica delle tabelle dei volumi
Con HIDL, il framework Android è stato in grado di caricare questi file XML direttamente dalla partizione del fornitore. Ciò è stato consentito perché è stato definito uno schema XSD, come parte dell'API HAL, per questi file XML. Ogni release principale dell'HAL HIDL aveva un corrispondente schema XSD. Le release principali non richiedevano la compatibilità con le versioni precedenti.
Struttura del CAP in AIDL
Con la transizione ad AIDL, le release dell'API HAL devono rimanere compatibili con le versioni precedenti (in termini di HIDL, ogni release dell'HAL AIDL è un aggiornamento "minor"). Gli schemi XSD non possono più essere utilizzati nell'ambito delle API HAL perché non esiste un modo stabilito per definire aggiornamenti compatibili con le versioni precedenti degli schemi. Di conseguenza, la configurazione precedentemente definita nei file XML ora deve essere fornita dall'HAL utilizzando le API AIDL. Per semplificare, la struttura della configurazione CAP viene convertita in AIDL, in modo simile ai file XML di configurazione dei criteri audio nell'HAL audio AIDL per Android 15.
Le strutture di dati per il CAP vengono aggiunte ai tipi di dati stabili comuni e includono i seguenti elementi parcelable:
AudioHalCapConfiguration.aidl
AudioHalCapCriterionV2.aidl
AudioHalCapDomain.aidl
AudioHalCapParameter.aidl
AudioHalCapRule.aidl
Il punto di contatto per la configurazione del CAP si trova nella struttura
AudioHalEngineConfig.CapSpecificConfig
. Consulta i commenti in
AudioHalCapConfiguration.aidl
per un diagramma delle strutture di dati CAP.
L'implementazione predefinita dell'HAL AIDL contiene una classe di supporto che compila i parcelable AIDL in base ai contenuti dei file XML CAP legacy per semplificare la migrazione per i partner.
Scenari di migrazione
I partner possono prendere in considerazione le opzioni elencate in questa sezione, a seconda che si tratti del primo lancio di un prodotto che non utilizzava prima il CAP o della migrazione di un prodotto esistente.
Nuovo prodotto
Per un nuovo prodotto che inizia a utilizzare CAP per l'implementazione dei criteri audio, l'OEM può scegliere di utilizzare XML per memorizzare la configurazione CAP lato fornitore.
Il vantaggio dell'utilizzo di XML è che esiste un insieme di strumenti di scripting che facilitano la generazione della configurazione da una descrizione di alto livello.
Se l'OEM decide di utilizzare XML per memorizzare la configurazione CAP nella partizione del fornitore, è consigliabile utilizzare l'implementazione predefinita del parser XML per convertire la configurazione in AIDL.
Aggiornamento per un prodotto esistente
Se il prodotto utilizza già CAP e quindi ha la configurazione XML, puoi continuare a utilizzare il CAP esistente con la versione AIDL dell'HAL.
La convenzione di denominazione per le strategie di prodotto è diversa nelle versioni HIDL e AIDL della configurazione CAP. In HIDL le strategie predefinite ("legacy")
utilizzavano nomi brevi in minuscolo come media
, mentre in AIDL le strategie predefinite
utilizzano nomi in maiuscolo con prefisso STRATEGY_
, ad esempio STRATEGY_MEDIA
. Consulta
l'elenco delle strategie integrate in
CapProductStrategies.xml
.
Lo stesso file definisce gli ID "preallocati" per le strategie specifiche dell'OEM che
seguono il pattern di denominazione vx_10xx
con numeri da 1000
a 1039
.
Prodotto legacy
Se il prodotto che si basa su CAP non aggiorna la partizione del fornitore e rimane su HIDL, puoi aggiornare la partizione di sistema ad Android 16. Il framework rimane compatibile con la configurazione CAP precedente.
Esempio di implementazione
Per aiutare i partner a implementare CAP per le loro piattaforme, AOSP ha un esempio di versione "automotive" del dispositivo virtuale Cuttlefish che utilizza CAP con HAL AIDL. La configurazione specifica del dispositivo si trova in
device/google/cuttlefish/shared/auto/audio/policy/engine,
con il nome target lunch
di aosp_cf_x86_64_auto
. Il file Android.bp
può essere utilizzato come riferimento per generare l'intero set di file del fornitore CAP.