Konfigurowalny mechanizm zasad dotyczących dźwięku

W Androidzie 14 system operacyjny Android Automotive (AAOS) wykorzystuje mechanizm konfigurowalnych zasad audio (CAP) do zarządzania dźwiękiem w samochodzie w głównej strefie audio. W Androidzie 16 silnik CAP jest dostępny we wszystkich strefach audio, w tym w strefie głównej i wszystkich strefach pasażerów (patrz Routing dźwięku w wielu strefach). 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 sterowania działaniem można używać tych flag:

• Aby włączyć zarządzanie głośnością CAP, użyj flagi useCoreAudioVolume. 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

Silnik CAP jest oparty na strukturze parametrów firmy Intel, która jest opartą na wtyczkach i regułach strukturą do obsługi parametrów. W przypadku zarządzania dźwiękiem na Androidzie mechanizm 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 widać na ilustracji, konfiguracja silnika CAP jest uzyskiwana przez usługę zasad audio poprzez analizowanie informacji z plikuaudio_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 z 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 usłudze zasad dotyczących dźwięku.

Pliki struktury CAP w Androidzie 15 i starszych wersjach

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

Szkielet struktury jest dostępny 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 to pliki konfiguracji silnika zasad audio. Ten przykład dotyczący motoryzacji 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 wersjach

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 mechanizmu zasad audioAudioHalCapConfiguration.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 AIDL Audio HAL API, zamiast analizować informacje z plików XML w partycji dostawcy urządzenia. Ta konfiguracja usuwa z frameworka analizowanie XML-a. Ponadto interfejs HAL audio nie musi analizować kodu XML. Zamiast tego musi udostępniać dane konfiguracyjne za pomocą AIDL, które można pobrać z dowolnego źródła. Dla wygody domyślna implementacja AOSP warstwy HAL audio zawiera konwerter XML (EngineConfigXmlConverter.cpp), który analizuje standardową konfigurację XML i wypełnia natywnie obiekty AIDL AudioHalEngineConfig.

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 AIDL audio HAL, które są używane przez usługę zasad audio do uzyskiwania konfiguracji mechanizmu CAP:

Rysunek 5. Interfejsy API AIDL audio HAL.

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

• Konfiguracja
• Strategie
• Woluminy
• Kryteria
• Ustawienia

Domyślny moduł wczytujący AIDL Audio HAL

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

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

• Konfiguracja
• Strategie
• Woluminy
• Kryteria

Informacje o strukturze są pobierane z pliku PolicyConfigurableDomains.xml. 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. Możesz się posłużyć przykładem urządzenia wirtualnego 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 folderze /etc/parameter-framework/ 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 z domyślnych strategii. 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_, po którym następuje liczba reprezentująca 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.:

Routing audio w wielu strefach

W Androidzie 16 i nowszych schemat CAP jest zintegrowany z definicjami dźwięku w wielu strefach w Androidzie Automotive.

W silniku CAP opcjonalny atrybut zoneId w elemencie ProductStrategy służy jako kryterium dopasowania pochodzenia, które filtruje strumienie na podstawie strefy źródłowej, z której pochodzi odtwarzanie.

1. Dopasowywanie pochodzenia (zoneId): gdy CarAudioService rejestruje mapowania użytkownika na strefę za pomocą setProductStrategiesZoneIdForUser, silnik CAP używa zoneId jako parametru dopasowywania, aby wybrać odpowiedni ProductStrategy dla strumieni w danej strefie.
2. Routing do miejsca docelowego (punkty końcowe urządzenia): gdy są zgrupowane w strategie, konfiguracja routingu audio określa mapowanie między tymi strategiami produktu a urządzeniami wyjściowymi, np. urządzeniem magistrali, takim jak bus100_media_out w przypadku strefy 1.

Strategie dotyczące produktów w <ProductStrategies> mogą określać zoneId odpowiadające strefie zajętości (kierowcy lub pasażera):

<ProductStrategies>
    <!-- General Primary Zone Media -->
    <ProductStrategy name="music_primary" id="1000" zoneId="0">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_primary">
            <Attributes>
                <Usage value="AUDIO_USAGE_MEDIA"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>

    <!-- Secondary Zone Media Endpoint -->
    <ProductStrategy name="music_rear_seat" id="1002" zoneId="1">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_rear">
            <Attributes>
                <!-- Rear seat entertainment attribute mapping via bundle tags -->
                <Usage value="AUDIO_USAGE_MEDIA"/>
                <Bundle key="VX_OEM" value="REAR_SEAT"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>
</ProductStrategies>

Strategie dotyczące produktów

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 (muzyka, mowa, wideo, sonifikacja).
• Typy flag określają różne zachowania lub żądania w odniesieniu do strumienia. Pamiętaj, że wiele flag musi być podanych jako ciąg znaków rozdzielonych spacjami, np. <Flags value="AUDIO_FLAG_SCO AUDIO_FLAG_BEACON"/>.
• Typy tagów obsługują dowolną listę wartości ciągów tekstowych dostawcy. Aby zdefiniować tag w konfiguracji, musisz użyć elementu <Bundle>.
  • Każdy klucz pakietu musi zaczynać się od prefiksu VX_, po którym następuje ciąg alfanumeryczny, np. <Bundle key="VX_OEM" value="REAR_SEAT"/>.

<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 produktu, która jest stosowana w przypadku emulatorów samochodowych. Zawiera 2 atrybuty dźwięku: „audio usage media” (wykorzystanie dźwięku w mediach) i „audio usage game” (wykorzystanie dźwięku w grze). Pamiętaj, że strategie dotyczące produktów dostawcy zdefiniowane w pliku XML muszą wyraźnie zawierać atrybut id (np. id="1008" w powyższym fragmencie kodu), który jest bezpośrednio mapowany na standardowy identyfikator strategii wymagany przez Audio HAL. Jeśli dostawca id zostanie pominięty, konfiguracja podczas analizowania wywoła niebezpieczne zachowanie rezerwowe.

Ta strategia produktu jest zgodna z MUSIC kontekstem audio używanym w usłudze audio w samochodzie, ale nie jest to wymagane. Jednym z głównych narzędzi dla producentów OEM korzystających z CAP w Androidzie jest możliwość bardziej elastycznego definiowania grup audio.

Grupy tomó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ę woluminów media, a definicja grupy woluminów 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 interpolacji liniowej 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 rozpoczęciu strumienia.

Konfiguracje

W mechanizmie CAP konfiguracje służą do określania warunków lub reguł, które decydują o tym, 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 pokazano na rysunku 5, interfejs API zawiera wiele domen, a celem każdej z nich jest podzielenie logiki na mniejsze problemy z routingiem do rozwiązania (np. urządzenie 1, urządzenie 2).

Każda domena ma konfiguracje, a każda konfiguracja ma zestaw reguł. Reguły są tworzone 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
  • Nagrywanie
  • Zadokuj
  • System
  • Dźwięk systemowy 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 to 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 na potrzeby strategii dotyczącej produktu muzycznego (ID 1000, vx_1000).
  • Jeśli jest używany do przesyłania multimediów, nie wyklucza A2DP.
  • Jeśli jest używany do komunikacji, nie jest to BT SCO.
  • Jeśli dostępne urządzenia obsługują 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 stosowania. 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 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). W kompilacji do publikacji wartość TuningAllowed jest ustawiana 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, aby zezwolić 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

Biorąc pod uwagę duże zmiany wprowadzone przez silnik CAP w warstwie HAL audio AIDL 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 działań, które należy podjąć, 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ć dostarczane z Androidem 16 lub nowszym w vendor partycji. Oznacza to, że musi udostępniać konfigurację konfigurowalnego mechanizmu 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ą za pomocą AIDL.

Przykładem jest urządzenie wirtualne Cuttlefish dla motoryzacji, które zostało wprowadzone w tym wpisie. 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ć dostarczane z Androidem 16 lub nowszym w vendor partycji. Jednak ponieważ producent OEM ma konfigurację silnika CAP, której można użyć, będzie chciał wykorzystać ją jako punkt początkowy (lub w pełni ją ponownie wykorzystać). Wersja konfiguracji CAP w AIDL ma pewne zmiany w porównaniu z Androidem 15 i starszymi wersjami, więc dostawca musi przekonwertować istniejącą konfigurację na AIDL. W sekcji Strategie dotyczące produktów znajdziesz omówienie zmian wymaganych w przypadku Androida 16 i starszych wersji. 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, która obejmuje tylko partycję systemową

W tym scenariuszu partycja vendor zawiera konfigurację CAP urządzenia w Androidzie 15 i starszych wersjach 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 producenci wypuścili nowe urządzenia z AIDL Audio HAL i CAP, który był wczytywany 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).

Platforma audio wykrywa konfigurację audio AIDL HAL bez konfiguracji CAP. W przypadku konfiguracji CAP usługa zasad audio (platforma audio) wraca do wczytywania konfiguracji CAP z vendor. 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: