HIDL Audio HAL

In 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

Konfigurationsdateien

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

Im Rahmen der Implementierung des Audio-HIDL-HAL müssen Sie eine Konfigurationsdatei für die Audiopolicy erstellen, in der die Audiotopologie beschrieben wird. Audio-HAL-Funktionen müssen in der Datei audio_policy_configuration.xml 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.

Core HAL

Einige der wichtigsten Schnittstellen der Core HAL, die HIDL verwenden, sind:

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

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

Die Standardimplementierung der Core HAL API (/hardware/interfaces/audio/core/all-versions/default/) ist ein Wrapper um die HAL-Implementierung vor Treble, die gemeinsam genutzte Legacy-Bibliotheken verwendet. Die Standardimplementierung kann auch als Referenz bei der Implementierung neuer Versionen von Audio-HALs dienen, die direkt mit Kerneltreibern interagieren.

HAL für Effekte

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

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

Gemeinsame HAL

Die gemeinsame 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 Programmieren von HIDL-APIs für Implementierungen, Clients und Tests helfen.

Aktualisierungen des Audio-HAL V7

In Android 12 gibt es erhebliche Änderungen an Version 7 des Audio-HAL, die in diesem Abschnitt beschrieben werden. Das Audio-HAL V7 führt folgende Schritte aus:

• Vereinheitlicht die Datenmodelle, die vom Framework und HAL verwendet werden.
• Minimiert die Duplizierung zwischen HIDL-Datentypen (Enums) und dem XML-Schema, das für die Konfiguration der Audio-Richtlinie verwendet wird.

Konkret wurden im Audio HAL V7 Änderungen in den folgenden Bereichen vorgenommen:

• Enumerationstypen
• Datentypen
• Anbieter-Tags
• Namespaces für Anbietererweiterungen

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

Aufzählungen

Ab Audio HAL V7 werden in der Audio Policy Configuration-Datei verwendete aufgezählte Typen nur im XSD-Schema und nicht in HIDL definiert.

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

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

Abbildung 2: Vergleich einiger Änderungen an der AudioFormat-Enumeration.

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

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

String-Enum-Werte übergeben

String-Werte werden verwendet, um Informationen als Enumerationswerte ü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 Konvertierungsansatz:

Abbildung 3: String-Enum-Werte übergeben

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

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

Änderungen am XML-Schema

Vollständige Listen von Enumerationswerten in der XML-Schemadefinition (XSD) ermöglichen eine bessere Validierung von XML-Dateien für die Audiokonfiguration durch VTS. Wir haben Änderungen an der Konfigurationsdatei für die Audio-Richtlinie vorgenommen, die mit HAL V7 verwendet wird, um XSD zu entsprechen.

In V7 wird ein Standardzeichen für das Leerzeichen (␣) verwendet, um Wertelisten in Attributen (z. B. Samplingraten, Channelmasken und Flags) zu trennen. In V6 und niedriger wurden dafür die Symbole , (Komma) und | (senkrechter Strich) verwendet. Wie im folgenden Beispiel zu sehen ist, wird ein Leerzeichen verwendet, um die Liste der Werte für channelMasks zu trennen:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Verwenden Sie für die Symboländerungen ein automatisches Konvertierungsskript namens update_audio_policy_config.sh. Mit dem folgenden Befehl wird eine V6-Konfigurationsdatei für die Audio-Richtlinie in eine V7-Version für das Pixel 5 (Redfin) konvertiert:

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 V7 neu definiert, um doppelte Definitionen zu minimieren. Wiederholte Tupel von Datenelementen werden in wiederverwendbare Strukturen gruppiert. Diese Datenstrukturen verwenden die neuesten HIDL-Funktionen wie sichere Unions.

In V6 und niedriger wird beispielsweise häufig ein Triple 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]>

  Wird von AudioConfig, AudioOffloadInfo und AudioPortConfig verwendet

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

  Er ersetzt lose Sammlungen in AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  ersetzt Unions in AudioPort/PortConfig

Anbieter-Tags

Zusätzlich zu Gerätetypen und ‑formaten können Anbieter benutzerdefinierte Tags für Metadaten von Audiotracks hinzufügen.

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

Anbieter-Tags für Metadaten von 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 für die Metadaten des Aufnahmetracks hinzugefügt werden.

Namespace für Anbietererweiterungen

Ab HAL V7 ist für Anbietererweiterungen ein zusätzliches {vendor}-Präfix erforderlich, das in V6 nicht erforderlich ist. Damit das Präfix {vendor} gültig ist, muss es aus mindestens drei alphanumerischen Zeichen bestehen.

Verwenden Sie in V7 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: