Configurare i criteri audio

La release di Android 10 include un refactoring significativo del gestore delle norme audio per offrire maggiore flessibilità a supporto di casi d'uso complessi per il settore automobilistico:

  • Strategie di routing specifiche per gli OEM.
  • Gruppi di volumi personalizzabili per gruppi di tipi di stream legacy che utilizzano le stesse curve di volume.
  • Strategie di routing dichiarate dal motore di criteri audio anziché essere codificate.
  • Curve e gruppi di volume gestiti dal motore di policy audio.
  • Refactoring interno in preparazione di una futura suddivisione tra codice comune e codice configurabile e per offrire una gestione più completa dei dispositivi audio. Ad esempio, l'utilizzo di tutte le proprietà del dispositivo, non solo il tipo, nelle regole dei criteri.

Android 7.0 ha introdotto un formato di file di configurazione delle policy audio (XML) per descrivere la topologia audio.

Le versioni precedenti di Android richiedevano l'utilizzo di device/<company>/<device>/audio/audio_policy.conf per dichiarare i dispositivi audio presenti nel tuo prodotto (puoi vedere un esempio di questo file per l'hardware audio di Galaxy Nexus in device/samsung/tuna/audio/audio_policy.conf). Tuttavia, CONF è un formato proprietario semplice troppo limitato per descrivere topologie complesse per verticali come televisori e automobili.

Android 7.0 ha ritirato audio_policy.conf e ha aggiunto il supporto per la definizione di una topologia audio utilizzando un formato di file XML più leggibile, con un'ampia gamma di strumenti di modifica e analisi e sufficientemente flessibile per descrivere topologie audio complesse. Android 7.0 utilizza il flag di build USE_XML_AUDIO_POLICY_CONF per scegliere il formato XML dei file di configurazione.

Vantaggi del formato XML

Come nel file CONF, il file XML consente di definire il numero e i tipi di profili di stream di output e input, i dispositivi utilizzabili per la riproduzione e l'acquisizione e gli attributi audio. Inoltre, il formato XML offre i seguenti miglioramenti:

  • In Android 10, sono consentite più app di registrazione attive contemporaneamente.
    • L'avvio della registrazione non viene mai rifiutato a causa di una situazione di concorrenza.
    • Il callback registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) notifica ai client le modifiche al percorso di acquisizione.
  • Nelle seguenti situazioni, un client riceve campioni audio silenziosi:
    • È attivo un caso d'uso sensibile alla privacy (ad esempio, VOICE_COMMUNICATION).
    • Il client non dispone di un servizio in primo piano o di un'interfaccia utente in primo piano.
    • I ruoli speciali sono riconosciuti dai criteri:
      • Servizio di accessibilità: può registrare anche se è attivo un caso d'uso sensibile alla privacy.
      • Assistente: considerato sensibile alla privacy se la UI è in primo piano.
  • I profili audio hanno una struttura simile ai descrittori audio semplici HDMI, consentendo un diverso set di frequenze di campionamento/maschere dei canali per ogni formato audio.
  • Esistono definizioni esplicite per tutte le possibili connessioni tra dispositivi e stream. In precedenza, una regola implicita consentiva di connettere tutti i dispositivi collegati allo stesso modulo HAL, impedendo alla policy audio di controllare le connessioni richieste con le API patch audio. Nel formato XML, la descrizione della topologia definisce i limiti di connessione.
  • Il supporto per include evita di ripetere le definizioni standard di A2DP, USB o invio di reindirizzamento.
  • Le curve del volume sono personalizzabili. In precedenza, le tabelle del volume erano codificate. Nel formato XML, le tabelle dei volumi sono descritte e possono essere personalizzate.

Il modello all'indirizzo frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml mostra molte di queste funzionalità in uso.

Formato e posizione del file

Il nuovo file di configurazione delle norme audio è audio_policy_configuration.xml e si trova in /system/etc. Gli esempi seguenti mostrano una semplice configurazione delle norme audio nel formato file XML per Android 12 e per le versioni precedenti di Android 12.

La struttura di primo livello contiene moduli che corrispondono a ogni modulo hardware HAL audio, dove ogni modulo ha un elenco di porte di mixaggio, porte del dispositivo e routing:

  • Mix ports descrive i possibili profili di configurazione per gli stream che possono essere aperti nell'HAL audio per la riproduzione e l'acquisizione.
  • Le porte del dispositivo descrivono i dispositivi che possono essere collegati con il relativo tipo (e, facoltativamente, indirizzo e proprietà audio, se pertinenti).
  • Routes è separato dal descrittore della porta di mixaggio, consentendo la descrizione dei percorsi da dispositivo a dispositivo o da stream a dispositivo.

Le tabelle del volume sono semplici elenchi di punti che definiscono la curva utilizzata per la conversione da un indice dell'interfaccia utente a un volume in dB. Un file di inclusione separato fornisce curve predefinite, ma ogni curva per un determinato caso d'uso e categoria di dispositivo può essere sovrascritta.

Inclusioni di file

Il metodo XML Inclusions (XInclude) può essere utilizzato per includere informazioni di configurazione delle policy audio contenute in altri file XML. Tutti i file inclusi devono seguire la struttura descritta sopra con le seguenti limitazioni:

  • I file possono contenere solo elementi di primo livello.
  • I file non possono contenere elementi XInclude.

Utilizza include per evitare di copiare le informazioni di configurazione del modulo HAL audio standard di Android Open Source Project (AOSP) in tutti i file di configurazione delle norme audio (che è soggetto a errori). Viene fornito un file XML di configurazione della policy audio standard per i seguenti HAL audio:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Reroute submix: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Organizzazione del codice delle norme audio

AudioPolicyManager.cpp è suddiviso in diversi moduli per semplificare la manutenzione e la configurazione. L'organizzazione di frameworks/av/services/audiopolicy include i seguenti moduli.

Modulo Descrizione
/managerdefault Include le interfacce generiche e l'implementazione del comportamento comuni a tutte le app. Simile a AudioPolicyManager.cpp con funzionalità del motore e concetti comuni astratti.
/common Definisce le classi di base (ad esempio, strutture di dati per profili di stream audio di input/output, descrittori di dispositivi audio, patch audio e porte audio). In precedenza, questo valore era definito all'interno di AudioPolicyManager.cpp.
/engine

Implementa le regole che definiscono quali dispositivi e volumi devono essere utilizzati per un determinato caso d'uso. Implementa un'interfaccia standard con la parte generica, ad esempio per ottenere il dispositivo appropriato per un determinato caso d'uso di riproduzione o acquisizione oppure per impostare dispositivi connessi o uno stato esterno (ovvero uno stato di chiamata di utilizzo forzato) che può alterare la decisione di routing.

Disponibile in due versioni: configurabile e predefinita. Per informazioni su come selezionare la versione, consulta Configurazione tramite il framework dei parametri.
/engineconfigurable Implementazione del motore delle policy che si basa sul framework dei parametri (vedi sotto). La configurazione si basa sul framework dei parametri e sul punto in cui la policy è definita dai file XML.
/enginedefault Implementazione del motore delle policy basata sulle implementazioni precedenti di Android Audio Policy Manager. Questa è l'impostazione predefinita e include regole hardcoded che corrispondono alle implementazioni Nexus e AOSP.
/service Include interfacce, threading e implementazione del blocco del binder con l'interfaccia al resto del framework.

Configurazione tramite il framework dei parametri

Il codice dei criteri audio è organizzato in modo da essere facile da comprendere e gestire, supportando al contempo un criterio audio definito interamente da file di configurazione. La progettazione dell'organizzazione e delle norme audio si basa sul framework dei parametri di Intel, un framework basato su plug-in e regole per la gestione dei parametri.

L'utilizzo del criterio audio configurabile consente ai fornitori OEM di:

  • Descrivere la struttura di un sistema e i relativi parametri in XML.
  • Scrivi (in C++) o riutilizza un backend (plug-in) per accedere ai parametri descritti.
  • Definisci (in XML o in un linguaggio specifico del dominio) le condizioni/regole in base alle quali un determinato parametro deve assumere un determinato valore.

AOSP include un esempio di file di configurazione delle norme audio che utilizza il framework dei parametri all'indirizzo Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Per maggiori dettagli, consulta la documentazione di Intel sul framework dei parametri.

In Android 10 o versioni precedenti, la policy audio configurabile viene selezionata utilizzando l'opzione di build USE_CONFIGURABLE_AUDIO_POLICY. In Android 11 o versioni successive, la versione del motore delle norme audio è selezionata nel file audio_policy_configuration.xml. Per selezionare il motore di policy audio configurabile, imposta il valore dell'attributo engine_library dell'elemento globalConfiguration su configurable come nel seguente esempio:

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

API di routing delle norme audio

Android 6.0 ha introdotto un'API di enumerazione e selezione pubblica che si basa sull'infrastruttura di patch/porta audio e consente agli sviluppatori di app di indicare una preferenza per un input o un output specifico del dispositivo per tracce o registrazioni audio connesse.

In Android 7.0, l'API Enumeration and Selection viene verificata dai test CTS ed è estesa per includere il routing per i flussi audio C/C++ nativi (OpenSL ES). Il routing degli stream nativi continua a essere eseguito in Java, con l'aggiunta di un'interfaccia AudioRouting che sostituisce, combina e ritira i metodi di routing espliciti specifici delle classi AudioTrack e AudioRecord.

Per dettagli sull'API Enumeration and Selection, consulta Interfacce di configurazione Android e OpenSLES_AndroidConfiguration.h. Per informazioni dettagliate sul routing audio, consulta AudioRouting.

Assistenza multicanale

Se l'hardware e il driver supportano l'audio multicanale tramite HDMI, puoi inviare il flusso audio direttamente all'hardware audio (in questo modo viene bypassato il mixer AudioFlinger, quindi non viene eseguito il downmix a due canali). L'HAL audio deve esporre se un profilo di stream di output supporta le funzionalità audio multicanale. Se l'HAL espone le proprie funzionalità, il gestore delle norme predefinito consente la riproduzione multicanale tramite HDMI. Per i dettagli sull'implementazione, vedi device/samsung/tuna/audio/audio_hw.c.

Per specificare che il tuo prodotto contiene un output audio multicanale, modifica il file di configurazione delle norme audio per descrivere l'output multicanale per il tuo prodotto. Il seguente esempio tratto da frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml mostra una maschera di canale dinamica, il che significa che Audio Policy Manager esegue query sulle maschere di canale supportate dal sink HDMI dopo la connessione.

Puoi anche specificare una maschera di canale statica, ad esempio AUDIO_CHANNEL_OUT_5POINT1. Il mixer di AudioFlinger esegue il downmix automatico dei contenuti in stereo quando vengono inviati a un dispositivo audio che non supporta l'audio multicanale.

Codec multimediali

Assicurati che i codec audio supportati dall'hardware e dai driver siano dichiarati correttamente per il tuo prodotto. Per i dettagli, vedi Esposizione di codec al framework.