HAL HIDL Audio

W Androidzie 13 i starszych interfejs Audio HAL jest definiowany za pomocą HIDL w plikach HAL HIDL (z rozszerzeniem .hal) i schematów XSD dla plików konfiguracji, jak pokazano poniżej.

Rysunek 1. Interfejs HAL dźwięku.

Uwaga: więcej informacji znajdziesz w definicji interfejsu Audio HAL oraz w komentarzach w plikach *.hal w odpowiednim katalogu wersji HAL. Strukturę katalogu Audio HAL dla HIDL znajdziesz w pliku README Audio HAL.

Pliki konfiguracji

Pliki konfiguracji w formacie XML zasad audio i efektów audio są częścią interfejsu audio HIDL HAL. Pliki te muszą być zgodne ze schematami, a zgodność jest weryfikowana przez testy VTS.

W ramach implementacji interfejsu HAL audio HIDL musisz utworzyć plik konfiguracji zasady audio, który opisuje topologię audio. Aby framework mógł korzystać z możliwości HAL audio, muszą one zostać zadeklarowane w pliku audio_policy_configuration.xml.

Interfejs Audio HIDL HAL API

W tej sekcji opisano interfejsy Core, Effects i Common HAL do obsługi HIDL.

Uwaga: w Androidzie 13 wszystkie ścieżki kodu zawierające 7.0 są zastępowane przez 7.1. W Androidzie 12 wszystkie ścieżki kodu zawierające 6.0 zostały zastąpione przez 7.0.

Podstawowa HAL

Oto niektóre z najważniejszych interfejsów Core HAL, które korzystają z HIDL:

• IDeviceFactory.hal to punkt wejścia do interfejsu API.
• IDevice.hal i IPrimaryDevice.hal zawierają takie metody jak setMasterVolume czy openInputStream.
• Strumienie są jednokierunkowe i służą do wysyłania lub odbierania dźwięku do HAL za pomocą interfejsów IStream.hal, IStreamOut.hal i IStreamIn.hal.

W tabeli poniżej znajdziesz przydatne komponenty Core HAL HIDL:

Komponent podstawowego interfejsu HAL	Lokalizacja
Najnowsza wersja interfejsu API	/hardware/interfaces/audio/6.0
Typy specyficzne dla najnowszej wersji interfejsu Core HAL API	/hardware/interfaces/audio/6.0/types.hal
Schemat XSD pliku konfiguracji zasad dotyczących dźwięku	/hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

Domyślna implementacja interfejsu Core HAL API (/hardware/interfaces/audio/core/all-versions/default/) jest opakowaniem implementacji interfejsu HAL przed wprowadzeniem interfejsu Treble, która korzysta z starszych bibliotek współdzielonych. Implementację domyślną można też traktować jako wskazówkę przy wdrażaniu nowych wersji HAL audio, które bezpośrednio współdziałają ze sterownikami jądra.

Efekty HAL

Tabela poniżej zawiera listę przydatnych komponentów HAL efektów, które korzystają z HIDL:

Komponent HAL efektów	Lokalizacja
Najnowsza wersja interfejsu API	/hardware/interfaces/audio/effect/6.0/
Schemat XSD pliku konfiguracji efektu	/hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Więcej informacji znajdziesz w przykładowej implementacji interfejsu Effects HAL API (/hardware/interfaces/audio/effect/all-versions/default/) oraz w sekcji Efekty dźwiękowe.

Wspólny HAL

Oto elementy interfejsu Common HAL API korzystające z HIDL:

• Definicje (/hardware/interfaces/audio/common/6.0/types.hal), które są wspólne dla interfejsów Core i Effect API.
• Narzędzia (/hardware/interfaces/audio/common/all-versions) ułatwiające kodowanie interfejsów HIDL API na potrzeby implementacji, klientów i testów.

Aktualizacje HAL dźwięku w wersji 7

W wersji 7 interfejsu Audio HAL w Androidzie 12 zaszły istotne zmiany, które opisano w tej sekcji. Interfejs Audio HAL V7:

• Ujednolica modele danych używane przez framework i HAL.
• Pozwala zminimalizować duplikowanie typów danych HIDL (wyliczenia) i schematu XML używanego do konfiguracji zasad audio.

Wprowadzamy zmiany w następujących obszarach w interfejsie Audio HAL 7:

• Typy zbiorów nazw
• Typy danych
• Tagi dostawcy
• Tempo nazw rozszerzeń dostawców

Szczegółowo omawiamy te zmiany w poszczególnych sekcjach.

Wyliczenia

Począwszy od wersji Audio HAL 7 typy zagregowane używane w pliku konfiguracji zasad dotyczących dźwięku są definiowane tylko w schemacie XSD, a nie w HIDL.

W Audio HAL V6 wartości typów enum (np. AudioFormat) w elementach types.hal są również zdefiniowane w schemacie XSD pliku konfiguracji zasad dotyczących dźwięku, co powoduje duplikację. Aby uniknąć tego w wersji 7, typy zbiorów zostały zmienione na string, a wszystkie możliwe wartości zbiorów są wymienione w schemacie XSD.

Na rysunku 2. porównano niektóre zmiany w typie zbioru AudioFormat w wersji 7:

Rysunek 2. Porównanie niektórych zmian w enumeracji AudioFormat.

Na liście poniżej znajdziesz typy wyliczeniowe, które zostały przekonwertowane na format string:

• AudioChannelMask
• AudioContentType
• AudioDevice: rozszerzalny przez dostawcę
• AudioFormat: rozszerzalny przez dostawcę
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Przekazywanie wartości typu wyliczeniowego ciągu znaków

Wartości ciągu znaków są używane do przesyłania informacji jako wartości zbioru na granicy interfejsu HAL. Zarówno platforma, jak i kod HAL wykorzystują wartości wyliczeniowe całkowitych do implementacji logiki biznesowej oraz wykorzystują metodę konwersji przedstawioną na Rys. 3:

Rysunek 3. Przekazywanie wartości typu wyliczeniowego ciągu znaków.

Uwaga: używanie ciągów tekstowych w naszym interfejsie API może się wydawać nietypowe lub nieefektywne. Użyliśmy ciągów znaków, aby wyeliminować duplikowanie stałych elementów enumeracji między plikami HIDL i XSD oraz uprościć dodawanie rozszerzeń dostawcy. Prezentowanie wyliczenia jako ciągów znaków jest zalecane tylko do przenoszenia ich przez interfejs HAL. Nie zalecamy używania w logice biznesowej zbiorów wyliczeniowych reprezentowanych jako ciągi znaków ze względu na związany z tym nakład na implementację operacji logicznych i wynikających z nich porównań.

Aby na przykład przekazać wartość typu formatu audio z ramy do dostawcy:

1. Wartość wyliczenia AudioFormat jest w libaudiohal konwertowana na wartość ciągu znaków i przekazywana do HAL.
2. Po stronie HAL domyślny wrapper konwertuje ciąg znaków na wartość enum, która jest przekazywana do starszej wersji HAL.

Uwaga: dostawcy mogą modyfikować system/audio.h, aby używać własnych wartości wyliczenia.

Zmiany schematu XML

Pełne listy wartości elementów w definicji schematu XML (XSD) umożliwiają lepszą walidację pliku XML konfiguracji zasad dotyczących dźwięku przez VTS. Wprowadziliśmy zmiany w pliku konfiguracji zasad dotyczących dźwięku używanym z HAL V7, aby był zgodny z XSD.

W wersji 7 do oddzielania list wartości w atrybutach (takich jak częstotliwości próbkowania, maski kanałów i flagi) zamiast symboli , (przecinek) i | (poprzeczna kreska) używa się standardowego znaku ␣ (spacja). Takie rozwiązanie jest stosowane w wersji 6 i niższych. Jak widać w poniższym przykładzie, do ograniczenia listy wartości w polu channelMasks służy spacja:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Aby wprowadzić zmiany symboli, użyj skryptu automatycznej konwersji o nazwie update_audio_policy_config.sh. Aby przekonwertować plik konfiguracji zasad dotyczących dźwięku w wersji V6 na plik w wersji V7 na urządzeniu Pixel 5 (Redfin), użyj tego polecenia:

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

Typy danych

W wersji 7 zdefiniowaliśmy ponownie niektóre struktury danych, aby zminimalizować liczbę definicji duplikatów. Powtarzające się tuple elementów danych są grupowane w struktury, które można ponownie wykorzystać. Te struktury danych korzystają z najnowszych funkcji HIDL, takich jak bezpieczne złączenia.

Na przykład w wersji 6 i starszych w interfejsach i typach HIDL często używana jest potrójna wartość <format, sampling rate, channel mask>. Aby usunąć tę nadmiarowość, w wersji 7 AudioConfigBase typ danych i inne typy danych są zdefiniowane w ten sposób:

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

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

  używane przez: AudioConfig, AudioOffloadInfo, AudioPortConfig

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

  zastępuje luźne kolekcje w AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  zastępuje związki w AudioPort/PortConfig

Tagi dostawcy

Oprócz typów i formatów urządzeń dostawcy mogą dodawać niestandardowe tagi metadanych ścieżek audio.

W przypadku metadanych utworów do odtwarzania i nagrywania dostawcy mogą przekazywać własne tagi, które służą do dodawania atrybutów do strumieni wejść/wyjść audio z aplikacji do HAL.

Uwaga: tagi dostawcy są podobne do rozszerzeń dostawcy w przypadku formatów i typów urządzeń audio. Różnica polega na tym, że w przypadku tagów dostawcy nie ma żadnych wartości zdefiniowanych w AOSP, więc zawierają one tylko wartości rozszerzone przez dostawcę.

Tagi dostawcy dla metadanych ścieżki odtwarzania są dodawane w ten sposób:

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

Struktura RecordTrackMetadata jest implementowana w podobny sposób poprzez dodanie tagów specyficznych dla metadanych utworu.

Nazewnictwo rozszerzeń dostawców

Od wersji HAL 7 rozszerzenia dostawcy wymagają dodatkowego prefiksu {vendor}, który nie jest wymagany w wersji 6. Aby prefiks {vendor} był prawidłowy, musi składać się z co najmniej 3 znaków alfanumerycznych.

W wersji 7 użyj tego formatu:

VX_{vendor}_{letters/numbers}

Oto kilka przykładów prawidłowych rozszerzeń dostawcy w wersji 7:

• VX_GOOGLE_VR
• VX_QCI_AMBIENT_MIC

Informacje o wersji

W tabeli poniżej znajdziesz numery wersji HAL poszczególnych wersji Androida:

Wersja Androida	Wersja HAL HIDL
Android 13	7.1
Android 12	7,0
Android 11	6.0
Android 10	5,0
Android 9	4.0
Android 8	2,0