Configura i criteri relativi all'audio

La release di Android 10 include un refactoring significativo del gestore delle norme audio per offrire maggiore flessibilità al fine di supportare casi d'uso complessi nel settore auto e motori:

  • Strategie di routing specifiche per OEM.
  • Gruppi di volumi personalizzabili per gruppi di tipi di flussi di dati precedenti utilizzando le stesse curve di volume.
  • Strategie di routing dichiarate dal motore dei criteri audio anziché essere hardcoded.
  • Curve e gruppi di volume gestiti dal motore dei criteri audio.
  • Refactoring interno in preparazione per 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 del tipo, nelle regole dei criteri.

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

Le release Android precedenti richiedevano l'utilizzo di 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 di Galaxy Nexus in device/samsung/tuna/audio/audio_policy.conf). Tuttavia, CONF è un formato proprietario semplice e troppo limitato per descrivere topologie complesse per verticali come televisioni e automobili.

Android 7.0 ha deprecato audio_policy.conf e ha aggiunto il supporto per definire una topologia audio utilizzando un formato file XML più leggibile, dotato di una vasta gamma di strumenti di editing e analisi e sufficientemente flessibile per descrivere topologie audio complesse. Android 7.0 utilizza il USE_XML_AUDIO_POLICY_CONF flag di build per scegliere il formato XML degli 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 di 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 è 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) avvisa i clienti delle 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 ha un servizio in primo piano o un'interfaccia utente in primo piano.
    • I ruoli speciali sono riconosciuti dalle norme:
      • Servizio di accessibilità: è possibile 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 insieme diverso di frequenze di campionamento/maschere di canale per ogni formato audio.
  • Esistono definizioni esplicite di tutte le possibili connessioni tra dispositivi e stream. In precedenza, una regola implicita consentiva di collegare tutti i dispositivi collegati allo stesso modulo HAL, impedendo al criterio audio di controllare le connessioni richieste con le API di patch audio. Nel formato XML, la descrizione della topologia definisce i limiti della connessione.
  • Il supporto per include evita la ripetizione di definizioni di invio standard A2DP, USB o di reindirizzamento.
  • Le curve di volume sono personalizzabili. In precedenza, le tabelle dei volumi erano hardcoded. In 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 dei criteri 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 primo livello contiene moduli corrispondenti a ciascun modulo hardware HAL audio, in cui ogni modulo ha un elenco di porte di mix, porte del dispositivo e percorsi:

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

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

Inclusioni di file

Il metodo XML Inclusions (XInclude) può essere utilizzato per includere informazioni di configurazione dei criteri audio situate 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 le inclusioni per evitare di copiare le informazioni sulle configurazioni del modulo HAL audio di Android Open Source Project (AOSP) in tutti i file di configurazione delle norme audio (che sono soggetti a errori). È fornito un file XML di configurazione dei criteri audio standard per i seguenti HAL audio:

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

Organizzazione dei codici delle norme relative all'audio

AudioPolicyManager.cpp è suddiviso in diversi moduli per semplificarne la gestione 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 e output, descrittori di dispositivi audio, patch audio e porte audio). precedentemente definito all'interno di AudioPolicyManager.cpp.
/engine

Implementa le regole che definiscono il dispositivo e i volumi da utilizzare per un determinato caso d'uso. Implementa un'interfaccia standard con la parte generica, ad esempio per recuperare il dispositivo appropriato per un determinato caso d'uso di riproduzione o acquisizione o per impostare i dispositivi connessi o lo stato esterno (ovvero uno stato di chiamata di utilizzo forzato) che può alterare la decisione di instradamento.

Disponibile in due versioni: configurabile e predefinita. Per informazioni su come selezionare la versione, vedi Configurazione con framework dei parametri.
/engineconfigurable Implementazione del motore dei criteri che si basa sul framework dei parametri (vedi di seguito). La configurazione si basa sul framework di parametri e sul criterio definito dai file XML.
/enginedefault l'implementazione del motore delle norme basata su implementazioni precedenti di Gestione norme audio di Android. Questa è l'impostazione predefinita e include regole hardcoded che corrispondono alle implementazioni Nexus e AOSP.
/service Include interfacce di binder, threading e blocco dell'implementazione con l'interfaccia al resto del framework.

Configurazione mediante framework dei parametri

Il codice dei criteri audio è organizzato in modo da semplificarne la comprensione e la manutenzione e supportare al contempo un criterio audio definito interamente da file di configurazione. La progettazione dei criteri audio e dell'organizzazione 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 agli OEM dei fornitori 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 una lingua specifica del dominio) condizioni/regole in base alle quali un determinato parametro deve assumere un determinato valore.

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

In Android 10 o versioni precedenti, il criterio audio configurabile viene selezionato utilizzando l'opzione di build USE_CONFIGURABLE_AUDIO_POLICY. In Android 11 o versioni successive, la versione del motore di criteri audio è selezionata nel file audio_policy_configuration.xml. Per selezionare il motore di criteri audio configurabile, imposta 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 norme relative all'audio

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

In Android 7.0, l'API Enumeration and Selection viene verificata dai test CTS ed è stata estesa per includere il routing per gli stream audio nativi C/C++ (OpenSL ES). Il routing dei flussi 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 per le classi AudioTrack e AudioRecord.

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

Supporto multicanale

Se l'hardware e il driver supportano l'audio multicanale tramite HDMI, puoi inviare lo stream audio direttamente all'hardware audio (in questo modo il mixer AudioFlinger viene ignorato, in modo che non venga sottoposto a downmix su due canali). L'HAL audio deve indicare se un profilo dello stream di output supporta funzionalità audio multicanale. Se l'HAL espone le sue funzionalità, il gestore dei criteri predefinito consente la riproduzione multicanale tramite HDMI. Per i dettagli sull'implementazione, consulta device/samsung/tuna/audio/audio_hw.c.

Per specificare che il tuo prodotto contiene un'uscita audio multicanale, modifica il file di configurazione delle norme relative all'audio per descrivere l'uscita multicanale del prodotto. L'esempio seguente di frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml mostra una maschera di canale dinamica, il che significa che il gestore delle norme relative all'audio esegue query sulle maschere di canale supportate dal ricevitore HDMI dopo il collegamento.

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

Codec multimediali

Assicurati che i codec audio supportati da hardware e driver siano dichiarati correttamente per il tuo prodotto. Per maggiori dettagli, consulta Esposizione dei codec nel framework.