Konfigurowalny mechanizm zasad dotyczących dźwięku

W Androidzie 14 system operacyjny Android Automotive (AAOS) wykorzystuje silnik konfigurowalnych zasad audio (CAP) do zarządzania dźwiękiem w samochodzie w głównej strefie audio. Silnik 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ą. Do kontrolowania działania można używać tych flag:

• Użyj flagi useCoreAudioVolume, aby włączyć zarządzanie głośnością CAP. Gdy ta wartość wynosi true, usługa audio w samochodzie używa interfejsów API menedżera dźwięku do zarządzania grupami głośności.

• Użyj flagi useCoreAudioRouting, aby włączyć zarządzanie routingiem audio CAP. Gdy ta wartość wynosi true, usługa audio w samochodzie używa konfigurowalnego routingu zasad audio do zarządzania routingiem audio.

Silnik zasad audio jest też domyślnie obsługiwany w Androidzie w postaci domyślnego silnika zasad audio.

Tło

Mechanizm CAP oparty jest na platformie parametrów firmy Intel, która jest platformą wtyczkową i opartą na regułach do obsługi parametrów. W przypadku zarządzania dźwiękiem na Androidzie silnik CAP wprowadził możliwość definiowania reguł w plikach XML, aby określać:

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

Inicjowanie CAP przed Androidem 16

Na poniższym rysunku przedstawiono ogólny przegląd zarządzania konfigurowalnym silnikiem zasad audio w Androidzie 6:

Rysunek 1. Zarządzanie konfiguracją silnika CAP w Androidzie 6.

Jak pokazano na rysunku, konfiguracja silnika CAP jest pobierana przez usługę zasad audio przez analizowanie informacji z pliku audio_policy_engine_configuration.xml w partycji vendor. Plik konfiguracji silnika CAP korzysta ze schematu zdefiniowanego w audio_policy_engine_configuration.xsd, aby uzyskać wymagane informacje. audio_policy_engine_configuration.xml to przykład w przypadku branży motoryzacyjnej. Podobne przykłady dla innych formatów znajdziesz w folderze frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

Na poniższym rysunku znajdziesz bardziej szczegółowe informacje o tym, jak w usłudze zasad audio wczytywane są informacje o konfigurowalnym module zasad audio. W tym przypadku platforma parametrów wczytuje strukturę i ustawienia z plików XML.

Rysunek 2. Informacje CAP załadowane w ramach usługi zasad dotyczących dźwięku.

Pliki struktury CAP w Androidzie 15 i starszych

Aby uzyskać strukturę i ustawienia, usługa zasad dotyczących dźwięku odczytuje plik ParameterFrameworkConfigurationPolicy.xml. Odwołuje się to do informacji o strukturze za pomocą lokalizacji pliku opisu struktury:

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

Wskazuje informacje o strukturze w pliku:

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

Struktura szkieletowa jest dostępna w Androidzie. Informacje o strukturze wymagają informacji o strukturze strategii produktu, dlatego Android udostępnia buildStrategiesStructureFile.py narzędzie do generowania, które może generować informacje z dostępnego pliku XML strategii produktu. Można się do niego odwołać za pomocą domyślnej reguły genrule buildstrategiesstructurerule w ten sposób:

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

Gdzie audio_policy_engine_configuration_files znajdują się pliki konfiguracji silnika zasad audio. Ten przykład dotyczący motoryzacji odwołuje się do plików konfiguracji zasad audio 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ą przywoływane w pliku ParameterFrameworkConfigurationPolicy.xml w ten sposób:

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

Android udostępnia też narzędzia do kompilacji, które generują te informacje na podstawie konfiguracji silnika zasad audio i plików struktury parametrów. Więcej informacji znajdziesz w sekcji Konfiguracje.

Inicjowanie AIDL audio HAL CAP

Od Androida 16 definicja interfejsu AIDL Audio HAL API jest rozszerzona o konfiguracje silnika zasad audio, AudioHalCapConfiguration.aidl. Na poniższym rysunku przedstawiono ogólne omówienie zarządzania konfiguracją silnika CAP w Androidzie 16:

Rysunek 3. Zarządzanie konfiguracją silnika CAP w Androidzie 16.

Usługa zasad audio pobiera informacje o silniku CAP bezpośrednio za pomocą interfejsów API AIDL Audio HAL, a nie przez analizowanie informacji z plików XML w partycji dostawcy urządzenia.

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

Rysunek 4. Struktura mechanizmu CAP.

We wszystkich przypadkach konfiguracja musi w pełni określać informacje dotyczące strategii produktowych, grup wolumenu i kryteriów.

Na rysunku poniżej przedstawiono ogólny przegląd interfejsów API HAL audio AIDL, które są używane przez usługę zasad audio do uzyskiwania konfiguracji silnika CAP:

Rysunek 5. interfejsy API AIDL audio HAL;

W tej konfiguracji usługa zasad audio uzyskuje z AIDL audio HAL te informacje:

• Konfiguracja
• Strategie
• Tomy
• Kryteria
• Ustawienia

Domyślny moduł ładowania AIDL Audio HAL

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

Domyślny moduł ładowania HAL audio AIDL używa audio_policy_engine_configuration.xml do uzyskiwania tych informacji:

• Konfiguracja
• Strategie
• Tomy
• Kryteria

Informacje o strukturze są pobierane z PolicyConfigurableDomains.xmlpliku. Główna różnica w porównaniu z poprzednim mechanizmem polega na tym, że informacje o strukturze są też uzyskiwane przez interfejs HAL audio AIDL, a nie przez platformę parametrów w usłudze zasad audio.

Dostawcy mogą używać narzędzia domaingeneratorpolicyrule do generowania konfigurowalnych domen na podstawie informacji z konfiguracji silnika zasad dotyczących dźwięku. Jako punkt odniesienia możesz wykorzystać przykład wirtualnego urządzenia Cuttlefish dla motoryzacji.

Struktura w konfiguracji AIDL

W Androidzie 16 i nowszych wersjach usługa zasad audio pobiera informacje o strukturze, odczytując i parsują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"/>

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

Struktura reprezentuje parametry, które powinny być kontrolowane, więc należy się do nich odwoływać w konfiguracji lub domenach. W tym celu konfiguracja silnika AIDL powinna 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 dotyczące produktów

Strategie dotyczące produktów zaczynają się od prefiksu STRATEGY_, a ich wartości domyślne są podane w domyślnym silniku:

• 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 istniejących plików (np. PfW, XML), które są używane do konfigurowania silnika. W szczególności wszystkie odniesienia do strategii dotyczących produktów powinny zostać zmienione tak, aby używać nowych nazw, na przykład:

Strategie dotyczące produktów określone przez producenta OEM

Konfigurowalny silnik umożliwia producentom OEM zmianę definicji strategii dotyczących produktów. Aby nadal to umożliwiać, plik strategii dotyczących produktów CapProductStrategies.xml zawiera też 40 strategii dotyczących produktów, które mogą być rozszerzane przez dostawców, w zakresie od vx_1000 do vx_1039. Wszystkie rozszerzenia dostawcy muszą zaczynać się od prefiksu vx_ i zawierać numer, który reprezentuje identyfikator strategii produktu w definicji strategii produktu AIDL audio HAL. Pozostałe definicje (np. grupy atrybutów audio, nazwa) są pobierane z obiektu AudioHALProductStrategy w konfiguracji silnika HAL audio.

Podobnie jak w przypadku domyślnych strategii dotyczących produktów, odniesienia do OEM zdefiniowane przez dostawcę muszą być dostosowane między konfiguracją bez AIDL a konfiguracją AIDL, np.:

Strategie dotyczące usług

Strategie dotyczące produktów umożliwiają dostosowywanie sposobu kategoryzowania i grupowania strumieni audio. Zapewnia to większą elastyczność w konfigurowaniu urządzeń audio, w tym sposobu kierowania dźwięku 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 powinny być powiązane z tą strategią. Te grupy atrybutów audio umożliwiają bardziej szczegółowe podejście do kategoryzowania dźwięku i mogą zawierać kombinację tych typów:

• Typy użycia określają, dlaczego odtwarzany jest dźwięk (np. multimedia, powiadomienie, połączenie).
• Typy treści opisują, co jest odtwarzane (czyli muzyka, mowa, wideo, sonifikacja).
• Typy flag określają różne zachowania lub żądania w odniesieniu do strumienia.
• Typy tagów obsługują dowolną listę wartości ciągów tekstowych dostawcy.
  • Każdy ciąg musi zaczynać się od znaku VX_, a po nim musi następować 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 zawiera przykład strategii dotyczącej produktów używanych w emulatorach samochodowych. Zawiera 2 atrybuty audio: audio usage media i audio usage game. Ta strategia produktu jest zgodna z kontekstem audio MUSIC używanym w usłudze audio w samochodzie, ale nie jest to wymagane. Jedną z głównych zalet korzystania z CAP w połączeniu z Androidem dla producentów OEM jest możliwość bardziej elastycznego definiowania grup audio.

Grupy woluminów

Dodatkowo każda grupa atrybutów audio musi mieć powiązaną grupę głośności. Ta grupa głośności jest powiązana z dowolnym strumieniem pasującym 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 zawiera grupę głośności media, a definicja grupy głośności multimediów jest następująca:

<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
• Minimalny indeks grupy
• Maksymalny indeks grupy
• Krzywe grup głośności

Krzywe grupy głośności zawierają mapowanie punktowe między indeksem grupy głośności a wzmocnieniem głośności w milibelach. Podane punkty są używane do liniowej interpolacji najlepiej dopasowanego wzmocnienia, gdy głośność jest zarządzana. Każda krzywa grupy głośności jest powiązana z kategorią typu urządzenia (np. słuchawki, głośnik, zewnętrzne multimedia).

Grupa głośności zarządza głośnością strumieni, które należą do 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 odpowiednie wzmocnienie jest ustawiane po uruchomieniu strumienia.

Konfiguracje

W silniku CAP konfiguracje służą do definiowania warunków lub reguł, które określają, jak ma się zachowywać dźwięk. Te konfiguracje są oceniane w czasie działania, 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. Celem każdej z nich jest podzielenie logiki na mniejsze problemy z routingiem (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 kryteriów podanych przez 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
  • Zakodowany dźwięk przestrzenny
  • Wibracje przy dzwonku

Każda domena zawiera konfiguracje, które określają reguły wpływające na zachowanie. Pamiętaj, że kolejność konfiguracji ma znaczenie i musisz się upewnić, że są one w odpowiedniej kolejności. Po zweryfikowaniu reguł konfiguracji jest ona wybierana.

Poniższy kod zawiera przykładowy fragment pliku struktury parametrów, którego można użyć 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 różne reguły powinny być stosowane podczas obsługi wyboru urządzenia w strategiach dotyczących produktów. Niebieskie części opisują reguły, które należy wziąć pod uwagę, a zielona część to zastosowana konfiguracja. Ten konkretny przykład zawiera te konfiguracje:

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

Aby wygenerować odpowiedni konfigurowalny plik XML silnika zasad, uruchom pliki frameworka parametrów (PFW) w systemie kompilacji, definiując regułę kompilacji, wykonując te czynności:

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 udostępniana przez platformę do generowania pliku PolicyConfigurableDomains.xml. Pozostałe pliki źródłowe (scrs) uwzględnione w regułach generowania domen to:

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

Po uruchomieniu reguły generowania w kompilacji plik PolicyConfigurableDomains.xml zostanie wygenerowany ze wszystkimi domenami. Poniżej znajdziesz fragment wygenerowanego pliku z użyciem reguł z przykładu 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 CAP

Aby zrzucić konfiguracje CAP, możesz użyć tego polecenia:remote-process

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

Wyświetli to wszystkie domeny i konfiguracje, w tym warunki zastosowania. Poniżej znajduje się fragment z urządzenia samochodowego Cuttlefish, w którym użyto konfiguracji domyślnych, urządzenia magistrali i Bluetooth A2DP. 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 dostępnych do debugowania parametru CAP framework znajdziesz w tym narzędziu:

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

Aby można było korzystać z tego narzędzia, producenci OEM muszą zezwolić na dostrajanie na urządzeniu. Aby sprawdzić, czy urządzenie umożliwia dostrajanie, użyj tego polecenia:

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

W Androidzie 15 i starszych wersjach 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 w zależności od typu obrazu kompilacji (lub użyj innego pliku w przypadku wersji lub debugowania w przypadku starszej kompilacji). Wersja produkcyjna ustawia wartość TuningAllowed na false bez portu gniazda (gniazda są w niej zabronione). W przypadku kompilacji inżynieryjnych i userdebug ustawia się wartość true z używanym portem gniazda. Pamiętaj, że jest to plik, do którego odwołuje się audio_policy_pfw_toplevel. Narzędzie do zdalnego przetwarzania musi być też uwzględnione w pliku producenta lub pliku kompilacji urządzenia:

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

Należy też uwzględnić odpowiednie zasady SELinux, które zezwalają na gniazda. Działa to tylko w trybie debugowania, ponieważ tryb wydania wyraźnie zabrania używania gniazd:

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

Migracja CAP w Androidzie 16

W związku z dużymi zmianami wprowadzonymi przez silnik AIDL audio HAL CAP i poprzednie wersje należy wziąć pod uwagę różne scenariusze przejścia na nowe urządzenie. W tej sekcji omawiamy najważniejsze scenariusze przejścia i podajemy rekomendacje dotyczące prac związanych z 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ć wprowadzane na rynek z Androidem 16 lub nowszym w vendor. Oznacza to, że musi udostępniać konfigurowalną konfigurację silnika zasad audio za pomocą interfejsu AIDL audio HAL. Konfigurację silnika Device CAP należy skopiować z przykładów. W przypadku partycji vendor nie powinna występować definicja domeny PfW CAP.

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

Przykładem jest wirtualne urządzenie Cuttlefish dla branży motoryzacyjnej, które zostało wprowadzone w tym zgłoszeniu zmiany. Możesz się do niego odwoływać, aby uzyskać wymagane pliki, reguły kompilacji i pliki make, które są potrzebne do skonfigurowania wymaganych plików konfiguracyjnych. Działa to z ładowarkami dostępnymi w domyślnym interfejsie HAL audio AIDL.

Scenariusz 2. Nowe urządzenie z Androidem 16 lub nowszym, poprzednie urządzenie z CAP

Nowe urządzenie musi być wprowadzane na rynek z Androidem 16 lub nowszym w vendor. Jednak ponieważ producent OEM ma konfigurację silnika CAP, której można użyć, będzie chciał wykorzystać ją jako punkt wyjścia (lub w pełni ją ponownie wykorzystać). Wersja konfiguracji CAP w AIDL ma pewne zmiany w porównaniu z wersją na Androida 15 i starsze, więc dostawca musi przekonwertować istniejącą konfigurację na AIDL. Więcej informacji o zmianach wymaganych w przypadku Androida 16 i starszych wersji znajdziesz w rozdziale Strategie dotyczące produktów. Ogólnie rzecz biorąc, platforma audio wykrywa i wczytuje konfigurację CAP w taki sam sposób jak w scenariuszu 1.

Scenariusz 3. Aktualizacja istniejącego urządzenia z CAP do Androida 16 tylko na partycji systemowej

W tym scenariuszu partycja vendor zawiera konfigurację CAP urządzenia z Androidem w wersji 15 lub starszej oraz definicję domeny CAP PfW. Partycja vendor pozostaje bez zmian, więc nadal korzysta z HIDL HAL. Framework działa zgodnie ze scenariuszem Androida 15 i starszych wersji i wczytuje wszystkie konfiguracje związane z CAP z partycji vendor.

Scenariusz 4. Urządzenie z Androidem 15 z CAP

W Androidzie 15 protokół CAP nie był obsługiwany w AIDL, więc niektórzy dostawcy wypuścili nowe urządzenia z AIDL Audio HAL i CAP, który był ładowany przez platformę audio. Ten tryb hybrydowy był nieoficjalny, ale jest dostępny w Androidzie 16. Pamiętaj, że tego trybu nie należy używać do wprowadzania na rynek nowych urządzeń z Androidem 16, ale raczej do umożliwienia aktualizacji istniejących urządzeń z Androidem 15 do Androida 16 (aktualizacja partycji system).

Framework audio wykrywa konfigurację audio AIDL HAL bez konfiguracji CAP. W przypadku konfiguracji CAP usługa zasad audio (framework audio) wraca do wczytywania konfiguracji CAP z vendorpartycji. W tym przypadku zarówno definicja domeny PfW CAP, jak i konfiguracja CAP urządzenia muszą być wczytywane z partycji vendor.

Podsumowanie migracji CAP

W tabeli poniżej znajdziesz podsumowanie zgodnych konfiguracji systemów i dostawców oraz wymagań dotyczących konfiguracji CAP: