HIDL Audio HAL

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

Abbildung 1. Audio-HAL-Schnittstelle.

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

Konfigurationsdateien

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

Im Rahmen der Implementierung des Audio-HIDL-HAL müssen Sie eine Audiorichtlinien-Konfigurationsdatei erstellen, die die Audiotopologie beschreibt. 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.

Hinweis: Für Android 13 werden alle Codepfade, die 7.0 enthalten, durch 7.1 ersetzt. In Android 12 wurden alle Codepfade, die 6.0 enthielten, durch 7.0 ersetzt.

Kern-HAL

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

• 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 und von der HAL zu senden oder zu empfangen.

Die folgende Tabelle listet die Position nützlicher Core HAL HIDL-Komponenten auf:

Kern-HAL-Komponente	Standort
Neueste Version der API	/hardware/interfaces/audio/6.0
Spezifische Typen für die neueste Core-HAL-API	/hardware/interfaces/audio/6.0/types.hal
XSD-Schema der Audiorichtlinien-Konfigurationsdatei	/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 unter Verwendung älterer gemeinsam genutzter Bibliotheken . Die Standardimplementierung kann auch als Referenz bei der Implementierung neuer Versionen von Audio-HALs betrachtet werden, die direkt mit Kernel-Treibern interagieren.

Effekte HAL

Die folgende Tabelle listet die Position nützlicher Effects HAL-Komponenten mit HIDL auf:

Effekte HAL-Komponente	Standort
Neueste Version der API	/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 einer Beispielimplementierung der Effects HAL API unter /hardware/interfaces/audio/effect/all-versions/default/ und im Abschnitt „Audioeffekte“ .

Gemeinsames 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 genutzt werden.
• Dienstprogramme ( /hardware/interfaces/audio/common/all-versions ), die zur Codierung anhand von HIDL-APIs für Implementierungen, Clients und Tests verwendet werden.

Updates für Audio HAL V7

Wie in diesem Abschnitt beschrieben, gibt es in Android 12 wesentliche Änderungen an Version 7 des Audio-HAL. Der Audio HAL V7 macht Folgendes:

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

Konkret werden in Audio HAL V7 Änderungen in folgenden Bereichen vorgenommen:

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

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

Aufzählungen

Ab Audio HAL V7 werden in der Audio-Richtlinienkonfigurationsdatei verwendete Aufzählungstypen nur im XSD-Schema und nicht im HIDL definiert.

In Audio HAL V6 werden Werte von Aufzählungstypen (wie AudioFormat ) in types.hal auch im XSD-Schema der Audiorichtlinienkonfigurationsdatei definiert, wodurch eine Duplizierung entsteht. Um dies in V7 zu vermeiden, werden die Aufzählungstypen in string geändert und stattdessen alle möglichen Aufzählungswerte im XSD-Schema aufgelistet.

Abbildung 2 vergleicht einige der Änderungen am AudioFormat Enumerationstyp in V7:

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 : Vom Anbieter erweiterbar
• AudioFormat : Vom Anbieter erweiterbar
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Übergeben Sie String-Enum-Werte

String-Werte werden zur Übertragung von Informationen als Aufzählungswerte über die HAL-Schnittstellengrenze hinweg verwendet. Sowohl das Framework als auch der HAL-Wrapper verwenden ganzzahlige Enum-Werte zur Implementierung der Geschäftslogik und verwenden den in Abbildung 3 dargestellten Konvertierungsansatz:

Abbildung 3. Übergabe von String-Enum-Werten.

Hinweis: Es könnte ungewöhnlich oder ineffizient erscheinen, dass unsere API hier Zeichenfolgen verwendet. Wir haben uns für die Verwendung von Zeichenfolgen entschieden, um die Duplizierung 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 für den Zweck empfohlen, sie über die HAL-Schnittstelle zu transportieren. Aufgrund des damit verbundenen Mehraufwands bei der Implementierung boolescher Logikoperationen und der daraus resultierenden Vergleichszuordnungen wird die Verwendung von als Zeichenfolgen dargestellten Aufzählungen in der Geschäftslogik nicht empfohlen.

So übergeben Sie beispielsweise 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 die Zeichenfolge in einen Enum-Wert, der an die Legacy-HAL übergeben wird.

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

XML-Schemaänderungen

Das Vorhandensein vollständiger Listen von Enum-Werten in der XML-Schemadefinition (XSD) ermöglicht eine bessere XML-Dateivalidierung der Audiorichtlinienkonfiguration durch VTS. Wir haben Änderungen an der mit HAL V7 verwendeten Audiorichtlinien-Konfigurationsdatei vorgenommen, um XSD zu entsprechen.

In V7 wird anstelle von , (Komma) und | ein Standardzeichen ␣ ( , ) verwendet, um Wertelisten in Attributen (wie Abtastraten, Kanalmasken und Flags) zu begrenzen (vertikaler Balken) Symbole, die in V6 und niedriger verwendet werden. Wie im folgenden Beispiel zu sehen ist, wird ein Leerzeichen verwendet, um die Werteliste für channelMasks zu begrenzen:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Um die Symboländerungen vorzunehmen, verwenden Sie ein automatisches Konvertierungsskript namens update_audio_policy_config.sh . Sehen Sie sich den folgenden Befehl an, um eine V6-Audiorichtlinien-Konfigurationsdatei in eine V7-Version für das Pixel 5 (Redfin)-Gerät zu 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 in V7 einige Datenstrukturen neu definiert, um doppelte Definitionen zu minimieren. Wiederholte Tupel von Datenelementen werden zu wiederverwendbaren Strukturen gruppiert. Diese Datenstrukturen nutzen die neuesten HIDL-Funktionen wie sichere Vereinigungen.

Beispielsweise wird in V6 und darunter häufig ein Dreifach aus <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 wie folgt 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}>

  ersetzt lose Sammlungen in AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  ersetzt Unions in AudioPort/PortConfig

Anbieter-Tags

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

Für Wiedergabe- und Aufzeichnungsspur-Metadaten können Anbieter ihre eigenen Tags, die zum Hinzufügen von Attributen zu Audio-I/O-Streams verwendet werden, von den Apps an den HAL übergeben.

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

Anbieter-Tags für Metadaten des Wiedergabetitels werden hinzugefügt, wie im folgenden Beispiel dargestellt:

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

Die RecordTrackMetadata Struktur wird auf ähnliche Weise implementiert, indem Tags hinzugefügt werden, die für die Metadaten der Aufnahmespur spezifisch sind.

Namensraum für Anbietererweiterungen

Ab HAL V7 erfordern Anbietererweiterungen ein zusätzliches {vendor} -Präfix, das in V6 nicht erforderlich ist. Damit das Präfix {vendor} gültig ist, muss es aus drei oder mehr 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

Versionsinformation

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,0
Android 11	6,0
Android 10	5,0
Android 9	4,0
Android 8	2,0