Konfigurierbare Audiorichtlinien-Engine

In Android 14 nutzt das Android Automotive Operating System (AAOS) die Engine für die konfigurierbare Audio-Richtlinie (Configurable Audio Policy, CAP) für die Verwaltung von Audio im Auto in der primären Audiozone. Konkret ermöglicht die CAP-Engine AAOS, nur das Audio-Routing, nur die Lautstärke oder sowohl das Routing als auch die Lautstärke gleichzeitig zu steuern. Mit den folgenden Flags kann das Verhalten gesteuert werden:

• Verwenden Sie das Flag useCoreAudioVolume, um die Verwaltung des CAP-Volumens zu aktivieren. Wenn dieser Wert true ist, verwendet der Car Audio-Dienst Audio Manager-APIs, um die Lautstärkegruppen zu verwalten.

• Verwenden Sie das Flag useCoreAudioRouting, um die Verwaltung des CAP-Audio-Routings zu aktivieren. Wenn dieser Wert true ist, verwendet der Car Audio-Dienst das konfigurierbare Audio-Policy-Routing, um das Audio-Routing zu verwalten.

Die Audio-Richtlinien-Engine wird in Android standardmäßig in Form der Standard-Audio-Richtlinien-Engine unterstützt.

Hintergrund

Die CAP-Engine basiert auf dem Parameter-Framework von Intel, einem Plug-in-basierten und regelbasierten Framework für die Verarbeitung von Parametern. Für die Android-Audioverwaltung wurde mit der CAP-Engine die Möglichkeit eingeführt, Regeln für XML-Dateien zu definieren, um Folgendes anzugeben:

• Audioproduktstrategie
• Regeln für die Auswahl des Audioausgabegeräts
• Regeln für die Auswahl von Audioeingabegeräten
• Regeln zum Verwalten von Lautstärke und Stummschaltung sowie die Lautstärketabellen

CAP-Initialisierung vor Android 16

Die folgende Abbildung zeigt einen allgemeinen Überblick über die konfigurierbare Verwaltung der Audio-Richtlinien-Engine ab Android 6:

Abbildung 1: Konfigurationsverwaltung für die CAP-Engine ab Android 6.

Wie in der Abbildung dargestellt, wird die CAP-Engine-Konfiguration vom Audio Policy Service abgerufen, indem die Informationen aus der audio_policy_engine_configuration.xml-Datei in der Partition vendor geparst werden. In der Konfigurationsdatei des CAP-Moduls wird das in audio_policy_engine_configuration.xsd definierte Schema verwendet, um die erforderlichen Informationen abzurufen. audio_policy_engine_configuration.xml ist ein Beispiel für die Automobilbranche. Ähnliche Beispiele für andere Formfaktoren finden Sie im Ordner frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

Das folgende Bild zeigt detailliertere Informationen dazu, wie konfigurierbare Informationen zur Audio-Richtlinien-Engine in den Audio-Richtliniendienst geladen werden. In diesem Fall lädt das Parameter-Framework die Struktur und die Einstellungen aus den XML-Dateien.

Abbildung 2: CAP-Informationen, die in den Audio-Richtliniendienst geladen werden.

CAP-Strukturdateien in Android 15 und niedriger

Um die Struktur und die Einstellungen abzurufen, liest der Audio Policy Service die Datei ParameterFrameworkConfigurationPolicy.xml. Die Strukturinformationen werden über den Speicherort der Strukturdeskriptordatei referenziert:

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

Dies verweist auf Strukturinformationen in der Datei:

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

Eine Skelettstruktur ist in Android verfügbar. Für die Strukturinformationen sind die Informationen zur Produktstrategiestruktur erforderlich. Daher bietet Android das buildStrategiesStructureFile.py Generierungstool an, mit dem Informationen aus der verfügbaren XML-Datei für die Produktstrategie generiert werden können. Darauf kann über die genrule-Standardeinstellung buildstrategiesstructurerule verwiesen werden:

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

Dabei ist audio_policy_engine_configuration_files der Pfad zu den Konfigurationsdateien der Audio Policy Engine. In diesem Beispiel für die Automobilbranche wird auf die Konfigurationsdateien für die Audioprichtlinie im Ordner „automotive“ verwiesen. Weitere Beispiele zeigen, wie Sie einen Build so konfigurieren, dass die Dateien in die Vendor-Partition des Geräts übertragen werden.

CAP-Einstellungsdateien in Android 15 und niedriger

Ähnlich wie bei der Struktur werden die Einstellungsinformationen, die Regeln und Werte der Parameter darstellen, in der Datei ParameterFrameworkConfigurationPolicy.xml so referenziert:

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

Android bietet auch Build-Tools, mit denen diese Informationen anhand der Konfiguration der Audio-Policy-Engine und der Parameter-Framework-Dateien generiert werden können. Weitere Informationen finden Sie unter Konfigurationen.

AIDL-Audio-HAL-CAP-Initialisierung

Ab Android 16 wird die AIDL Audio HAL API-Definition um die Audio Policy Engine-Konfigurationen AudioHalCapConfiguration.aidl erweitert. Die folgende Abbildung zeigt eine allgemeine Übersicht über die Konfigurationsverwaltung der CAP-Engine in Android 16:

Abbildung 3: Konfigurationsverwaltung für die CAP-Engine ab Android 16

Der Audio Policy Service ruft die CAP-Engine-Informationen direkt über die AIDL Audio HAL APIs ab, anstatt die Informationen aus XML-Dateien in der Anbieterpartition des Geräts zu parsen.

In dieser Konfiguration wird die Struktur des Parameter-Frameworks weiterhin von der CAP-Engine auf der Audio-Serverseite geladen.

Abbildung 4: CAP-Engine-Struktur.

In jedem Fall muss die Konfiguration die Informationen zu den Produktstrategien, Volumengruppen und Kriterien vollständig angeben.

Die folgende Abbildung bietet einen allgemeinen Überblick über die AIDL-Audio-HAL-APIs, die vom Audio Policy Service verwendet werden, um die CAP-Engine-Konfiguration abzurufen:

Abbildung 5: AIDL-Audio-HAL-APIs.

Bei dieser Einrichtung ruft der Audio Policy Service die folgenden Informationen von der AIDL-Audio-HAL ab:

• Konfiguration
• Strategien
• Bände
• Kriterien
• Einstellungen

Standardmäßiger AIDL-Audio-HAL-Loader

Um den Übergang von HIDL zu AIDL zu erleichtern, bietet das Standard-Audio-AIDL-Audio-HAL einen XML-CAP-Engine-Loader. Anbieter können diesen Loader direkt verwenden, indem sie ihren Audio-HAL mit dem Standard-Audio-HAL erweitern oder auf die libaudioserviceexampleimpl-Bibliothek verweisen.

Der Standard-AIDL-Audio-HAL-Loader verwendet audio_policy_engine_configuration.xml, um die folgenden Informationen abzurufen:

• Konfiguration
• Strategien
• Bände
• Kriterien

Die Strukturinformationen werden aus der Datei PolicyConfigurableDomains.xml abgerufen. Der Hauptunterschied zum vorherigen Mechanismus besteht darin, dass die Strukturinformationen auch vom AIDL-Audio-HAL anstelle des Parameter-Frameworks im Audio Policy Service abgerufen werden.

Anbieter können mit dem Tool domaingeneratorpolicyrule die konfigurierbaren Domains anhand der Informationen aus der Konfiguration der Audio-Richtlinien-Engine generieren. Das Beispiel für ein virtuelles Cuttlefish-Gerät für die Automobilbranche kann als Referenz verwendet werden.

Struktur in der AIDL-Konfiguration

In Android 16 und höher ruft der Audio-Richtliniendienst die Strukturinformationen ab, indem er die Datei ParameterFrameworkConfigurationCap.xml liest und parst.

). Insbesondere werden die Informationen aus der Datei mit der Strukturbeschreibung abgerufen:

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

Das Framework legt die erforderlichen Dateien im Ordner /etc/parameter-framework/ mit den benötigten Informationen ab.

Die Struktur stellt die Parameter dar, die gesteuert werden sollen. Daher sollte in der Konfiguration oder in den Domains darauf verwiesen werden. Dazu muss in der AIDL-Engine-Konfiguration ein vordefinierter Name für die Parameter verwendet werden. Für die Produktstrategien werden die Strukturen in CapProductStrategies.xml konfiguriert.

Standardmäßige Produktstrategien

Die Produktstrategien beginnen mit dem Präfix STRATEGY_ und basieren auf den Standardeinstellungen der Standard-Engine:

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

Dieses Format wurde bereitgestellt, um den Übergang von HIDL zu AIDL für Geräte zu erleichtern, die Standardstrategien verwenden. Diese Formatänderung hat einige Auswirkungen auf die vorhandenen Dateien (z. B. PfW, XML), die zum Konfigurieren der Engine verwendet werden. Insbesondere alle Verweise auf die Produktstrategie sollten so geändert werden, dass die neuen Namen verwendet werden, z. B.:

Vom OEM definierte Produktstrategien

Mit der konfigurierbaren Engine können OEMs die Definition der Produktstrategien ändern. Um dies weiterhin zu unterstützen, enthält die Datei mit der Produktstrategie CapProductStrategies.xml auch 40 anbietererweiterbare Produktstrategien von vx_1000 bis vx_1039. Alle Anbietererweiterungen müssen mit dem Präfix vx_ beginnen und mit einer Zahl fortgesetzt werden, die die Produktstrategie-ID in der AIDL-Audio-HAL-Produktstrategiedefinition darstellt. Die restlichen Definitionen (z. B. Audioattributgruppen, Name) werden aus dem AudioHALProductStrategy-Objekt in der Konfiguration der Audio-HAL-Engine abgerufen.

Ähnlich wie bei den Standardproduktstrategien müssen die vom Anbieter definierten OEM-Referenzen auch zwischen der Nicht-AIDL-Konfiguration und der AIDL-Konfiguration angepasst werden, z. B.:

Produktstrategien

Mit Produktstrategien können Sie anpassen, wie Audiostreams kategorisiert und gruppiert werden. Dadurch können Sie Audio-Geräte flexibler konfigurieren, z. B. wie sie weitergeleitet werden und wie ihre Lautstärke verwaltet wird. Jede Produktstrategie kann eine oder mehrere Audioattributgruppen haben, die Streams identifizieren, die mit dieser Produktstrategie verknüpft werden sollen. Diese Gruppen von Audioattributen ermöglichen eine detailliertere Kategorisierung von Audioinhalten und können eine Mischung der folgenden Typen sein:

• Verwendungsarten beschreiben, warum ein Ton abgespielt wird (z. B. Medien, Benachrichtigung, Anruf).
• Inhaltstypen beschreiben, was wiedergegeben wird (z. B. Musik, Sprache, Video, Sonifizierung).
• Flag-Typen definieren unterschiedliche Verhaltensweisen oder Anfragen in Bezug auf den Stream.
• Tags-Typen unterstützen eine beliebige Liste von Anbieter-Stringwerten.
  • Jeder String muss mit VX_ beginnen, gefolgt von einem alphanumerischen String (z. B. 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>

In diesem Auszug sehen Sie ein Beispiel für eine Produktstrategie, die in Auto-Emulatoren verwendet wird. Es enthält zwei Audioattribute mit den Werten „audio usage media“ und „game“. Diese Produktstrategie entspricht dem MUSIC-Audiokontext, der im Car Audio Service verwendet wird. Eine solche Übereinstimmung ist jedoch nicht erforderlich. Einer der Hauptvorteile für OEMs, die CAP zusammen mit Android verwenden, ist die Möglichkeit, flexiblere Definitionen für die Audiogruppierung zu erstellen.

Volume-Gruppen

Außerdem muss jeder Gruppe von Audioattributen eine Lautstärkegruppe zugeordnet sein. Diese Lautstärkegruppe ist mit allen Streams verknüpft, die den Audioattributen der Audioattributgruppe entsprechen. Die Beispielstrategie für Musikprodukte im Abschnitt Produktstrategien hat die Volumengruppe media. Die Definition der Media-Volumengruppe lautet so:

<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>

In dieser Definition enthält die Volumegruppe Folgendes:

• Gruppenname
• Minimaler Gruppenindex
• Maximaler Gruppenindex
• Kurven für Volume-Gruppen

Die Kurven der Lautstärkegruppe enthalten eine punktweise Zuordnung zwischen dem Index der Lautstärkegruppe und der Lautstärkeerhöhung in Millibel. Die angegebenen Punkte werden verwendet, um die am besten passende Verstärkung linear zu interpolieren, wenn die Lautstärke angepasst wird. Jede Lautstärkegruppenkurve ist einer Gerätetypkategorie zugeordnet (z. B. Headset, Lautsprecher, externe Medien).

Die Lautstärkegruppe verwaltet die Lautstärke für die Streams, die Teil der Gruppe mit Audioattributen sind. Wenn beispielsweise ein Stream mit Audioattributen, die Musik oder Spiele enthalten, gestartet wird, wird der zuletzt festgelegte Lautstärkeindex für die Media-Lautstärkegruppe verwendet. In diesem Fall wird die entsprechende Kurve für die Geräteklasse basierend auf dem ausgewählten Gerät ausgewählt und die entsprechende Verstärkung wird beim Starten des Streams festgelegt.

Konfigurationen

In der CAP-Engine werden Konfigurationen verwendet, um die Bedingungen oder Regeln zu definieren, die das Verhalten des Audiosignals bestimmen. Diese Konfigurationen werden zur Laufzeit ausgewertet, um die entsprechenden Regeln auszuwählen, die je nach aktuellem Status des Audiosystems angewendet werden sollen.

Wie in Abbildung 5 dargestellt, enthält die API mehrere Domains. Ziel jeder Domain ist es, die Logik in kleinere Routing-Probleme aufzuteilen, die gelöst werden müssen (z. B. Gerät 1, Gerät 2).

Jede Domain hat Konfigurationen und jede Konfiguration hat eine Reihe von Regeln. Regeln werden anhand von Kriterien erstellt, die von AudioPolicyManager bereitgestellt werden:

• Audiomodus
• Verfügbare Ein- und Ausgabegeräte
• Adressen der verfügbaren Ein- und Ausgabegeräte
• Verwendung für
  • Medien
  • Kommunikation
  • Aufnahme
  • Dock
  • System
  • HDMI-Systemaudio
  • Codierter Surround-Sound
  • Vibration bei Klingeln

Jede Domain enthält Konfigurationen, die die Regeln für das Verhalten festlegen. Die Reihenfolge der Konfiguration ist wichtig. Achten Sie darauf, dass die Konfigurationen in der erforderlichen Reihenfolge vorliegen. Nachdem die Regeln für eine Konfiguration validiert wurden, wird die Konfiguration ausgewählt.

Der folgende Code zeigt einen Auszug aus einer Parameter-Framework-Datei, mit der die erforderliche XML-Datei zum Konfigurieren konfigurierbarer Domains generiert werden kann:

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

Die Domain DeviceForProductStrategies definiert, wie verschiedene Regeln bei der Geräteauswahl für Produktstrategien angewendet werden sollen. Die blauen Teile beschreiben die Regeln, die berücksichtigt werden sollten, und der grüne Teil ist die angewendete Konfiguration. Dieses Beispiel enthält die folgenden Konfigurationen:

• Bluetooth-A2DP-Gerät für die Musikproduktstrategie auswählen (ID 1000, vx_1000)
  • Bei Verwendung für Medien wird A2DP nicht ausgeschlossen.
  • Wenn für die Kommunikation verwendet, ist nicht BT SCO
  • Wenn Geräte verfügbar sind, füge BT A2DP hinzu.
• Busgerät auswählen
  • Ob Bus-Geräte verfügbar sind
  • Wenn die Adresse BUS00_MEDIA lautet
• Andernfalls Standardausgabegerät auswählen

Um die entsprechende konfigurierbare XML-Datei für die Richtlinien-Engine zu generieren, führen Sie die PFW-Dateien (Parameter Framework) über das Build-System aus. Definieren Sie dazu eine Build-Regel mit den folgenden Schritten:

1. Erstellen Sie in der Datei Android.bp eine Dateigruppe für die Datei:

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

2. Fügen Sie die Datei anderen PfW-Dateien hinzu (falls vorhanden).

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

3. Erstellen Sie die entsprechende Regel zur Generierung von Domains:

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

   Dabei ist domaingeneratorpolicyrule eine Generierungsregel, die vom Framework bereitgestellt wird, um die Datei PolicyConfigurableDomains.xml zu generieren. Die anderen Quelldateien (scrs), die in den Regeln zur Domain-Generierung enthalten sind, sind:

   Quelle	Beschreibung
   audio_policy_pfw_toplevel	Konfigurationsdatei für das Parameter-Framework auf oberster Ebene.
   audio_policy_pfw_structure_files	Dateien mit der Struktur zur Generierung von Domains, die zum Generieren der Konfigurationsdateien verwendet werden.
   audio_policy_engine_criterion_types	XML-Datei mit Kriterientypen, in der die bei der Generierung verwendeten Kriterien beschrieben werden.
   edd_files	Liste der Dateien für einzelne Domains (jede enthält ein einzelnes <ConfigurableDomain>-Tag).

Nachdem die Generierungsregel im Build ausgeführt wurde, wird die PolicyConfigurableDomains.xml mit allen Domains generiert. Im Folgenden sehen Sie einen Auszug aus der generierten Datei, in der die Regeln aus dem Beispiel für PfW verwendet werden:

---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>

CAP-Debugging

Mit dem Befehl remote-process können Sie die CAP-Konfigurationen ausgeben:

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

Hier werden alle Domains und Konfigurationen einschließlich der Anwendbarkeitsbedingungen angezeigt. Das Folgende zeigt einen Auszug aus dem Cuttlefish-Automobilgerät mit den Bluetooth A2DP-, Busgeräte- und Standardkonfigurationen. Siehe Konfigurationen:

- 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

Weitere Informationen zu anderen Befehlen, die zum Debuggen des CAP-Parameterframeworks verfügbar sind, finden Sie in diesem Tool:

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

Damit das Tool verwendet werden kann, müssen OEMs die Optimierung auf dem Gerät zulassen. Mit dem folgenden Befehl können Sie prüfen, ob das Gerät die Optimierung zulässt:

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

In Android 15 und niedriger kann die Datei anders sein. Verwenden Sie daher den folgenden Befehl:

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

Die Datei sollte TuningAllowed="true" zusammen mit dem entsprechenden Serverport enthalten:

<?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>

Diese Datei wird automatisch generiert, je nach Art des Build-Images. Bei Legacy-Builds kann auch eine andere Datei für release oder debug verwendet werden. Bei einem Release-Build wird TuningAllowed auf false gesetzt, ohne dass ein Socket-Port verwendet wird (Sockets sind in Release-Builds nicht zulässig). Bei Engineering- und userdebug-Builds wird der Wert auf true mit dem verwendeten Socket-Port festgelegt. Beachten Sie, dass dies die Datei ist, auf die in audio_policy_pfw_toplevel verwiesen wird. Das Tool für Remote-Prozesse muss auch in der Make-Datei des Geräts oder in der Build-Datei enthalten sein:

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

Die entsprechende SELinux-Richtlinie zum Zulassen von Sockets muss ebenfalls enthalten sein. Das funktioniert nur im Debug-Modus, da Sockets im Release-Modus ausdrücklich nicht zulässig sind:

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

CAP-Migration in Android 16

Angesichts der großen Änderungen, die durch die AIDL-Audio-HAL-CAP-Engine und frühere Versionen eingeführt wurden, gibt es verschiedene Geräteübergangsszenarien, die Sie berücksichtigen sollten. In diesem Abschnitt werden die wichtigsten Übergangsszenarien behandelt und Empfehlungen für die erforderlichen Arbeiten zur Aktivierung der CAP-Engine-Konfiguration gegeben.

Szenario 1: Neues Gerät mit Android 16 oder höher, keine vorherige Quelle für die Geräte-CAP-Konfiguration

Auf einem neuen Gerät muss bei Markteinführung Android 16 oder höher auf der Partition vendor installiert sein. Das bedeutet, dass die konfigurierbare Audio Policy Engine-Konfiguration über die AIDL-Audio-HAL-Schnittstelle verfügbar gemacht werden muss. Die Konfiguration der CAP-Engine des Geräts sollte aus den Beispielen kopiert werden. In der Partition vendor darf keine PfW-CAP-Domaindefinition vorhanden sein.

Das für das Gerät verwendete System-Image ist Android 16 oder höher. Das Audio-Service-Framework ermittelt die CAP-Konfiguration über die AIDL-Audio-HAL-Schnittstelle. Es initialisiert PfW also mit der PfW-CAP-Domänendefinition aus dem System-Image und lädt die über AIDL empfangene Geräte-CAP-Konfiguration.

Ein Beispiel finden Sie im virtuellen Cuttlefish-Gerät für die Automobilbranche, das in dieser Änderung eingeführt wurde. Dort finden Sie die erforderlichen Dateien, Build-Regeln und Makefiles, die zum Einrichten der erforderlichen Konfigurationsdateien benötigt werden. Dies funktioniert mit den Loadern, die im Standard-AIDL-Audio-HAL bereitgestellt werden.

Szenario 2: Neues Gerät mit Android 16 oder höher, von einem vorherigen Gerät mit CAP

Auf einem neuen Gerät muss bei Markteinführung Android 16 oder höher auf der Partition vendor installiert sein. Da der OEM jedoch über eine nutzbare CAP-Engine-Konfiguration für das Gerät verfügt, möchte er diese als Ausgangspunkt verwenden (oder vollständig wiederverwenden). Die AIDL-Version der CAP-Konfiguration weist einige Änderungen im Vergleich zur Version für Android 15 und niedriger auf. Der Anbieter muss die vorhandene Konfiguration also in AIDL konvertieren. Informationen zu Änderungen zwischen Android 16 und niedrigeren Versionen finden Sie im Abschnitt Produktstrategien. Im Allgemeinen erkennt und lädt das Audio-Framework die CAP-Konfiguration auf dieselbe Weise wie in Szenario 1.

Szenario 3: Vorhandenes Gerät mit CAP wird auf Android 16 aktualisiert, wobei nur die Systempartition aktualisiert wird

In diesem Szenario enthält die vendor-Partition die Geräte-CAP-Konfiguration für Android 15 und niedriger sowie die PfW-CAP-Domänendefinition. Die vendor-Partition wird nicht geändert, sodass sie weiterhin HIDL HAL verwendet. Das Framework folgt dem Szenario für Android 15 und niedriger und lädt die gesamte CAP-bezogene Konfiguration aus der Partition vendor.

Szenario 4: Vorhandenes Gerät, das mit Android 15 mit CAP veröffentlicht wurde

CAP wurde in AIDL unter Android 15 nicht unterstützt. Daher haben einige Anbieter neue Geräte mit AIDL Audio HAL und CAP veröffentlicht, die vom Audio-Framework geladen wurden. Dieser Hybridmodus war inoffiziell, ist aber in Android 16 enthalten. Dieser Modus darf nicht für die Veröffentlichung neuer Geräte mit Android 16 verwendet werden, sondern nur, um vorhandene Geräte mit Android 15-Anbieter auf Android 16 zu aktualisieren (das system-Partitionsupdate).

Das Audio-Framework erkennt die AIDL-Audio-HAL-Audiokonfiguration ohne die CAP-Konfiguration. Bei der CAP-Konfiguration greift der Audio Policy Service (Audio-Framework) darauf zurück, die CAP-Konfiguration aus der Partition vendor zu laden. In diesem Fall müssen sowohl die PfW-CAP-Domänendefinition als auch die Geräte-CAP-Konfiguration von der vendor-Partition geladen werden.

Zusammenfassung der CAP-Migration

In der folgenden Tabelle sind die kompatiblen System- und Anbieterkonfigurationen sowie die Anforderungen an die CAP-Konfiguration zusammengefasst: