W przypadku dźwięku na Androidzie audio_devices_t służy do reprezentowania typu urządzenia audio. Jest on powszechnie używany w kodzie źródłowym audio jako pole bitowe do filtrowania lub wybierania co najmniej jednego określonego urządzenia. Przed Androidem 11 istniało ograniczenie do 30 typów urządzeń wejścia/wyjścia audio i nie było wolnych miejsc na dodanie nowych typów urządzeń audio. Usunęliśmy limit liczby typów urządzeń audio, aby umożliwić dodawanie nowych typów urządzeń audio.
Aby usunąć limit liczby typów urządzeń audio, typy urządzeń audio są teraz wartościami wyliczeniowymi zamiast masek bitowych.
Wszystkie dotychczasowe typy urządzeń audio pozostają bez zmian. AUDIO_DEVICE_BIT_IN nadal służy do rozróżniania urządzeń wejściowych i wyjściowych. Podczas dodawania nowych typów urządzeń audio są one wartościami wyliczeniowymi w lukach między istniejącymi wartościami.
Producenci OEM nie powinni używać wartości audio_devices_t jako maski bitowej, ponieważ może to powodować nieoczekiwane wyniki po dodaniu nowych typów urządzeń audio.
Przykłady i źródło
Przed Androidem 11 istniały 2 typy użycia typów urządzeń audio jako masek bitowych.
- 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.
Do reprezentowania wielu typów urządzeń audio służy klasa o nazwie DeviceTypeSet w
/libaudiofoundation/include/media/AudioContainers.h, która jest kontenerem std::set typu audio_devices_t. Klasa jest zadeklarowana w bibliotece udostępnianej przez dostawcę
libaudiofoundation. Aby w kodzie C reprezentować wiele typów urządzeń audio, można użyć tablicy lub listy audio_devices_t.
Aby sprawdzić, czy pojedynczy 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ąć reprezentację pola bitowego typu urządzenia audio z implementacji HAL audio.
- Usuń wszystkie miejsca na urządzenia w polu bitowym.
audio_devices_tnie należy używać 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ń.
W wersjach Androida starszych niż 11 typy urządzeń audio mogą być używane jako pole bitowe. W takim przypadku często używa się operacji bitowych do porównywania typów urządzeń. Gdy dodawane są nowe, wyliczone typy urządzeń audio, operacje bitowe mogą powodować nieoczekiwane wyniki. Zamiast tego używaj funkcji pomocniczych. Jeśli jest tylko jeden typ urządzenia audio, porównaj bezpośrednio obie wartości. 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). - Przestań używać wstępnie zdefiniowanych wartości dla grup typów urządzeń audio.
Istnieją wstępnie zdefiniowane wartości dla grup typów urządzeń audio,
AUDIO_DEVICE_OUT_ALL, wsystem/media/audio/include/system/audio-base-utils.h. Wszystkie te wartości są zarezerwowane, ale mogą zostać wycofane, ponieważ nie będą prawidłowe po dodaniu nowych typów urządzeń audio. Waudio-base-utils.hzdefiniowano 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_parameterszaimplementuj metodycreate_audio_patch()irelease_audio_patch()do wyznaczania trasy.Metoda
set_parametersużywa typów urządzeń audio jako pola bitowego, więc jeśli zostaną dodane nowe wyliczone typy urządzeń audio, mogą wystąpić nieoczekiwane wyniki.Obecnie wymagane są 2 rodzaje ścieżek audio:
- Miksowanie do ścieżek urządzenia w celu odtwarzania
- Urządzenie do miksowania ścieżek na potrzeby nagrywania
W kolejnych aktualizacjach mogą być wymagane dodatkowe poprawki dla poszczególnych urządzeń.
Podczas tworzenia poprawki audio, jeśli uchwyt poprawki nie zostanie określony, HAL audio musi wygenerować unikalny uchwyt poprawki, który może identyfikować poprawkę audio. W przeciwnym razie HAL audio powinien użyć podanego uchwytu poprawki audio, aby zaktualizować poprawkę audio.
Jeśli używasz starszej wersji HAL audio i otoczki HIDL AOSP, starsza wersja HAL audio powinna ustawić główną wersję HAL na 3.0.
Aby włączyć funkcję poprawki audio, warstwa HAL audio powinna ustawić główną wersję HAL na 3.0 lub wyższą. Więcej informacji znajdziesz w
Device::supportsAudioPatches()w domyślnej implementacji HIDL, która jest też dostępna w przypadku interfejsu HAL audio na urządzeniu Cuttlefish.
Dostosowywanie
Nie można wyłączyć tej funkcji ani cofnąć refaktoryzacji urządzenia audio w ramach, która umożliwia dodawanie typów urządzeń audio.
Wszystkie dodane typy urządzeń audio umożliwiają reprezentowanie typu urządzenia za pomocą jednego ustawionego bitu, dzięki czemu obecne implementacje HAL nadal działają.
Jeśli zostaną dodane nowe typy urządzeń audio, a producenci OEM będą chcieli ich używać, będą musieli uaktualnić implementację HAL audio i przejść na HIDL w wersji 6.0 lub nowszej. Wymagane jest uaktualnienie głównej wersji HAL do 3.0 i wdrożenie metod create_audio_patch i release_audio_patch, ponieważ używanie metody set_parameters do kierowania strumieniem może powodować nieoczekiwane wyniki po dodaniu nowych typów urządzeń audio.
Weryfikacja
Producenci OEM muszą zaktualizować swoje implementacje HAL. VTS dla HAL audio można używać do sprawdzania, czy implementacja działa zgodnie z oczekiwaniami. Wszystkie testy znajdziesz w plikach VTS.