Configurare i criteri audio

La versione Android 10 include un significativo refactoring del gestore delle policy audio per fornire maggiore flessibilità e supportare casi d'uso automobilistici complessi:

  • Strategie di routing specifiche dell'OEM.
  • Gruppi di volumi personalizzabili per gruppi di tipi di flusso legacy che utilizzano le stesse curve di volume.
  • Strategie di routing dichiarate dal motore delle policy audio invece di essere codificate.
  • Curve e gruppi di volume gestiti dal motore delle policy audio.
  • Refactoring interno che prepara per una futura suddivisione tra codice comune e codice configurabile e offre una gestione più ricca dei dispositivi audio. Ad esempio, l'utilizzo di tutte le proprietà del dispositivo e non solo del relativo tipo nelle regole dei criteri.

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

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

Android 7.0 ha deprecato audio_policy.conf e ha aggiunto il supporto per la definizione di una topologia audio utilizzando un formato di file XML più leggibile dall'uomo, dotato di un'ampia gamma di strumenti di modifica e analisi ed è sufficientemente flessibile da 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 flusso di output e input, dispositivi utilizzabili per la riproduzione e l'acquisizione e attributi audio. Inoltre, il formato XML offre i seguenti miglioramenti:

  • In Android 10 è consentita più di un'app di registrazione attiva 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 dalla policy:
      • Servizio di accessibilità: può registrare anche se è attivo un caso d'uso sensibile alla privacy.
      • Assistente: considerato sensibile alla privacy se l'interfaccia utente è in alto.
  • I profili audio hanno una struttura simile ai descrittori audio semplici HDMI, consentendo un diverso set di frequenze di campionamento/maschere di canale per ciascun formato audio.
  • Esistono definizioni esplicite per tutte le possibili connessioni tra dispositivi e flussi. 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 di patch audio. Nel formato XML, la descrizione della topologia definisce le limitazioni della connessione.
  • Il supporto per include evita la ripetizione di definizioni di invio A2DP, USB o reindirizzamento standard.
  • Le curve di volume sono personalizzabili. In precedenza, le tabelle dei volumi erano codificate. Nel formato XML, le tabelle dei volumi sono descritte e possono essere personalizzate.

Il modello in 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 della policy audio è audio_policy_configuration.xml e si trova in /system/etc . Gli esempi seguenti mostrano una semplice configurazione dei criteri audio nel formato file XML per Android 12 e per le versioni precedenti ad Android 12.

La struttura di livello superiore contiene moduli che corrispondono a ciascun modulo hardware HAL audio, dove ogni modulo ha un elenco di porte mix, porte dispositivo e percorsi:

  • Le porte mix descrivono i possibili profili di configurazione per i flussi che possono essere aperti nell'HAL audio per la riproduzione e l'acquisizione.
  • Le porte dei dispositivi descrivono i dispositivi che possono essere collegati con il loro tipo (e facoltativamente indirizzo e proprietà audio, se rilevanti).
  • I percorsi sono separati dal descrittore della porta mix, consentendo la descrizione dei percorsi da dispositivo a dispositivo o da flusso a dispositivo.

Le tabelle del volume sono semplici elenchi di punti che definiscono la curva utilizzata per tradurre da un indice UI a un volume in dB. Un file di inclusione separato fornisce curve predefinite, ma è possibile sovrascrivere ciascuna curva per un determinato caso d'uso e categoria di dispositivi.

Inclusioni di file

Il metodo XML Inclusions (XInclude) può essere utilizzato per includere informazioni sulla configurazione dei criteri audio che si trovano in altri file XML. Tutti i file inclusi devono seguire la struttura sopra descritta con le seguenti restrizioni:

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

L'uso include l'evitare di copiare le informazioni sulle configurazioni del modulo HAL audio Android Open Source Project (AOSP) standard in tutti i file di configurazione dei criteri audio (che sono soggetti a errori). Viene fornito un file XML di configurazione dei criteri audio standard per i seguenti HAL audio:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Reindirizzare il submix: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Organizzazione del codice della politica audio

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

Modulo Descrizione
/managerdefault Include le interfacce generiche e l'implementazione del comportamento comune 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 dati per profili di flusso audio di input e output, descrittori di dispositivi audio, patch audio e porte audio). Questo è stato precedentemente definito all'interno di AudioPolicyManager.cpp .
/engine

Implementa le regole che definiscono quale dispositivo 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 dato caso d'uso di riproduzione o acquisizione o per impostare i dispositivi collegati o lo stato esterno (ovvero uno stato di chiamata di utilizzo forzato) che può alterare il routing decisione.

Disponibile in due versioni: configurabile e predefinita . Per informazioni su come selezionare la versione, vedere Configurazione utilizzando il Framework dei parametri .

/engineconfigurable Implementazione del motore delle politiche che si basa sul Parametro Framework (vedi sotto). La configurazione si basa sul Framework dei parametri e la policy è definita da file XML.
/enginedefault Implementazione del motore delle policy basata sulle precedenti implementazioni di Android Audio Policy Manager. Questa è l'impostazione predefinita e include regole codificate che corrispondono alle implementazioni Nexus e AOSP.
/service Include interfacce di associazione, threading e implementazione del blocco con l'interfaccia al resto del framework.

Configurazione utilizzando il framework dei parametri

Il codice della policy audio è organizzato per facilitarne la comprensione e la manutenzione, supportando al tempo stesso una policy audio definita interamente dai file di configurazione. L'organizzazione e la progettazione delle policy audio si basano sul Parametro Framework di Intel, un framework basato su plug-in e regole per la gestione dei parametri.

L'utilizzo della policy audio configurabile consente agli OEM dei fornitori di:

  • Descrivere la struttura di un sistema e i suoi parametri in XML.
  • Scrivi (in C++) o riutilizza un backend (plugin) per accedere ai parametri descritti.
  • Definire (in XML o in un linguaggio specifico del dominio) condizioni/regole in base alle quali un dato parametro deve assumere un dato valore.

AOSP include un esempio di file di configurazione della policy audio che utilizza il Framework dei parametri in Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Per i dettagli, fare riferimento alla documentazione 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 dei criteri audio è selezionata nel file audio_policy_configuration.xml . Per selezionare il motore dei criteri audio configurabile, impostare il valore dell'attributo engine_library dell'elemento globalConfiguration su configurable come nell'esempio seguente:

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

API di routing delle policy audio

Android 6.0 ha introdotto un'API pubblica di enumerazione e selezione che si trova sopra l'infrastruttura di patch/porte audio e consente agli sviluppatori di app di indicare una preferenza per l'output o l'input di un dispositivo specifico per le registrazioni o le tracce audio connesse.

In Android 7.0, l'API di enumerazione e selezione viene verificata mediante test CTS ed è estesa per includere il routing per flussi audio C/C++ nativi (OpenSL ES). L'instradamento dei flussi nativi continua ad essere eseguito in Java, con l'aggiunta di un'interfaccia AudioRouting che sostituisce, combina e depreca i metodi di instradamento espliciti specifici delle classi AudioTrack e AudioRecord .

Per dettagli sull'API di enumerazione e selezione, fare riferimento alle interfacce di configurazione Android e OpenSLES_AndroidConfiguration.h . Per i dettagli sul routing audio, fare riferimento a AudioRouting .

Supporto multicanale

Se l'hardware e il driver supportano l'audio multicanale tramite HDMI, è possibile trasmettere il flusso audio direttamente all'hardware audio (questo bypassa il mixer AudioFlinger in modo che non venga downmixato su due canali). L'HAL audio deve indicare se un profilo di flusso di output supporta funzionalità audio multicanale. Se l'HAL espone le sue capacità, il gestore delle policy predefinito consente la riproduzione multicanale su HDMI. Per i dettagli sull'implementazione, vedere device/samsung/tuna/audio/audio_hw.c .

Per specificare che il tuo prodotto contiene un output audio multicanale, modifica il file di configurazione della policy 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 il gestore dei criteri audio interroga le maschere di canale supportate dal sink HDMI dopo la connessione.

È inoltre possibile specificare una maschera di canale statica come AUDIO_CHANNEL_OUT_5POINT1 . Il mixer di AudioFlinger esegue automaticamente il downmix del contenuto in stereo quando viene inviato 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, vedere Esposizione dei codec al framework .