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 XML zasad dźwięku i efektów dźwiękowych 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 HIDL HAL do obsługi dźwięku musisz utworzyć plik konfiguracji zasad dotyczących dźwięku, który opisuje topologię dźwięku. Aby framework mógł korzystać z możliwości HAL audio, muszą one zostać zadeklarowane w pliku audio_policy_configuration.xml.

API HAL HIDL dla dźwięku

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 zostały zastąpione przez 7.1. W Androidzie 12 wszystkie ścieżki kodu zawierające 6.0 zostały zastąpione przez 7.0.

Core HAL

Oto niektóre z głównych 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 używa starszych bibliotek współdzielonych. Domyślne wdrożenie może też służyć jako punkt odniesienia podczas wdrażania nowych wersji interfejsów Audio HAL, które bezpośrednio współpracują z 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

Interfejs Common HAL API korzystający z HIDL zawiera:

• 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.
• Minimalizuje duplikowanie typów danych HIDL (typów wyliczenia) i schematu XML używanego do konfiguracji zasad dotyczących dźwięku.

W Audio HAL V7 wprowadzono zmiany w tych obszarach:

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

Te zmiany są omawiane bardziej szczegółowo w odpowiednich 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 problemu w wersji 7, typy zbiorów wartości zostały zmienione na string, a wszystkie możliwe wartości zbiorów wartości są zamiast tego 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.

Typy wyliczenia, które zostały przekonwertowane na typ string, znajdziesz na tej liście:

• 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 opakowanie HAL używają wartości typu całkowitego w enumeracji na potrzeby implementacji logiki biznesowej i stosują podejście do konwersji pokazane na rysunku 3:

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

Uwaga: używanie przez nasz interfejs API ciągów znaków może wydawać się 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. Reprezentowanie typów wyliczeniowych jako ciągów znaków jest zalecane tylko na potrzeby przesyłania 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ść enumeracji AudioFormat jest zamieniana na wartość ciągu znaków w libaudiohal 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łna lista wartości w definicji schematu XML (XSD) umożliwia 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 starszych. Jak widać w tym przykładzie, spacja służy do rozdzielania listy wartości w przypadku zmiennej channelMasks:

<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 oraz typach HIDL często używana jest potrójka <format, sampling rate, channel mask>. Aby usunąć tę redundancję, w V7 typ danych AudioConfigBase i inne typy danych są zdefiniowane w ten sposób:

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

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

  używany 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ć tagi niestandardowe do metadanych ścieżki 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 podano numer wersji HAL dla każdej wersji Androida:

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