HIDL Audio HAL

Unter Android 13 und niedriger wird die Audio HAL-Schnittstelle mit HIDL in HIDL HAL-Dateien (mit der Erweiterung .hal) und XSD-Schemas für die Konfigurationsdateien definiert, wie unten dargestellt.

Abbildung 1. Audio HAL-Schnittstelle

Hinweis :Weitere Informationen finden Sie in der Audio HAL-Schnittstellendefinition und in den Kommentaren in den *.hal-Dateien des entsprechenden HAL-Verzeichnisses der Version. Die Audio HAL-Verzeichnisstruktur für HIDL finden Sie in der README-Datei für die Audio HAL.

Konfigurationsdateien

XML-Konfigurationsdateien für Audiorichtlinien und Audioeffekte gelten als Teil der Audio-HIDL-HAL-Schnittstelle. Diese Dateien müssen ihren Schemas entsprechen. Die Einhaltung wird durch VTS-Tests überprüft.

Im Rahmen der Implementierung der Audio-HIDL-HAL müssen Sie eine Konfigurationsdatei für Audiorichtlinien erstellen, die die Audiotopologie beschreibt. Audio-HAL-Funktionen müssen in der audio_policy_configuration.xml-Datei deklariert werden, damit das Framework sie verwenden kann.

Audio HIDL HAL API

In diesem Abschnitt werden die Core-, Effects- und Common HAL APIs für HIDL beschrieben.

Hinweis :Unter Android 13 werden alle Codepfade, die 7.0 enthalten, durch 7.1 ersetzt. In Android 12 wurden alle Codepfade, die 6.0 enthalten, durch 7.0 ersetzt.

Core HAL

Einige der wichtigsten Schnittstellen der Core HAL mit HIDL sind:

• IDeviceFactory.hal ist der Einstiegspunkt in die API.
• IDevice.hal und IPrimaryDevice.hal enthalten Methoden wie setMasterVolume oder openInputStream.
• Streams sind einseitig und werden von AudioFlinger verwendet, um Audio über IStream.hal, IStreamOut.hal und IStreamIn.hal an die HAL zu senden oder von ihr zu empfangen.

In der folgenden Tabelle sind die Speicherorte nützlicher Core HAL HIDL-Komponenten aufgeführt:

HAL-Kernkomponente	Standort
Neueste API-Version	/hardware/interfaces/audio/6.0
Für die neueste Core HAL API spezifische Typen	/hardware/interfaces/audio/6.0/types.hal
XSD-Schema der Konfigurationsdatei für Audiorichtlinien	/hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

Die Standardimplementierung der Core HAL API (/hardware/interfaces/audio/core/all-versions/default/) ist ein Wrapper um die HAL-Implementierung vor Treble, die alte freigegebene Bibliotheken verwendet. Die Standardimplementierung kann auch als Referenz verwendet werden, wenn neue Versionen von Audio-HALs implementiert werden, die direkt mit Kerneltreibern interagieren.

HAL für Effekte

In der folgenden Tabelle sind die Standorte nützlicher HAL-Effekte mit HIDL aufgeführt:

HAL-Komponente für Effekte	Standort
Neueste API-Version	/hardware/interfaces/audio/effect/6.0/
XSD-Schema der Effektkonfigurationsdatei	/hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Weitere Informationen finden Sie in der Beispielimplementierung der Effects HAL API unter /hardware/interfaces/audio/effect/all-versions/default/ und im Abschnitt Audioeffekte.

Gemeinsame HAL

Die Common HAL API mit HIDL enthält Folgendes:

• Definitionen (/hardware/interfaces/audio/common/6.0/types.hal), die von den Core- und Effect-APIs gemeinsam verwendet werden.
• Dienstprogramme (/hardware/interfaces/audio/common/all-versions), die beim Codieren für HIDL-APIs für Implementierungen, Clients und Tests helfen.

Aktualisierungen der Audio HAL V7

In Android 12 gibt es erhebliche Änderungen an Version 7 der Audio HAL, wie in diesem Abschnitt beschrieben. Die Audio HAL V7 bietet folgende Vorteile:

• Die Datenmodelle, die vom Framework und HAL verwendet werden, werden vereinheitlicht.
• Minimiert die Duplizierung zwischen HIDL-Datentypen (Enumerationen) und dem XML-Schema, das für die Konfiguration von Audiorichtlinien verwendet wird.

Insbesondere werden in den folgenden Bereichen von Audio HAL V7 Änderungen vorgenommen:

• Aufzählungstypen
• Datentypen
• Anbieter-Tags
• Namespaces für Anbietererweiterungen

Diese Änderungen werden in den jeweiligen Abschnitten ausführlicher erläutert.

Aufzählungen

Ab Audio HAL V7 werden die in der Audio Policy Configuration-Datei verwendeten Aufzählungstypen nur im XSD-Schema und nicht in HIDL definiert.

In Audio HAL V6 sind Werte von Enum-Typen (z. B. AudioFormat) in types.hal auch im XSD-Schema der Konfigurationsdatei für Audiorichtlinien definiert, was zu einer Duplizierung führt. Um dies in Version 7 zu vermeiden, werden die Enum-Typen in string geändert und stattdessen alle möglichen Enumerationswerte im XSD-Schema aufgeführt.

In Abbildung 2 werden einige der Änderungen am AudioFormat-Enumtyp in Version 7 verglichen:

Abbildung 2. Vergleich einiger Änderungen am AudioFormat-Enum.

In der folgenden Liste finden Sie die Enum-Typen, die in string konvertiert wurden:

• AudioChannelMask
• AudioContentType
• AudioDevice: Vom Anbieter erweiterbar
• AudioFormat: Vom Anbieter erweiterbar
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

String-Enum-Werte übergeben

Stringwerte werden verwendet, um Informationen als Aufzählungswerte über die HAL-Schnittstellengrenze hinweg zu übertragen. Sowohl das Framework als auch der HAL-Wrapper verwenden Ganzzahl-Enum-Werte für die Implementierung der Geschäftslogik und den in Abbildung 3 dargestellten Conversion-Ansatz:

Abbildung 3 Übergeben von enum-Werten vom Typ String

Hinweis :Es mag ungewöhnlich oder ineffizient erscheinen, dass unsere API hier Strings verwendet. Wir haben uns für Strings entschieden, um Duplikate von Aufzählungskonstanten zwischen HIDL- und XSD-Dateien zu vermeiden und das Hinzufügen von Anbietererweiterungen zu vereinfachen. Die Darstellung von Enumerationen als Strings wird nur zum Transport über die HAL-Schnittstelle empfohlen. Es wird nicht empfohlen, in der Geschäftslogik Enumerationen zu verwenden, die als Strings dargestellt werden, da dies zu einem zusätzlichen Aufwand bei der Implementierung boolescher Logikoperationen und der daraus resultierenden Vergleichszuordnungen führt.

So übergeben Sie beispielsweise einen Wert des Audioformattyps vom Framework an den Anbieter:

1. Der enum-Wert von AudioFormat wird in libaudiohal in einen Stringwert konvertiert und an die HAL übergeben.
2. Auf HAL-Seite konvertiert der Standard-Wrapper den String in einen Enum-Wert, der an die bisherige HAL übergeben wird.

Hinweis: Anbieter können system/audio.h ändern, um ihre eigenen Enum-Werte zu verwenden.

XML-Schemaänderungen

Vollständige Listen von Enum-Werten in der XML-Schemadefinition (XSD) ermöglichen eine bessere Validierung von XML-Dateien für die Audiorichtlinienkonfiguration durch VTS. Wir haben Änderungen an der Konfigurationsdatei für die Audiorichtlinie vorgenommen, die mit HAL V7 verwendet wird, um die XSD-Anforderungen zu erfüllen.

In Version 7 wird ein Standardzeichen ␣ (Leerzeichen) verwendet, um Wertelisten in Attributen (z. B. Abtastrate, Kanalmasken und Flags) zu trennen. In Version 6 und niedriger werden die Symbole , (Komma) und | (senkrechter Strich) verwendet. Wie im folgenden Beispiel zu sehen, wird ein Leerzeichen verwendet, um die Liste der Werte für channelMasks abzugrenzen:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Verwenden Sie zum Ändern der Symbole ein automatisches Konvertierungsskript namens update_audio_policy_config.sh. Mit dem folgenden Befehl können Sie eine V6-Konfigurationsdatei für Audiorichtlinien in eine V7-Version für Google Pixel 5 (Redfin) konvertieren:

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

Datentypen

Wir haben einige Datenstrukturen in Version 7 neu definiert, um doppelte Definitionen zu minimieren. Wiederholte Tupel von Datenelementen werden in wiederverwendbaren Strukturen gruppiert. Diese Datenstrukturen verwenden die neuesten HIDL-Funktionen wie sichere Unions.

In Version 6 und niedriger wird beispielsweise häufig ein Dreier von <format, sampling rate, channel mask> in den HIDL-Schnittstellen und ‑Typen verwendet. Um diese Redundanz zu beseitigen, werden in V7 der Datentyp AudioConfigBase und andere Datentypen so definiert:

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

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

  von AudioConfig, AudioOffloadInfo, AudioPortConfig verwendet

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

  ersetzt lose Sammlungen in AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  ersetzt Gewerkschaften in AudioPort/PortConfig

Anbieter-Tags

Zusätzlich zu Gerätetypen und Formaten können Anbieter benutzerdefinierte Tags für Audiotrack-Metadaten hinzufügen.

Für Metadaten von Wiedergabe- und Aufnahmetracks können Anbieter eigene Tags übergeben, mit denen Audio-I/O-Streams Attribute hinzugefügt werden. Diese werden von den Apps an die HAL übergeben.

Hinweis :Die Anbieter-Tags ähneln Anbietererweiterungen für Audioformate und Audiogerätetypen. Der Unterschied besteht darin, dass für Anbieter-Tags keine Werte in AOSP definiert sind. Sie enthalten also nur vom Anbieter erweiterte Werte.

Anbieter-Tags für Metadaten zu Wiedergabetracks werden wie im folgenden Beispiel hinzugefügt:

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

Die RecordTrackMetadata-Struktur wird auf ähnliche Weise implementiert, indem Tags hinzugefügt werden, die speziell für die Metadaten des Aufnahmetracks gelten.

Namensraum für Anbietererweiterungen

Ab HAL V7 benötigen Anbietererweiterungen ein zusätzliches {vendor}-Präfix, das in V6 nicht erforderlich ist. Das {vendor}-Präfix muss aus mindestens drei alphanumerischen Zeichen bestehen, um gültig zu sein.

Verwenden Sie in Version 7 das folgende Format:

VX_{vendor}_{letters/numbers}

Im Folgenden finden Sie einige Beispiele für gültige V7-Anbietererweiterungen:

• VX_GOOGLE_VR
• VX_QCI_AMBIENT_MIC

Versionsinformationen

In der folgenden Tabelle ist die HAL-Versionsnummer für jede Android-Version aufgeführt:

Android-Version	HIDL HAL-Version
Android 13	7.1
Android 12	7
Android 11	6.0
Android 10	5
Android 9	4.0
Android 8	2