Konfigurowalny mechanizm zasad dotyczących dźwięku

W Androidzie 14 system operacyjny Android Automotive (AAOS) korzysta z silnika konfigurowalnych zasad dotyczących dźwięku (CAP) do zarządzania dźwiękiem w samochodzie w ramach głównej strefy audio. W szczególności mechanizm CAP umożliwia AAOS sterowanie tylko kierowaniem dźwięku, tylko głośnością dźwięku lub jednocześnie kierowaniem i głośnością. Aby kontrolować działanie funkcji, możesz użyć tych flag:

• Aby włączyć zarządzanie głośnością w CAP, użyj flagi useCoreAudioVolume. Gdy ta wartość to true, usługa audio w samochodzie używa interfejsów API menedżera audio do zarządzania grupami głośności.

• Użyj flagi useCoreAudioRouting, aby włączyć zarządzanie kierowaniem dźwięku w CAP. Gdy ta wartość wynosi true, usługa audio w samochodzie korzysta z konfigurowalnego routingu zasad audio do zarządzania routingiem audio.

Silnik zasad dotyczących dźwięku jest też domyślnie obsługiwany w Androidzie w postaci domyślnego silnika zasad dotyczących dźwięku.

Tło

Mechanizm CAP jest oparty na ramówce parametrów firmy Intel, która jest platformą opartą na wtyczkach i regułach do obsługi parametrów. W szczególności w przypadku zarządzania dźwiękiem w Androidzie silnik CAP umożliwia definiowanie reguł plików XML, które określają:

• Strategia dotycząca produktów audio
• Reguły wyboru urządzenia wyjściowego audio
• Reguły wyboru urządzenia wejściowego audio
• Reguły do zarządzania głośnością i wyciszaniem oraz tabele głośności

Inicjalizacja CAP przed Androidem 16

Na rysunku poniżej przedstawiono ogólne omówienie konfigurowalnego zarządzania konfiguracją mechanizmu polityki audio w Androidzie 6:

Rysunek 1. Zarządzanie konfiguracją silnika CAP w wersji Androida 6.

Jak widać na rysunku, konfiguracja silnika CAP jest uzyskiwana przez usługę zasad dotyczących dźwięku poprzez parsowanie informacji z audio_policy_engine_configuration.xml pliku w partycji vendor. Plik konfiguracji silnika CAP używa schematu zdefiniowanego w audio_policy_engine_configuration.xsd, aby uzyskać wymagane informacje. audio_policy_engine_configuration.xml to przykład dotyczący motoryzacji. Podobne przykłady dla innych formatów są dostępne w folderze frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

Na rysunku poniżej znajdziesz więcej informacji o tym, jak w usłudze zasad dotyczących dźwięku są wczytywane informacje z konfigurowalnego mechanizmu zasad dotyczących dźwięku. W tym przypadku framework parametrów wczytuje strukturę i ustawienia z plików XML.

Rysunek 2. Informacje CAP załadowane w usłudze audiopolicy.

Pliki struktury CAP w Androidzie 15 i starszym

Aby uzyskać strukturę i ustawienia, usługa zasad dotyczących treści audio odczytuje plik ParameterFrameworkConfigurationPolicy.xml. Odwołuje się do informacji o strukturze za pomocą lokalizacji pliku opisu struktury:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

To wskazuje na strukturę informacji w pliku:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Na Androidzie jest dostępna struktura podstawowa. Informacje o strukturze wymagają informacji o strukturze strategii produktu, dlatego Android udostępnia buildStrategiesStructureFile.py narzędzia do generowania, które może generować informacje z dostępnego pliku XML strategii produktu. Można się do niego odwoływać za pomocą parametru genrule default buildstrategiesstructurerule w ten sposób:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Gdzie audio_policy_engine_configuration_files to pliki konfiguracji mechanizmu zasad dotyczących dźwięku. Ten przykład dla branży motoryzacyjnej odwołuje się do plików konfiguracji zasad dotyczących dźwięku w folderze automotive. Inne przykłady pokazują, jak skonfigurować kompilację, aby przesłać pliki do partycji dostawcy urządzenia.

Pliki ustawień CAP w Androidzie 15 i starszych

Podobnie jak w przypadku struktury, informacje o ustawieniach, które reprezentują reguły i wartości parametrów, są w pliku ParameterFrameworkConfigurationPolicy.xml oznaczone jako:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android udostępnia też narzędzia do kompilacji, które generują te informacje za pomocą konfiguracji silnika zasad dotyczących dźwięku i plików ramowych parametrów. Więcej informacji znajdziesz w sekcji Konfiguracje.

Inicjowanie inicjalizacji CAP HAL dźwięku AIDL

Począwszy od Androida 16 definicja interfejsu API HAL dla dźwięku w AIDL została rozszerzona o konfiguracje mechanizmu zasad dotyczących dźwięku (plik AudioHalCapConfiguration.aidl). Na rysunku poniżej znajdziesz ogólne omówienie zarządzania konfiguracją silnika CAP w Androidzie 16:

Rysunek 3. Zarządzanie konfiguracją silnika CAP w wersji Android 16.

Usługa polityki audio uzyskuje informacje o silniku CAP za pomocą interfejsów API AIDL Audio HAL bezpośrednio, zamiast analizować informacje z plików XML w partycji dostawcy urządzenia.

W tej konfiguracji struktura ramki parametrów jest nadal wczytywana przez mechanizm CAP po stronie serwera audio.

Rysunek 4. Struktura silnika CAP.

W każdym przypadku konfiguracja musi zawierać pełne informacje o strategiach produktowych, grupach wolumenowych i kryteriach.

Na rysunku poniżej znajdziesz ogólny opis interfejsów API HAL audio AIDL, których usługa zasad dotyczących dźwięku używa do uzyskiwania konfiguracji silnika CAP:

Rysunek 5. Interfejsy API HAL dźwięku AIDL.

W tej konfiguracji usługa zasad dotyczących dźwięku uzyskuje z HAL audio AIDL te informacje:

• Konfiguracja
• Strategie
• Tomy
• Kryteria
• Ustawienia

Domyślny ładowar HAL dźwięku AIDL

Aby ułatwić przejście z HIDL na AIDL, domyślny moduł audio AIDL Audio HAL udostępnia moduł wczytywania silnika CAP w formacie XML. Dostawcy mogą używać tego ładowarki bezpośrednio, rozszerzając interfejs HAL dźwięku o domyślny interfejs HAL dźwięku lub odwołując się do biblioteki libaudioserviceexampleimpl.

Domyślny ładownik HAL audio AIDL używa audio_policy_engine_configuration.xmldo uzyskania tych informacji:

• Konfiguracja
• Strategie
• Tomy
• Kryteria

Informacje o strukturze są uzyskiwane z pliku PolicyConfigurableDomains.xml. Główną różnicą w stosunku do poprzedniego mechanizmu jest to, że informacje o strukturze są również uzyskiwane przez interfejs audio HAL AIDL zamiast przez ramy parametrów w usłudze dotyczącej zasad dotyczących dźwięku.

Do generowania domen konfigurowalnych za pomocą informacji z konfiguracji silnika zasad audio można użyć narzędzia domaingeneratorpolicyrule. Jako przykład można użyć wirtualnego urządzenia Cuttlefish.

Struktura w konfiguracji AIDL

W Androidzie 16 i nowszych usługa audio policy uzyskuje informacje o strukturze, odczytując i analizując ParameterFrameworkConfigurationCap.xml[plik](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). W szczególności pobiera informacje z pliku opisu struktury:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

Platforma umieszcza wymagane pliki w folderze /etc/parameter-framework/z potrzebnymi informacjami.

Struktura reprezentuje parametry, które należy kontrolować, dlatego należy je uwzględnić w konfiguracji lub domenach. W tym celu silnik AIDL powinien używać z góry określonej nazwy parametrów. W przypadku strategii dotyczących produktów struktury są konfigurowane w CapProductStrategies.xml.

Domyślne strategie produktów

Począwszy od domyślnych ustawień w domyślnym mechanizmie strategie produktów zaczynają się od prefiksu STRATEGY_:

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Ten format został udostępniony, aby ułatwić przejście z HIDL na AIDL na urządzeniach, które korzystały ze strategii domyślnych. Ta zmiana formatu ma pewne konsekwencje dla dotychczasowych plików (np. PfW, XML), które służą do konfigurowania silnika. W szczególności należy zmienić wszystkie odniesienia do strategii produktu, aby używały nowych nazw. Na przykład:

Strategie produktów określone przez producenta OEM

Konfigurowalny mechanizm umożliwia producentom OEM zmianę definicji strategii dotyczących produktów. Aby zapewnić dalszą obsługę tej funkcji, plik strategii produktów CapProductStrategies.xml zawiera 40 strategii produktów, które można rozszerzyć o elementy pochodzące od dostawców (vx_1000–vx_1039). Wszystkie rozszerzenia producenta muszą zaczynać się od prefiksu vx_, a za nim musi podać numer odpowiadający identyfikatorowi strategii produktu w definicji strategii produktu HAL audio AIDL. Pozostałe definicje (np. grupy atrybutów dźwięku, nazwa) są pobierane z obiektu AudioHALProductStrategy w konfiguracji mechanizmu sterowania HAL dźwięku.

Podobnie jak w przypadku domyślnych strategii produktów, odniesienia do OEM-ów zdefiniowane przez dostawcę muszą zostać dostosowane do konfiguracji bez AIDL i konfiguracji AIDL, na przykład:

Strategie dotyczące produktów

Strategie dotyczące produktów umożliwiają dostosowanie sposobu kategoryzowania i grupowania strumieni audio. Daje to większą elastyczność w konfigurowaniu urządzeń audio, w tym ich kierowania i zarządzania głośnością. Każda strategia dotycząca produktu może mieć co najmniej jedną grupę atrybutów audio, która identyfikuje strumienie, które należy powiązać z tą strategią. Te grupy atrybutów audio umożliwiają bardziej szczegółowe kategoryzowanie dźwięku i mogą być mieszanką tych typów:

• Typy użycia opisują, dlaczego odtwarzany jest dźwięk (np. media, powiadomienie, połączenie).
• Typ treści: typy opisują odtwarzane treści (muzykę, mowę, film, sonifikację).
• Typy flag definiują różne zachowania lub żądania dotyczące strumienia.
• Typy tagów obsługują dowolną listę wartości ciągu znaków dostawcy.
  • Każdy ciąg musi zaczynać się od VX_, a następnie zawierać ciąg alfanumeryczny (np. VX_OEM, VX_NAVIGATION).

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

Ten fragment pokazuje przykład strategii dotyczącej produktów stosowanej w emulatorach samochodów. Zawiera ona 2 atrybuty dźwięku: odpowiednio atrybuty z mediami i grami. Ta strategia dotycząca produktów pasuje do kontekstu audio MUSIC używanego w usłudze audio samochodowej, ale nie jest wymagane takie dopasowanie. Jedną z głównych zalet dla producentów OEM korzystających z CAP i Androida jest możliwość bardziej elastycznego definiowania grup dźwięków.

Grupy objętości

Dodatkowo każda grupa atrybutów audio musi mieć powiązaną grupę objętości. Ta grupa wolumin jest powiązana ze wszystkimi strumieniami, które pasują do atrybutów audio należących do grupy atrybutów audio. Przykładowa strategia dotycząca produktów muzycznych w sekcji Strategie dotyczące produktów ma grupę głośności media, a definicja grupy głośności multimediów wygląda tak:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

W tej definicji grupa woluminów zawiera:

• Nazwa grupy
• Indeks minimum grupy
• Indeks maksymalny grupy
• Krzywe grupy głośności

Krzywe grupy głośności zawierają punktowe mapowanie między indeksem grupy głośności a wzmocnieniem głośności w milibelach. Podane punkty są używane do liniowej interpolacji najlepszego dopasowania przy zmianie objętości. Każda krzywa grupy głośności jest powiązana z kategorią typu urządzenia (np. zestaw słuchawkowy, głośnik, zewnętrzne nośniki).

Grupa głośności zarządza głośnością strumieni, które są częścią grupy atrybutów audio. Na przykład, gdy rozpoczyna się strumień z atrybutami audio zawierającymi muzykę lub grę, używany jest ostatni ustawiony indeks głośności dla grupy głośności multimediów. W tym przypadku odpowiednia krzywa kategorii urządzenia jest wybierana na podstawie wybranego urządzenia, a odpowiednia wartość wzmocnienia jest ustawiana po uruchomieniu strumienia.

Konfiguracje

W silniku CAP konfiguracje służą do definiowania warunków lub reguł określających zachowanie dźwięku. Te konfiguracje są oceniane w czasie wykonywania, aby wybrać odpowiednie reguły do zastosowania w zależności od bieżącego stanu systemu audio.

Jak widać na rysunku 5, interfejs API zawiera wiele domen, a celem każdej z nich jest podzielenie logiki na mniejsze problemy związane z przekierowywaniem (np. urządzenie 1, urządzenie 2).

Każda domena ma konfiguracje, a każda konfiguracja ma zestaw reguł. Reguły są ustalane na podstawie tych kryteriów:AudioPolicyManager

• Tryb „tylko dźwięk”
• Dostępne urządzenia wejściowe i wyjściowe
• adresy dostępnych urządzeń wejściowych i wyjściowych;
• Używaj do:
  • Multimedia
  • Komunikacja
  • Nagrywam
  • Zadokuj
  • System
  • Dźwięk z systemu HDMI
  • Kodowany dźwięk przestrzenny
  • Wibracje przy dzwonku

Każda domena zawiera konfiguracje, które określają reguły wpływające na działanie. Pamiętaj, że kolejność konfiguracji ma znaczenie. Upewnij się, że konfiguracje są ustawione w wymaganej kolejności. Po zweryfikowaniu reguł konfiguracji następuje jej wybór.

Poniższy kod zawiera przykładowy fragment pliku ramowego parametrów, który można wykorzystać do wygenerowania wymaganego pliku XML do konfigurowania domen konfigurowalnych:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

Domena DeviceForProductStrategies określa, jak stosować różne reguły podczas obsługi strategii produktowych dotyczących wyboru urządzenia. Części w kolorze niebieskim opisują reguły, które należy wziąć pod uwagę, a część w kolorze zielonym to zastosowana konfiguracja. Ten przykład zawiera te konfiguracje:

• Wybierz urządzenie Bluetooth A2DP do strategii dotyczącej produktów muzycznych (identyfikator 1000, vx_1000)
  • Jeśli używany do multimediów, nie wyklucza A2DP
  • Jeśli używany do komunikacji, nie jest BT SCO
  • Jeśli dostępne są urządzenia, uwzględnij BT A2DP.
• Wybierz urządzenie magistrali
  • Jeśli dostępne są urządzenia autobusowe
  • Jeśli adres to BUS00_MEDIA
• Wybierz domyślne urządzenie wyjściowe

Aby wygenerować odpowiedni plik XML konfigurowalnego mechanizmu zasad, uruchom pliki frameworku parametrów (PFW) za pomocą systemu kompilacji, definiując regułę kompilacji w ten sposób:

1. W pliku Android.bp utwórz grupę plików:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Dodaj plik do innych plików PfW (jeśli takie istnieją).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. Utwórz odpowiednią regułę generowania domeny:

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Gdzie domaingeneratorpolicyrule to reguła generowania podana przez platformę w celu wygenerowania pliku PolicyConfigurableDomains.xml. Inne pliki źródłowe (scrs) uwzględnione w regułach generowania domen:

   Źródło	Opis
   audio_policy_pfw_toplevel	Plik konfiguracji frameworku parametrów najwyższego poziomu.
   audio_policy_pfw_structure_files	Pliki struktury generowania domeny, które służą do generowania plików konfiguracji.
   audio_policy_engine_criterion_types	Plik XML z typami kryteriów, który opisuje kryteria użyte podczas generowania.
   edd_files	Lista plików pojedynczych domen (każdy zawiera pojedynczy tag <ConfigurableDomain>).

Po zastosowaniu reguły generowania w kompilacji generowany jest element PolicyConfigurableDomains.xml ze wszystkimi domenami. Poniżej znajduje się fragment wygenerowanego pliku z wykorzystaniem reguł PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Debugowanie kodu CAP

Aby wyodrębnić konfiguracje CAP, możesz użyć polecenia remote-process:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Pokazuje wszystkie domeny i konfiguracje, w tym warunki stosowania. Poniżej przedstawiono fragment urządzenia samochodowego Cuttlefish, które korzysta z Bluetooth A2DP, urządzenia bus i ustawień domyślnych. Patrz Konfiguracje:

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Więcej informacji o innych poleceniach do debugowania frameworku parametrów CAP znajdziesz w tym narzędziu:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Aby móc korzystać z tego narzędzia, producenci OEM muszą zezwolić na dostosowanie urządzenia. Aby sprawdzić, czy urządzenie umożliwia dostosowanie, użyj tego polecenia:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

W przypadku Androida 15 i starszych plik może być inny, dlatego użyj tego polecenia:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

Plik powinien zawierać TuningAllowed="true" wraz z odpowiednim portem serwera:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Ten plik jest generowany automatycznie na podstawie typu obrazu kompilacji (lub innego pliku w przypadku wersji produkcyjnej lub debugowania w przypadku wersji niestandardowej). Kompilacja wersji produkcyjnej ustawia wartość TuningAllowed na false bez gniazda (gniazda są zabronione w przypadku kompilacji wersji produkcyjnych). Inżynierowie i ustawienia userdebug ustawiają je na true z wykorzystywanym gniazdem. Pamiętaj, że jest to plik, do którego odwołuje się audio_policy_pfw_toplevel. Narzędzie do przetwarzania zdalnego musi być również uwzględnione w make urządzenia lub pliku kompilacji:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

Należy też uwzględnić odpowiednią zasadę SELinux, aby zezwolić na gniazda. Działa to tylko w trybie debugowania, ponieważ tryb wydania wyraźnie zabrania korzystania z gniazd:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Migracja CAP w Androidzie 16

Ze względu na duże zmiany wprowadzone przez silnik HAL CAP audio AIDL i poprzednie wersje, należy wziąć pod uwagę różne scenariusze przejścia na nowe wersje. W tej sekcji omawiamy najważniejsze scenariusze przejścia na nowy system i podajemy rekomendacje dotyczące czynności, które należy wykonać, aby włączyć konfigurację silnika CAP.

Scenariusz 1. Nowe urządzenie z Androidem 16 lub nowszym, bez poprzedniego źródła konfiguracji CAP urządzenia

Nowe urządzenie musi być uruchamiane z Androidem 16 lub nowszym w ramach kodu na partycji vendor. Oznacza to, że musi udostępniać konfigurowalną konfigurację silnika zasad dotyczących dźwięku za pomocą interfejsu HAL dźwięku AIDL. Konfiguracja silnika CAP urządzenia powinna być skopiowana z przykładów. W partycji vendor nie powinno być definicji domeny CAP w ramach szyfrowania kluczem publicznym.

obraz systemu używany na urządzeniu to Android 16 lub nowszy. Framework usługi audio wykrywa konfigurację CAP za pomocą interfejsu HAL dźwięku AIDL, więc inicjuje PfW za pomocą definicji domeny CAP PfW z obrazu systemu i wczytuje konfigurację CAP urządzenia otrzymaną za pomocą AIDL.

Przykładem jest wirtualne urządzenie Cuttlefish dla branży motoryzacyjnej, które zostało wprowadzone w ramach tej zmiany. Można się do niego odwoływać, aby uzyskać informacje o wymaganych plikach, regułach kompilacji i plikach make, które są potrzebne do skonfigurowania wymaganych plików konfiguracji. Funkcja działa z ładowarkami udostępnionymi w domyślnym interfejsie dźwiękowym AIDL.

Scenariusz 2. Nowe urządzenie z Androidem 16 lub nowszym, z poprzedniego urządzenia z użyciem CAP

Nowe urządzenie musi być uruchamiane z Androidem 16 lub nowszym w ramach kodu na partycji vendor. Producent OEM ma jednak konfigurację silnika CAP, którą może wykorzystać jako punkt wyjścia (lub użyć jej w pełni). Wersja AIDL konfiguracji CAP różni się nieco od wersji na Androida 15 i starszych, dlatego sprzedawca musi przekonwertować dotychczasową konfigurację na AIDL. Informacje o zmianach między Androidem 16 a starszymi wersjami znajdziesz w dyskusji na temat strategii dotyczących produktów. Ogólnie framework audio wykrywa i wczytuje konfigurację CAP w taki sam sposób jak w sytuacji 1.

Scenariusz 3. Na istniejącym urządzeniu z CAP aktualizowana jest tylko partycja systemowa do Androida 16

W tym scenariuszu partycja vendor zawiera konfigurację CAP urządzenia w wersji 15 lub starszej oraz definicję domeny CAP PfW. Partycja vendor pozostaje nietknięta, więc nadal używa interfejsu HIDL HAL. Platforma działa zgodnie ze scenariuszem Androida 15 i starszych oraz wczytuje całą konfigurację związaną z CAP z partycji vendor.

Scenariusz 4. Istniejące urządzenie z Androidem 15 z CAP

Protokół CAP nie był obsługiwany w AIDL w Androidzie 15, dlatego niektórzy sprzedawcy wydali nowe urządzenia z AIDL Audio HAL i CAP, które były ładowane przez interfejs audio. Ten tryb hybrydowy był nieoficjalny, ale jest uwzględniony w Androidzie 16. Pamiętaj, że tego trybu nie należy używać do publikowania nowych urządzeń z Androidem 16, ale do umożliwienia aktualizacji istniejących urządzeń z Androidem 15 do Androida 16 (aktualizacja partycji system).

Framework audio wykrywa konfigurację audio HAL AIDL bez konfiguracji CAP. W przypadku konfiguracji CAP usługa zasad dźwięku (ramka audio) wczytuje konfigurację CAP z partycji vendor. W tym przypadku z partycji vendor należy załadować zarówno definicję domeny CAP PfW, jak i konfigurację CAP urządzenia.

Podsumowanie migracji CAP

Tabela poniżej zawiera podsumowanie kompatybilnych konfiguracji systemu i usługodawcy oraz wymagania dotyczące konfiguracji CAP: