Obsługa konfigurowalnych zasad dotyczących dźwięku w interfejsie AIDL HAL

Począwszy od Androida 16 interfejs AIDL Audio HAL w pełni obsługuje konfigurowalne zasady dotyczące dźwięku (CAP).

Na tej stronie znajdziesz niezbędne informacje techniczne, które pomogą partnerom i dostawcom SoC w migracji konfiguracji zasad dotyczących dźwięku.

Platforma parametrów

Implementacja CAP opiera się na ramach parametrów Intela. CAP został wprowadzony w Androidzie 6. Platforma parametrów (PfW) umożliwia opisywanie systemu za pomocą parametrów. Za pomocą pliku konfiguracyjnego XML PfW łączy parametry z działaniami za pomocą wtyczek i zapewnia reguły zmiany parametrów zgodnie z aktualnymi kryteriami.

Struktura CAP w HIDL

W HIDL cała konfiguracja CAP została określona w formacie XML. Więcej informacji znajdziesz w artykule Framework parametrów oraz Konfiguracja za pomocą frameworku parametrów. Pliki XML służyły do określenia tych elementów:

  • Opis struktury parametrów (czyli opis domeny audio dla PfW)
  • Definicje kryteriów
  • Reguły dotyczące strategii routingu (wybór urządzenia wejściowego i wyjściowego)
  • Specyfikacja tabel woluminów

Dzięki HIDL platforma Android mogła wczytywać te pliki XML bezpośrednio z partycji dostawcy. Było to dozwolone, ponieważ w ramach interfejsu HAL API zdefiniowano schemat XSD dla tych plików XML. Każda główna wersja HIDL HAL miała odpowiadający jej schemat XSD. Duże aktualizacje nie wymagają zgodności wstecznej.

Struktura CAP w AIDL

W przypadku przejścia na interfejs AIDL wersje interfejsu HAL muszą być zgodne wstecz (w terminologii HIDL każda wersja interfejsu HAL AIDL jest „małą” aktualizacją). Schematów XSD nie można już używać w ramach interfejsów HAL, ponieważ nie ma ustalonego sposobu definiowania aktualizacji schematów zgodnych wstecznie. Dlatego konfigurację, która była wcześniej zdefiniowana w plikach XML, musi teraz dostarczyć HAL za pomocą interfejsów AIDL. Aby to ułatwić, strukturę konfiguracji CAP zamienia się w AIDL, podobnie jak pliki XML konfiguracji zasad dotyczących dźwięku w interfejsie AIDL Audio HAL w Androidzie 15.

Struktury danych w CAP są dodawane do wspólnych stabilnych typów danych i obejmują te elementy:

Punkt wejścia do konfiguracji CAP znajduje się w strukturze AudioHalEngineConfig.CapSpecificConfig. Schemat struktur danych CAP znajdziesz w komentarzach w AudioHalCapConfiguration.aidl.

Domyślna implementacja interfejsu API AIDL zawiera pomocniczą klasę, która wypełnia obiekty AIDL na podstawie zawartości starszych plików XML CAP, aby ułatwić partnerom migrację.

Scenariusze migracji

Partnerzy mogą rozważyć opcje wymienione w tej sekcji, w zależności od tego, czy jest to pierwsze wdrożenie usługi, która wcześniej nie korzystała z CAP, czy też migracja dotychczasowej usługi.

Nowy produkt

W przypadku nowego produktu, który zaczyna używać CAP do implementacji zasad dotyczących dźwięku, OEM może zdecydować się na użycie pliku XML do przechowywania konfiguracji CAP po stronie dostawcy.

Zaletą używania XML jest to, że istnieje zestaw narzędzi do tworzenia skryptów, które ułatwiają generowanie konfiguracji na podstawie ogólnego opisu.

Jeśli OEM zdecyduje się na używanie formatu XML do przechowywania konfiguracji CAP na partycji dostawcy, zaleca się użycie domyślnej implementacji parsarza XML do konwertowania konfiguracji na AIDL.

Aktualizacja dotychczasowego produktu

Jeśli produkt korzysta już z protokołu CAP i ma konfigurację XML, możesz nadal używać dotychczasowego interfejsu CAP z wersją interfejsu HAL AIDL.

Konwencja nazewnictwa strategii dotyczących produktów różni się w wersjach konfiguracji CAP: HIDL i AIDL. W HIDL wbudowane („starsze”) strategie używają krótkich nazw w dużych literach, np. media, podczas gdy w AIDL wbudowane strategie używają nazw w dużych literach z prefiksem STRATEGY_, np. STRATEGY_MEDIA. Zobacz listę wbudowanych strategii w sekcji CapProductStrategies.xml. Ten sam plik definiuje „przypisane wstępnie” identyfikatory strategii dla OEM-ów, które mają nazwy o wzorze vx_10xx z liczbami od 1000 do 1039.

Starsza usługa

Jeśli produkt, który korzysta z CAP, nie aktualizuje partycji dostawcy i pozostawia ją w HIDL, możesz zaktualizować partycję systemową do Androida 16. Struktura pozostaje zgodna ze starszą konfiguracją CAP.

Przykładowa implementacja

Aby pomóc partnerom w wdrażaniu CAP na swoich platformach, AOSP udostępnia przykład „samochodowej” wersji urządzenia wirtualnego Cuttlefish, które korzysta z CAP z AIDL HAL. Konfiguracja urządzenia znajduje się w folderze device/google/cuttlefish/shared/auto/audio/policy/engine, a jej nazwa docelowa to lunch aosp_cf_x86_64_auto. Plik Android.bp może służyć jako plik referencyjny do generowania pełnego zestawu plików dostawcy CAP.