HAL audio HIDL

In Android 13 e versioni precedenti, l'interfaccia Audio HAL è definita utilizzando HIDL nei file HIDL HAL (con estensione .hal ) e schemi XSD per i file di configurazione, mostrati di seguito.

Figura 1. Interfaccia HAL audio.

Nota: per ulteriori dettagli, fare riferimento alla definizione dell'interfaccia Audio HAL e ai commenti nei file *.hal della directory della versione HAL corrispondente. Consultare il file README Audio HAL per la struttura della directory Audio HAL per HIDL.

File di configurazione

I file XML di configurazione dei criteri audio e degli effetti audio sono considerati parte dell'interfaccia Audio HIDL HAL. Questi file devono essere conformi ai rispettivi schemi e la conformità viene verificata mediante test VTS.

Nell'ambito dell'implementazione dell'HAL HIDL audio, è necessario creare un file di configurazione dei criteri audio che descriva la topologia audio. Le funzionalità HAL audio devono essere dichiarate nel file audio_policy_configuration.xml affinché il framework possa utilizzarle.

API HAL HIDL audio

Questa sezione descrive le API HAL core, effetti e comuni per HIDL.

Nota: per Android 13, tutti i percorsi del codice contenenti 7.0 vengono sostituiti con 7.1 . In Android 12, tutti i percorsi di codice contenenti 6.0 sono stati sostituiti con 7.0 .

HAL principale

Alcune delle interfacce chiave di Core HAL, utilizzando HIDL, sono le seguenti:

• IDeviceFactory.hal è il punto di ingresso nell'API.
• IDevice.hal e IPrimaryDevice.hal contengono metodi come setMasterVolume o openInputStream .
• I flussi sono unidirezionali e vengono utilizzati da AudioFlinger per inviare o ricevere audio da e verso l'HAL tramite IStream.hal , IStreamOut.hal e IStreamIn.hal .

La seguente tabella elenca la posizione dei componenti Core HAL HIDL utili:

Componente principale dell'HAL	Posizione
Ultima versione dell'API	/hardware/interfaces/audio/6.0
Tipi specifici dell'ultima API Core HAL	/hardware/interfaces/audio/6.0/types.hal
Schema XSD del file di configurazione dei criteri audio	/hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

L'implementazione predefinita dell'API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) è un wrapper attorno all'implementazione HAL pre-Treble utilizzando librerie condivise legacy . L'implementazione predefinita può anche essere considerata come riferimento quando si implementano nuove versioni di HAL audio che interagiscono direttamente con i driver del kernel.

Effetti HAL

La tabella seguente elenca la posizione dei componenti HAL degli effetti utili che utilizzano HIDL:

Effetti del componente HAL	Posizione
Ultima versione dell'API	/hardware/interfaces/audio/effect/6.0/
Schema XSD del file di configurazione degli effetti	/hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Per ulteriori informazioni, vedere un esempio di implementazione dell'API HAL degli effetti in /hardware/interfaces/audio/effect/all-versions/default/ e la sezione Effetti audio .

HAL comune

L'API HAL comune che utilizza HIDL contiene quanto segue:

• Definizioni ( /hardware/interfaces/audio/common/6.0/types.hal ) condivise dalle API Core ed Effect.
• Utilità ( /hardware/interfaces/audio/common/all-versions ) utilizzate per facilitare la codifica rispetto alle API HIDL per implementazioni, client e test.

Aggiornamenti all'HAL audio V7

Sono presenti modifiche significative alla versione 7 dell'HAL audio in Android 12, come descritto in questa sezione. L'Audio HAL V7 esegue le seguenti operazioni:

• Unifica i modelli di dati utilizzati dal framework e dall'HAL.
• Riduce al minimo la duplicazione tra i tipi di dati HIDL (enumerazioni) e lo schema XML utilizzato per la configurazione dei criteri audio.

Nello specifico, vengono apportate modifiche nelle seguenti aree in Audio HAL V7:

• Tipi di enumerazione
• Tipi di dati
• Tag del venditore
• Spaziatura dei nomi delle estensioni del fornitore

Queste modifiche sono discusse più dettagliatamente nelle rispettive sezioni.

Enumerazioni

A partire da Audio HAL V7, i tipi enumerati utilizzati nel file di configurazione dei criteri audio sono definiti solo nello schema XSD e non nell'HIDL.

In Audio HAL V6, i valori dei tipi enum (come AudioFormat ) in types.hal sono definiti anche nello schema XSD del file di configurazione della policy audio, creando una duplicazione. Per evitare ciò nella V7, i tipi di enumerazione vengono modificati in string e tutti i possibili valori di enumerazione vengono invece elencati nello schema XSD.

La Figura 2 confronta alcune delle modifiche al tipo di enumerazione AudioFormat nella V7:

Figura 2. Confronto di alcune modifiche all'enumerazione AudioFormat.

Fare riferimento al seguente elenco per i tipi enum che sono stati convertiti in string :

• AudioChannelMask
• AudioContentType
• AudioDevice : fornitore estensibile
• AudioFormat : fornitore estensibile
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Passa i valori di enumerazione delle stringhe

I valori stringa vengono utilizzati per trasferire informazioni come valori di enumerazione oltre i limiti dell'interfaccia HAL. Sia il framework che il wrapper HAL utilizzano valori enumerativi interi per implementare la logica aziendale e impiegano l'approccio di conversione illustrato nella Figura 3 :

Figura 3. Passaggio dei valori di enumerazione delle stringhe.

Nota: potrebbe sembrare insolito o inefficiente che la nostra API utilizzi le stringhe qui. Abbiamo scelto di utilizzare le stringhe per eliminare la duplicazione delle costanti di enumerazione tra i file HIDL e XSD e per semplificare l'aggiunta delle estensioni del fornitore. La rappresentazione delle enumerazioni come stringhe è consigliata solo allo scopo di trasportarle sull'interfaccia HAL. Non è consigliabile utilizzare le enumerazioni rappresentate come stringhe nella logica aziendale a causa del sovraccarico associato nell'implementazione delle operazioni logiche booleane e delle risultanti mappature di confronto.

Ad esempio, per passare un valore di tipo formato audio dal framework al fornitore:

1. Il valore enum di AudioFormat viene convertito in un valore stringa in libaudiohal e viene passato all'HAL.
2. Sul lato HAL, il wrapper predefinito converte la stringa in un valore enum, che viene passato all'HAL legacy.

Nota: i fornitori possono modificare system/audio.h per utilizzare i propri valori enum.

Modifiche allo schema XML

Avere elenchi completi di valori enum nella definizione dello schema XML (XSD) consente una migliore convalida del file XML di configurazione della policy audio da parte di VTS. Abbiamo apportato modifiche al file di configurazione della policy audio utilizzato con HAL V7 per conformarsi a XSD.

Nella V7, viene utilizzato un carattere standard ␣ (spazio) per delimitare gli elenchi di valori negli attributi (come frequenze di campionamento, maschere di canale e flag), invece di , (virgola) e | (barra verticale) simboli utilizzati nella versione V6 e precedenti. Come visto nell'esempio seguente, viene utilizzato uno spazio per delimitare l'elenco di valori per channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Per apportare modifiche ai simboli, utilizzare uno script di conversione automatica chiamato update_audio_policy_config.sh . Consulta il comando seguente per convertire un file di configurazione dei criteri audio V6 in una versione V7 per il dispositivo Pixel 5 (Redfin):

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Tipi di dati

Abbiamo ridefinito alcune strutture dati nella V7 per ridurre al minimo le definizioni duplicate. Tuple ripetute di elementi di dati sono raggruppate insieme in strutture riutilizzabili. Queste strutture dati utilizzano le funzionalità HIDL più recenti come le unioni sicure.

Ad esempio, nella V6 e nelle versioni precedenti, viene spesso utilizzato un triplo di <format, sampling rate, channel mask> nelle interfacce e nei tipi HIDL. Per rimuovere questa ridondanza, nella V7, il tipo di dati AudioConfigBase e altri tipi di dati sono definiti come segue:

• AudioConfigBase := <format, sampling rate, channel mask>

• AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

  utilizzato da AudioConfig , AudioOffloadInfo , AudioPortConfig

• AudioProfile := <format, {sampling rates}, {channel masks}>

  sostituisce le raccolte sciolte in AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  sostituisce i sindacati in AudioPort/PortConfig

Tag del venditore

Oltre ai tipi e ai formati di dispositivo, i fornitori possono aggiungere tag personalizzati per i metadati delle tracce audio.

Per la riproduzione e la registrazione dei metadati delle tracce, i fornitori possono passare i propri tag, che vengono utilizzati per aggiungere attributi ai flussi I/O audio, dalle app all'HAL.

Nota: i tag del fornitore sono simili alle estensioni del fornitore per i formati audio e i tipi di dispositivi audio. La differenza è che per i tag del fornitore non ci sono valori definiti in AOSP, quindi contengono solo valori estesi dal fornitore.

I tag del fornitore per i metadati della traccia di riproduzione vengono aggiunti come mostrato nell'esempio seguente:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

La struttura RecordTrackMetadata viene implementata in modo simile aggiungendo tag specifici per i metadati della traccia di registrazione.

Spaziatura dei nomi delle estensioni del fornitore

A partire da HAL V7, le estensioni del fornitore richiedono un prefisso {vendor} aggiuntivo che non è richiesto nella V6. Affinché il prefisso {vendor} sia valido, deve contenere tre o più caratteri alfanumerici.

Utilizzare il seguente formato in V7:

VX_{ vendor }_{ letters/numbers }

Di seguito sono riportati alcuni esempi di estensioni del fornitore V7 valide:

• VX_ GOOGLE _VR
• VX_ QCI _AMBIENT_MIC

Informazioni sulla versione

La tabella seguente elenca il numero di versione HAL per ciascuna versione di Android:

Versione Android	Versione HIDL HAL
Androide 13	7.1
Androide 12	7.0
Androide 11	6.0
Androide 10	5.0
Androide 9	4.0
Androide 8	2.0