HIDL Audio HAL

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

Abbildung 1 : Audio HAL-Schnittstelle

Konfigurationsdateien

Die XML-Konfigurationsdateien für die Audiopolicies und Audioeffekte sind 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 der Audio HIDL HAL müssen Sie eine Konfigurationsdatei für die Audiopolicies erstellen, in der die Audiotopologie beschrieben wird. Die Audio HAL-Funktionen müssen in der Datei audio_policy_configuration.xml deklariert werden, damit sie vom Framework verwendet werden können.

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 von 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 unidirektional 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 ist der Speicherort 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 ältere freigegebene Bibliotheken verwendet. Die Standardimplementierung kann auch als Referenz dienen, wenn neue Versionen von Audio HALs implementiert werden, die direkt mit Kerneltreibern interagieren.

Effects HAL

In der folgenden Tabelle ist der Speicherort nützlicher Effects HAL-Komponenten mit HIDL aufgeführt:

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

Common 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 bei der Codierung für HIDL APIs für Implementierungen, Clients und Tests helfen.

Updates für Audio HAL V7

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

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

Insbesondere wurden in 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 beschrieben.

Enumerationen

Ab Audio HAL V7 werden Enumerationstypen, die in der Konfigurationsdatei für Audiopolicies verwendet werden, 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 Konfigurationsdatei für Audiopolicies 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.

Abbildung 2 vergleicht einige der Änderungen am Enum-Typ AudioFormat in V7:

Abbildung 2 : Vergleich einiger Änderungen am AudioFormat-Enum

In der folgenden Liste sind die Enum-Typen aufgeführt, die in string konvertiert wurden:

• AudioChannelMask
• AudioContentType
• AudioDevice: vom Anbieter erweiterbar
• 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 Integer-Enum-Werte für die Implementierung der Geschäftslogik und verwenden 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 libaudiohal in einen String-Wert konvertiert und an die HAL übergeben.
2. Auf der HAL-Seite konvertiert der Standard-Wrapper den String in einen Enum-Wert, der an die ältere HAL übergeben wird.

Änderungen am XML-Schema

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

In V7 wird ein Standardzeichen ␣ (Leerzeichen) verwendet, um Wertelisten in Attributen (z. B. Abtastraten, Kanalmasken und Flags) zu trennen, anstelle der Symbole , (Komma) und | (vertikaler Strich), die in V6 und niedriger verwendet werden. 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 ein automatisches Konvertierungsskript namens update_audio_policy_config.sh, um die Symboländerungen vorzunehmen. Mit dem folgenden Befehl können Sie eine V6-Konfigurationsdatei für Audiopolicies in eine V7-Version für das Pixel 5-Gerät (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 V7 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 V6 und niedriger wird beispielsweise häufig ein Tripel aus <format, sampling rate, channel mask> in den HIDL-Schnittstellen und -Typen verwendet. Um diese Redundanz zu vermeiden, werden in V7 der Datentyp AudioConfigBase und andere Datentypen wie folgt definiert:

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

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

  verwendet von AudioConfig, AudioOffloadInfo, AudioPortConfig

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

  ersetzt lose Sammlungen in AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  ersetzt Unions in AudioPort/PortConfig

Anbieter-Tags

Neben Gerätetypen und -formaten können Anbieter benutzerdefinierte Tags für Metadaten von Audiotracks hinzufügen.

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

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 Struktur RecordTrackMetadata wird auf ähnliche Weise implementiert, indem Tags hinzugefügt werden, die spezifisch für die Metadaten von Aufzeichnungstracks sind.

Namespaces für Anbietererweiterungen

Ab HAL V7 benötigen Anbietererweiterungen ein zusätzliches Präfix {vendor}, das in V6 nicht erforderlich ist. Damit das Präfix {vendor} gültig ist, muss es mindestens drei alphanumerische Zeichen enthalten.

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: