La release Android 10 include un significativo refactoring dell'audio
Policy Manager per fornire maggiore flessibilità per supportare casi d'uso complessi del 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 preparazione a una futura suddivisione tra codice comune e codice configurabile
e offre una gestione dei dispositivi audio più ricca. Ad esempio, l'uso di tutte le proprietà dei dispositivi non solo
il proprio tipo nelle regole dei criteri.
Android 7.0 ha introdotto un formato file di configurazione dei criteri audio (XML) per
che descrive la topologia audio.
Release di Android precedenti richieste utilizzando
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 del Galaxy Nexus
device/samsung/tuna/audio/audio_policy.conf). Tuttavia, CONF è un
un formato semplice e proprietario troppo limitato per descrivere topologie complesse
verticali come televisori e automobili.
Android 7.0 ha deprecato audio_policy.conf e aggiunto supporto
per la definizione di una topologia audio utilizzando un formato file XML
leggibile da una persona, dispone di una vasta gamma di strumenti di editing e analisi ed è flessibile
in modo da descrivere topologie audio complesse. Android 7.0 utilizza
Flag di build USE_XML_AUDIO_POLICY_CONF per scegliere il file 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 stream di output e di input, dispositivi utilizzabili per la riproduzione e l'acquisizione
attributi audio. Inoltre, il formato XML offre i seguenti miglioramenti:
In Android 10, vengono gestite più app di registrazione
consentiti contemporaneamente.
L'avvio della registrazione non viene mai rifiutato a causa di una situazione di contemporaneità.
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
il callback avvisa i clienti delle modifiche al percorso di acquisizione.
Nelle seguenti situazioni, un cliente 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 una UI 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: i dati sono considerati sensibili alla privacy se l'UI si trova in alto.
I profili audio hanno una struttura simile ai descrittori audio semplici HDMI, consentendo un
insieme di frequenze di campionamento/maschere del 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 HAL
del modulo, impedendo al criterio audio di controllare le connessioni richieste con una patch audio
su quelle di livello inferiore. Nel formato XML, la descrizione della topologia definisce i limiti della connessione.
Il supporto di include evita la ripetizione di invii standard A2DP, USB o di reindirizzamento.
le tue definizioni.
Le curve di volume sono personalizzabili. In precedenza, le tabelle dei volumi erano impostate come hardcoded. Nel file XML
le tabelle del volume 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 file e posizione
Il nuovo file di configurazione dei criteri audio è
audio_policy_configuration.xml e si trova in
/system/etc. I seguenti esempi mostrano una semplice configurazione dei criteri audio nel
Formato file XML per Android 12 e per le versioni seguenti
Android 12.
Mostra un esempio di norme relative all'audio per Android 12
La struttura di primo livello contiene moduli che corrispondono a ciascun HAL audio
modulo hardware, in cui ogni modulo include un elenco di porte combinate, porte dei dispositivi
route:
Le porte mix descrivono i possibili profili di configurazione per i flussi
che può essere aperta nell'HAL audio per la riproduzione e l'acquisizione.
Le porte dei dispositivi descrivono i dispositivi che è possibile collegare
il tipo (e facoltativamente indirizzo e proprietà audio, se pertinenti).
Route è separato dal descrittore di porta combinato,
attivazione della descrizione dei percorsi da un dispositivo all'altro o da stream a dispositivo.
Le tabelle di volume sono semplici elenchi di punti che definiscono la curva utilizzata per tradurre
da un indice di UI a un volume in dB. Un file di inclusione separato fornisce i valori predefiniti
ma ogni curva per un determinato caso d'uso e categoria di dispositivi può essere
sovrascritto.
È possibile utilizzare il metodo XML Inclusions (XInclude) per includere le norme relative all'audio
di configurazione disponibili in altri file XML. Tutti i file inclusi devono
seguono la struttura descritta sopra con le seguenti restrizioni:
I file possono contenere solo elementi di primo livello.
I file non possono contenere elementi XInclude.
Utilizza le funzionalità incluse per evitare di copiare l'Android Open Source Project (AOSP) standard
informazioni sulle configurazioni dei moduli HAL audio a tutte le configurazioni dei criteri audio
(che è soggetto a errori). Un file XML di configurazione dei criteri audio standard
è disponibile per i seguenti HAL audio:
A2DP:a2dp_audio_policy_configuration.xml
Modifica il routing del submix:rsubmix_audio_policy_configuration.xml
USB:usb_audio_policy_configuration.xml
Organizzazione del codice dei criteri audio
AudioPolicyManager.cpp è suddiviso in più moduli
per semplificarne la manutenzione e la configurazione. L'organizzazione di
frameworks/av/services/audiopolicy include i campi
seguenti moduli.
Modulo
Descrizione
/managerdefault
Include le interfacce generiche e l'implementazione del comportamento comune a tutti
app. Simile a AudioPolicyManager.cpp con motore
funzionalità e concetti comuni astratti.
/common
Definisce le classi base (ad esempio, le strutture dei dati per lo stream audio di input e output)
profili, descrittori dei dispositivi audio, patch audio e porte audio). In precedenza
definiti all'interno di AudioPolicyManager.cpp.
/engine
Implementa le regole che definiscono il dispositivo e i volumi da utilizzare
caso d'uso specifico. Implementa un'interfaccia standard con la parte generica, come
trovare il dispositivo appropriato per un determinato caso d'uso di riproduzione o acquisizione, oppure
Impostare i dispositivi connessi o lo stato esterno (ovvero uno stato di chiamata di utilizzo forzato) che
possono alterare la decisione di routing.
Implementazione del motore dei criteri che si basa sul framework dei parametri (vedi di seguito).
La configurazione si basa sul framework dei parametri e su dove viene impostato il criterio
definiti da file XML.
/enginedefault
Implementazione del motore delle norme basata sulla precedente Gestione norme audio di Android
implementazioni. 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 delle norme relative all'audio è organizzato in modo da semplificare la comprensione e
mantenere supportando al contempo un criterio audio definito interamente dalla configurazione
. La progettazione dei criteri audio e dell'organizzazione si basa sul parametro Intel
Framework, basato su plug-in e regole, per la gestione dei parametri.
L'utilizzo dei criteri audio configurabili consente agli OEM dei fornitori di:
Descrivere la struttura di un sistema e i suoi parametri in XML.
Scrivere (in C++) o riutilizzare un backend (plug-in) per accedere alle descrizioni
parametri.
Definire (in XML o in una lingua specifica del dominio) condizioni/regole su cui
un determinato parametro deve avere un determinato valore.
AOSP include un esempio di file di configurazione dei criteri audio che utilizza il parametro
Framework all'indirizzo Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Per
dettagli, consulta la documentazione Intel sul
Framework dei parametri.
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 dei criteri relativi all'audio
motore selezionato nel file audio_policy_configuration.xml.
Per selezionare il motore dei criteri audio configurabile, imposta il valore dell'attributo engine_library
attributo dell'elemento globalConfiguration a configurable
come nell'esempio seguente:
Android 6.0 ha introdotto un'API pubblica Enumeration and Selection basata su
al top dell'infrastruttura di patch audio/porta audio e consente
agli sviluppatori di indicare una preferenza per un input o output di dispositivo specifico
tracce o record audio collegati.
In Android 7.0, l'API Enumeration and Selection viene verificata tramite i test CTS
ed è stato esteso 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
un'interfaccia AudioRouting che sostituisce, combina e ritira
i metodi espliciti di routing specifici per AudioTrack e
AudioRecord corsi.
Se il tuo hardware e driver supportano l'audio multicanale tramite HDMI, puoi
inviare lo stream audio direttamente all'hardware audio (questa operazione bypassa
il mixer AudioFlinger in modo che non venga sottoposto a downmix a due canali.) L'HAL audio
deve indicare se un profilo di stream di output supporta l'audio multicanale
le funzionalità di machine learning. Se l'HAL espone le proprie funzionalità, lo strumento di gestione dei criteri predefinito
consente la riproduzione multicanale tramite HDMI. Per i dettagli di implementazione, consulta
device/samsung/tuna/audio/audio_hw.c.
Per specificare che il prodotto contiene un'uscita audio multicanale, modifica il
di configurazione dei criteri audio per descrivere l'output multicanale
prodotto. Il seguente esempio
frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml
Mostra una maschera del canale dinamica, il che significa che la Gestione norme relative agli audio esegue una query sul canale.
maschere supportate dal sink HDMI dopo la connessione.
Mostra esempio di configurazione del dispositivo HDMI
Puoi anche specificare una maschera statica del canale,
AUDIO_CHANNEL_OUT_5POINT1. Il mixer di AudioFlinger esegue il downmix
automaticamente i contenuti in stereo quando vengono inviati a un dispositivo audio che non
supportare l'audio multicanale.
Codec multimediali
Assicurati che i codec audio supportati da hardware e driver siano corretti
per il tuo prodotto. Per maggiori dettagli, vedi
Esposizione dei codec ai
Framework.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.