W Androidzie audio_devices_t reprezentuje typ urządzenia audio. Jest on szeroko stosowany w kodzie źródłowym audio jako pole bitowe do filtrowania lub wybierania co najmniej jednego określonego urządzenia. Przed Androidem 11 było 30 typów urządzeń wejściowych/wyjściowych audio i brak wolnych slotów na dodawanie nowych typów urządzeń audio. Usunęliśmy limit liczby typów urządzeń audio, aby umożliwić dodawanie nowych typów.
Aby usunąć limit liczby typów urządzeń audio, typy urządzeń audio są teraz wartościami wyliczonymi zamiast masek bitowych.
Wszystkie istniejące typy urządzeń audio są zachowywane w niezmienionej formie. AUDIO_DEVICE_BIT_IN nadal służy do rozróżniania urządzeń wejściowych i wyjściowych. Gdy dodajesz nowe typy urządzeń audio, są one zaszeregowane w przedziałach między istniejącymi wartościami.
Producenci OEM nie powinni używać wartości audio_devices_t jako maski bitowej, ponieważ może to spowodować nieoczekiwane wyniki po dodaniu nowych typów urządzeń audio.
Przykłady i źródło
Przed Androidem 11 typy urządzeń audio były używane jako maski bitowe na 2 sposoby.
- Używanie wartości
audio_devices_tdo reprezentowania wielu urządzeń audio. - Sprawdzanie, czy wartość
audio_devices_tzawiera typy urządzeń audio z określonej kategorii.
Aby reprezentować wiele typów urządzeń audio, w
/libaudiofoundation/include/media/AudioContainers.h używana jest klasa o nazwie DeviceTypeSet, która jest kontenerem std::set dla audio_devices_t. Klasa jest zadeklarowana w bibliotece
libaudiofoundation dostępnej dla dostawcy. Aby w kodzie C reprezentować różne typy urządzeń audio, możesz użyć tablicy lub listy audio_devices_t.
Aby sprawdzić, czy dany typ urządzenia należy do określonej kategorii, użyj funkcji pomocniczych audio_is_.*_device w
/system/media/audio/include/system/audio.h.
W przypadku wielu typów urządzeń audio użyj funkcji pomocniczych w libaudiofoundation. Na przykład użyj areAllOfSameDeviceType (DeviceTypeSet, std::function w
AudioContainers.h, aby sprawdzić, czy wszystkie podane typy urządzeń audio są tego samego typu.
Implementacja
Producenci OEM muszą usunąć z implementacji HAL audio reprezentacje bitowych pól typu urządzenia audio.
- Usuń całą pamięć urządzeń w polu bitowym.
audio_devices_tnie powinien być używany do reprezentowania wielu typów urządzeń audio. Zamiast tego użyj listy lub wektora. - Przestań używać operacji bitowych do porównywania typów urządzeń.
Przed Androidem 11 typy urządzeń audio można było używać jako bitowe pola. W takim przypadku do porównywania typów urządzeń zwykle stosuje się operacje bitowe. Gdy dodawane są nowe, zliczane typy urządzeń audio, operacje bitowe mogą dawać nieoczekiwane wyniki. Zamiast tego użyj funkcji pomocniczych. W przypadku jednego typu urządzenia audio porównaj obie wartości za pomocą bezpośredniego porównania. Aby sprawdzić, czy typ urządzenia audio należy do określonej kategorii, użyj funkcji pomocniczych w
/system/media/audio/include/system/audio.h. Na przykład:audio_is_output_device(audio_devices_t device). - Zaprzestań korzystania z wstępnie zdefiniowanych wartości dla grup typów urządzeń audio.
W
system/media/audio/include/system/audio-base-utils.hsą zdefiniowane wstępnie wartości dla grup typów urządzeń audio (AUDIO_DEVICE_OUT_ALL). Wszystkie te wartości są zarezerwowane, ale mogą zostać wycofane, ponieważ nie będą prawidłowe po dodaniu nowych typów urządzeń audio. W usłudzeaudio-base-utils.hzdefiniowane są nowe grupy typów urządzeń audio, które są tablicami typów urządzeń audio, np.AUDIO_DEVICE_OUT_ALL_ARRAY. - Zamiast metody
set_parametersużyj metodcreate_audio_patch()irelease_audio_patch()do wyznaczania tras.Metoda
set_parametersużywa typów urządzeń audio jako bitowej reprezentacji liczby, więc w przypadku dodania nowych typów urządzeń audio mogą wystąpić nieoczekiwane wyniki.Obecnie wymagane są 2 rodzaje poprawek audio:
- Mix to device patches (na potrzeby odtwarzania)
- Urządzenie do miksowania poprawek do nagrywania
W kolejnych aktualizacjach mogą być wymagane dodatkowe poprawki dotyczące komunikacji między urządzeniami.
Podczas tworzenia poprawki audio, jeśli nie jest określony identyfikator poprawki, interfejs HAL dźwięku musi wygenerować unikalny identyfikator poprawki, który może zidentyfikować poprawkę audio. W przeciwnym razie interfejs HAL audio powinien używać danego uchwytu poprawki audio do aktualizacji poprawki audio.
Jeśli używasz starszej wersji interfejsu HAL dźwięku i opakowania AOSP HIDL, w starszej wersji interfejsu HAL dźwięku należy ustawić główną wersję interfejsu HAL na 3.0.
Aby można było włączyć funkcję poprawki audio, interfejs HAL audio powinien ustawić główną wersję HAL na 3.0 lub wyższą. Więcej informacji znajdziesz w
Device::supportsAudioPatches()w domyślnej implementacji HIDL, którą można też znaleźć w interfejsie API do obsługi dźwięku dla Cuttlefish.
Dostosowywanie
Nie można wyłączyć tej funkcji ani cofnąć refaktoryzacji urządzenia audio w ramach frameworku, który umożliwia dodawanie typów urządzeń audio.
Wszystkie dodane typy urządzeń audio umożliwiają reprezentowanie typu urządzenia za pomocą jednego bitu, dzięki czemu obecne implementacje HAL nadal działają.
Jeśli dodano nowe typy urządzeń audio i producenci OEM chcą z nich korzystać, muszą uaktualnić implementację HAL dźwięku i przełączyć się na HIDL w wersji 6.0 lub nowszej. Konieczne jest uaktualnienie głównej wersji HAL do wersji 3.0 oraz wdrożenie metod create_audio_patch i release_audio_patch, ponieważ kierowanie strumienia za pomocą set_parameters może spowodować nieoczekiwane rezultaty po dodaniu nowych typów urządzeń audio.
Weryfikacja
Dostawcy OEM muszą zaktualizować swoje implementacje HAL. VTS dla interfejsu HAL audio można użyć do sprawdzenia, czy implementacja działa zgodnie z oczekiwaniami. Wszystkie testy znajdziesz w plikach VTS.