W przypadku Androida Audio typ audio_devices_t jest używany do reprezentowania typu urządzenia audio. Jest
powszechnie stosowane w kodzie źródłowym audio jako pole bitowe do filtrowania lub wyboru
określonych urządzeniach. Przed Androidem 11 limit wynosił 30
urządzeń wejściowych/wyjściowych audio i nie ma wolnych gniazd na dodawanie nowych typów urządzeń audio. Poniżej
usunięto limit dozwolonych typów urządzeń audio
nowe typy urządzeń audio, które chcesz dodać.
Aby usunąć limit liczby typów urządzeń audio, wyliczanych wartości, a nie masek bitowych.
Wszystkie dotychczasowe typy urządzeń audio zostaną zachowane. AUDIO_DEVICE_BIT_IN to
są nadal używane do rozróżniania urządzeń wejściowych i wyjściowych. Gdy dodajesz nowe typy urządzeń audio,
określone wartości w lukach między istniejącymi wartościami.
OEM nie powinien używać maski audio_devices_t jako masky, ponieważ może to spowodować,
po dodaniu nowych wymienionych typów urządzeń audio nie powinny wystąpić nieoczekiwane rezultaty.
Przykłady i źródło
Przed Androidem 11 istniały 2 typowe przypadki użycia urządzeń audio jako maski bitowe.
- Używanie wartości
audio_devices_tdo reprezentowania wielu urządzeń audio. - Sprawdzam, czy wartość
audio_devices_tzawiera typy urządzeń audio z określonej kategorii.
Aby reprezentować wiele typów urządzeń audio, klasa o nazwie DeviceTypeSet w parametrze
/libaudiofoundation/include/media/AudioContainers.h
który jest kontenerem std::set zbioru danych audio_devices_t.
klasa jest zadeklarowana w elemencie dostępnym dla dostawcy
libaudiofoundation. Reprezentować
wiele plików audio
typów urządzeń w kodzie C, można użyć tablicy lub listy elementów audio_devices_t.
Aby sprawdzić, czy poszczególne typy urządzeń należą do określonej kategorii, użyj funkcji pomocniczych
audio_is_.*_device w
/system/media/audio/include/system/audio.h.
W przypadku etui różnych typów urządzeń audio użyj funkcji pomocniczych w języku: libaudiofoundation. Dla:
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
OEM musi usunąć reprezentację pola bitowego typu urządzenia audio z implementacji HAL audio.
- Usuń całą pamięć urządzeń w polu bitowym.
Nazwa
audio_devices_tnie powinna być używana do reprezentowania wielu urządzeń audio . Zamiast tego użyj listy lub wektora. - Przestań używać operacji bitowych do porównań typów urządzeń.
Przed Androidem 11 typy urządzeń audio można wykorzystać jako lub „bitfield”. W takich przypadkach w przypadku typów urządzeń często używa się operacji bitowych. i porównaniami. Po dodaniu nowych, wymienionych typów urządzeń audio operacje bitowe mogą powodować, nieoczekiwane rezultaty. Zamiast tego użyj funkcji pomocniczych. Jeśli jest singiel, typu urządzenia audio, a potem porównać obie wartości za pomocą bezpośredniego porównania. Aby sprawdzić, czy dźwięk Typ urządzenia należy do określonej kategorii, użyj funkcji pomocniczych w
/system/media/audio/include/system/audio.hPrzykład:audio_is_output_device(audio_devices_t device) - Przestań używać wstępnie zdefiniowanych wartości w przypadku grup typów urządzeń audio.
Istnieje kilka wstępnie zdefiniowanych wartości dla grup typów urządzeń audio,
AUDIO_DEVICE_OUT_ALL, w:system/media/audio/include/system/audio-base-utils.hWszystkie te wartości są zarezerwowane, ale mogą zostać wycofane, ponieważ nie będą poprawne po wyliczeniu typy urządzeń audio. Zdefiniowano nowe grupy typów urządzeń audio waudio-base-utils.h, czyli tablice typów urządzeń audio, takich jakAUDIO_DEVICE_OUT_ALL_ARRAY - Wdróż
create_audio_patch()irelease_audio_patch()zamiastset_parameters.Metoda
set_parametersużywa typów urządzeń audio jako pola bitowego, więc można po dodaniu nowych wyliczanych typów urządzeń audio pojawią się nieoczekiwane wyniki.Obecnie wymagane są 2 rodzaje poprawek audio:
- Miksuj razem z poprawkami na urządzeniu, aby odtwarzać
- Urządzenie do miksowania poprawek do nagrywania
Kolejne aktualizacje mogą wymagać dodatkowych poprawek na urządzeniach.
Podczas tworzenia poprawki audio, jeśli uchwyt poprawki nie jest kod HAL audio jest wymagany do wygenerowania unikalnego uchwytu poprawki, który może zidentyfikować poprawkę audio. W przeciwnym razie HAL audio powinien użyć podanego uchwytu poprawki audio, aby zaktualizować poprawkę audio.
Jeśli korzystasz ze starszej wersji HAL audio i kodu AOSP HIDL, należy ustawić starsze wersje HAL audio. główną wersję HAL 3.0.
Aby włączyć funkcję poprawki audio, należy ustawić wartość HAL audio główną wersję HAL 3.0 lub wyższe. Odwołaj się do
Device::supportsAudioPatches()w domyślna implementacja HIDL .
Dostosowywanie
Nie można jej wyłączyć ani przywrócić refaktoryzacji urządzenia audio w platforma, która pozwala dodawać typy urządzeń audio.
Wszystkie dodane typy urządzeń audio pozwalają na reprezentowanie typu urządzenia za pomocą pojedynczego zestawu bitów, więc obecne implementacje HAL nadal działają.
Gdy producent OEM doda nowe typy urządzeń audio,
muszą uaktualnić implementację HAL audio i przejść na HIDL w wersji 6.0 lub nowszej. Jest
konieczne jest uaktualnienie głównej wersji HAL do wersji 3.0 i wdrożenie interfejsu
create_audio_patch i release_audio_patch, ponieważ
za pomocą set_parameters do kierowania strumienia może spowodować nieoczekiwane rezultaty, gdy
nowe typy urządzeń audio.
Weryfikacja
Dostawcy OEM muszą zaktualizować implementacje HAL. VTS dla HAL audio można wykorzystać do sprawdzenia, czy implementacja działa zgodnie z oczekiwaniami. Wszystkie testy znajdziesz w Pliki VTS.