Limit typu urządzenia

W systemie Android audio audio_devices_t służy do reprezentowania typu urządzenia audio. Jest szeroko stosowany w kodzie źródłowym audio jako pole bitowe do filtrowania lub wybierania jednego lub więcej określonych urządzeń. Przed Androidem 11 istniał limit 30 typów urządzeń wejścia/wyjścia audio i nie było wolnych gniazd, w których można było dodawać nowe typy urządzeń audio. Usunęliśmy ograniczenie liczby typów urządzeń audio, aby umożliwić dodawanie nowych typów urządzeń audio.

Aby usunąć ograniczenie liczby typów urządzeń audio, typy urządzeń audio są teraz wyliczane jako wartości, a nie maski bitowe.

Wszystkie istniejące typy urządzeń audio pozostają bez zmian. AUDIO_DEVICE_BIT_IN jest nadal używany do rozróżniania urządzeń wejściowych i wyjściowych. Podczas dodawania nowych typów urządzeń audio ich wartości są wyliczane w odstępach pomiędzy istniejącymi wartościami.

Producenci OEM nie powinni używać audio_devices_t jako maski bitowej, ponieważ może to spowodować nieoczekiwane wyniki po dodaniu nowych wyliczonych typów urządzeń audio.

Przykłady i źródło

Przed Androidem 11 istniały dwa typowe zastosowania typów urządzeń audio jako masek bitowych.

  • Używanie wartości audio_devices_t do reprezentowania wielu urządzeń audio.
  • Sprawdzanie, czy wartość audio_devices_t zawiera typy urządzeń audio z określonej kategorii.

Aby reprezentować wiele typów urządzeń audio, używana jest klasa o nazwie DeviceTypeSet w pliku /libaudiofoundation/include/media/AudioContainers.h , która jest kontenerem std::set audio_devices_t . Klasa jest zadeklarowana w dostępnej przez dostawcę bibliotece libaudiofoundation . Aby reprezentować wiele typów urządzeń audio w kodzie C, 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 ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) w AudioContainers.h , aby sprawdzić, czy wszystkie podane typy urządzeń audio są tego samego typu.

Realizacja

Producenci OEM muszą usunąć reprezentację pola bitowego typu urządzenia audio z implementacji audio HAL.

  1. Usuń całą pamięć urządzeń z pola bitowego.

    audio_devices_t nie powinno być używane do reprezentowania wielu typów urządzeń audio. Zamiast tego użyj listy lub wektora.

  2. Przestań używać operacji bitowych do porównywania typów urządzeń.

    Przed wersją Androida 11 jako pola bitowego można używać typów urządzeń audio. W takim przypadku często stosuje się operacje bitowe do porównywania typów urządzeń. Po dodaniu nowych, wyliczonych typów urządzeń audio, operacje bitowe mogą spowodować nieoczekiwane rezultaty. Zamiast tego użyj funkcji pomocniczych jako alternatywy. Jeśli istnieje jeden typ urządzenia audio, użyj bezpośredniego porównania, aby porównać dwie 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) .

  3. Przestań używać predefiniowanych wartości dla grup typów urządzeń audio.

    Istnieją pewne predefiniowane wartości dla grup typów urządzeń audio AUDIO_DEVICE_OUT_ALL w system/media/audio/include/system/audio-base-utils.h . Wszystkie te wartości są zastrzeżone, ale mogą zostać przestarzałe, ponieważ nie będą poprawne po dodaniu nowych wyliczonych typów urządzeń audio. W audio-base-utils.h zdefiniowano nowe grupy typów urządzeń audio, które są tablicami typów urządzeń audio, np. AUDIO_DEVICE_OUT_ALL_ARRAY .

  4. Zaimplementuj metody create_audio_patch() i release_audio_patch() do routingu zamiast set_parameters .

    Metoda set_parameters wykorzystuje typy urządzeń audio jako pole bitowe, zatem w przypadku dodania nowych wyliczonych typów urządzeń audio mogą wystąpić nieoczekiwane wyniki.

    Obecnie wymagane są dwa rodzaje poprawek audio:

    • Miksuj do poprawek urządzenia w celu odtwarzania
    • Urządzenie do miksowania brzmień, do nagrywania

    W kolejnych aktualizacjach mogą być wymagane dodatkowe poprawki między urządzeniami.

    Podczas tworzenia poprawki audio, jeśli uchwyt poprawki nie jest określony, wymagana jest warstwa HAL audio, aby wygenerować unikalny uchwyt poprawki, który może zidentyfikować poprawkę audio. W przeciwnym razie warstwa audio HAL powinna użyć danego uchwytu poprawki audio do aktualizacji poprawki audio.

    Jeśli używasz starszej warstwy audio HAL i opakowania AOSP HIDL, starsza wersja audio HAL powinna ustawić główną wersję HAL na 3.0.

    Aby włączyć funkcję poprawki audio, warstwa audio HAL powinna ustawić główną wersję HAL na 3.0 lub nowszą. Aby uzyskać więcej informacji, zobacz Device::supportsAudioPatches() w domyślnej implementacji HIDL , które można również znaleźć w audio HAL dla mątwy.

Dostosowywanie

Nie można wyłączyć tej funkcji ani przywrócić refaktoryzacji urządzeń audio w środowisku umożliwiającym dodawanie typów urządzeń audio.

Wszystkie dodane typy urządzeń audio umożliwiają reprezentowanie typu urządzenia za pomocą jednego zestawu bitów, więc obecne implementacje HAL nadal działają.

Jeśli zostaną dodane nowe typy urządzeń audio i producenci OEM będą chcieli z nich korzystać, muszą zaktualizować swoją implementację audio HAL i przejść do wersji HIDL 6.0 lub wyższej. Obowiązkowa jest aktualizacja głównej wersji HAL do 3.0 i zaimplementowanie metod create_audio_patch i release_audio_patch , ponieważ użycie set_parameters do kierowania strumienia może spowodować nieoczekiwane rezultaty po dodaniu nowych typów urządzeń audio.

Walidacja

Wymaganą pracą dla producentów OEM jest aktualizacja ich implementacji HAL. VTS dla audio HAL można wykorzystać do sprawdzenia, czy implementacja działa zgodnie z założeniami. Wszystkie testy można znaleźć w plikach VTS .