Supporto dei criteri audio configurabili nell'HAL AIDL

A partire da Android 16, l'interfaccia AIDL Audio HAL supporta completamente Configurable Audio Policy (CAP).

Questa pagina fornisce le informazioni tecniche di base necessarie per aiutare i partner e i fornitori di SoC nella migrazione delle configurazioni delle policy audio.

Il framework dei parametri

L'implementazione del CAP si basa sull'Intel Parameter Framework. Il CAP è stato introdotto in Android 6. Il framework dei parametri (PfW) consente di descrivere un sistema in termini di parametri. Utilizzando un file XML di configurazione, PfW associa i parametri alle azioni utilizzando i plug-in e fornisce regole per modificare i parametri in base ai criteri correnti.

Struttura di CAP in HIDL

In HIDL, tutta la configurazione per CAP è stata specificata in XML. Per saperne di più, consulta Framework dei parametri e Configurazione tramite il framework dei parametri. I file XML sono stati utilizzati per specificare quanto segue:

  • Descrizione della struttura dei parametri (ovvero la descrizione del dominio audio per PfW)
  • Definizioni dei criteri
  • Regole per le strategie di routing (selezione del dispositivo 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 uno schema XSD corrispondente. Le release principali non richiedevano la compatibilità con le versioni precedenti.

Struttura di CAP in AIDL

Con la transizione ad AIDL, le release dell'API HAL devono rimanere compatibili con le versioni precedenti (in termini HIDL, ogni release dell'HAL AIDL è un aggiornamento "secondario"). 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. Pertanto, la configurazione precedentemente definita nei file XML ora deve essere fornita dall'HAL utilizzando le API AIDL. Per facilitare questa operazione, la struttura della configurazione CAP viene convertita in AIDL, in modo simile ai file XML di configurazione delle norme audio in AIDL Audio HAL per Android 15.

Le strutture di dati per CAP vengono aggiunte ai tipi di dati stabili comuni e includono i seguenti parcelable:

Il punto di ingresso per la configurazione CAP si trova nella struttura AudioHalEngineConfig.CapSpecificConfig. Consulta i commenti in AudioHalCapConfiguration.aidl per un diagramma delle strutture dei dati CAP.

L'implementazione predefinita dell'HAL AIDL contiene una classe helper 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 CAP in precedenza o della migrazione di un prodotto esistente.

Nuovo prodotto

Per un nuovo prodotto che inizia a utilizzare CAP per l'implementazione delle norme audio, l'OEM può scegliere di utilizzare XML per archiviare la configurazione CAP sul 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 archiviare la configurazione CAP nella partizione del fornitore, è consigliabile utilizzare l'implementazione predefinita dell'analizzatore XML per convertire la configurazione in AIDL.

Aggiornamento per un prodotto esistente

Se il prodotto utilizza già CAP e quindi dispone della configurazione XML, puoi continuare a utilizzare 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 integrate ("legacy") utilizzavano nomi brevi in minuscolo come media, mentre in AIDL le strategie integrate utilizzano nomi in maiuscolo con il prefisso STRATEGY_, ad esempio STRATEGY_MEDIA. Consulta l'elenco delle strategie integrate in CapProductStrategies.xml. Lo stesso file definisce gli ID "preassegnati" per le strategie specifiche per gli 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 variante "automotive" del dispositivo virtuale Cuttlefish che utilizza CAP con AIDL HAL. 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.