Konfigurierbare Audiorichtlinien-Engine

In Android 14 nutzt das Android Automotive Operating System (AAOS) die CAP-Engine (Configurable Audio Policy) für die Audioverwaltung im Auto in der primären Audiozone. Mit der CAP-Engine kann AAOS entweder nur das Audiorouting, nur die Audiolautstärke oder sowohl das Routing als auch die Lautstärke gleichzeitig steuern. Mit den folgenden Flags kann das Verhalten gesteuert werden:

• Verwenden Sie das Flag useCoreAudioVolume, um die CAP-Volumeverwaltung zu aktivieren. Wenn dieser Wert true ist, verwendet der Autoaudiodienst Audiomanager-APIs, um die Lautstärkegruppen zu verwalten.

• Mit dem Flag useCoreAudioRouting kannst du die CAP-Audio-Routing-Verwaltung aktivieren. Wenn dieser Wert true ist, verwendet der Autoaudiodienst das konfigurierbare Audiorichtlinien-Routing, um die Audioweiterleitung zu verwalten.

Die Audiorichtlinien-Engine wird auch in Android standardmäßig in Form der standardmäßigen Audiorichtlinien-Engine unterstützt.

Hintergrund

Die CAP-Engine basiert auf dem Parameter-Framework von Intel, einem Plug-in-basierten und regelbasierten Framework für die Parameterverwaltung. Insbesondere für die Audioverwaltung unter Android bietet die CAP-Engine die Möglichkeit, XML-Dateiregeln zu definieren, um Folgendes anzugeben:

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

CAP-Initialisierung vor Android 16

Die folgende Abbildung bietet einen allgemeinen Überblick über die Konfigurationsverwaltung der konfigurierbaren Audiorichtlinien-Engine ab Android 6:

Abbildung 1: Konfigurationsverwaltung der CAP-Engine ab Android 6

Wie in der Abbildung dargestellt, wird die CAP-Engine-Konfiguration vom Audiorichtliniendienst abgerufen, indem die Informationen aus der audio_policy_engine_configuration.xml-Datei in der Partition vendor geparst werden. In der Konfigurationsdatei der CAP-Engine 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/.

Die folgende Abbildung zeigt detailliertere Informationen dazu, wie konfigurierbare Informationen der Audiorichtlinien-Engine in den Audiorichtliniendienst 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 Dienst für Audiorichtlinien geladen werden.

CAP-Strukturdateien in Android 15 und niedriger

Der Audiorichtliniendienst liest die ParameterFrameworkConfigurationPolicy.xml-Datei, um die Struktur und die Einstellungen abzurufen. Hier wird über den Speicherort der Datei mit der Gebäudebeschreibung auf die Gebäudeinformationen verwiesen:

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

Dies verweist auf Strukturinformationen in der Datei:

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

Eine Skelettstruktur wird in Android bereitgestellt. Für die Strukturinformationen sind Informationen zur Struktur der Produktstrategie erforderlich. Daher stellt Android das buildStrategiesStructureFile.py Generierungstool bereit, mit dem Informationen aus der verfügbaren XML-Datei der Produktstrategie generiert werden können. Darauf kann über die genrule default buildstrategiesstructurerule verwiesen werden:

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

Dabei ist audio_policy_engine_configuration_files die Konfigurationsdatei der Audiorichtlinien-Engine. In diesem Beispiel für die Automobilbranche wird auf die Konfigurationsdateien der Audiorichtlinien im Ordner „automotive“ verwiesen. Weitere Beispiele zeigen, wie Sie einen Build so konfigurieren, dass die Dateien in die Anbieterpartition des Geräts gesendet werden.

CAP-Einstellungendateien 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 außerdem Build-Tools, mit denen diese Informationen anhand der Konfiguration der Audiorichtlinien-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 Konfigurationen der Audiorichtlinien-Engine AudioHalCapConfiguration.aidl erweitert. Die folgende Abbildung bietet einen allgemeinen Überblick über die CAP-Engine-Konfigurationsverwaltung ab Android 16:

Abbildung 3: Konfigurationsverwaltung der CAP-Engine ab Android 16

Der Audiorichtliniendienst 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 analysieren.

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

Abbildung 4: CAP-Engine-Struktur.

In jedem Fall müssen in der Konfiguration alle Informationen zu den Produktstrategien, Volumengruppen und Kriterien angegeben sein.

Die folgende Abbildung bietet eine allgemeine Übersicht über die AIDL Audio HAL APIs, die vom Audiorichtliniendienst zum Abrufen der CAP-Engine-Konfiguration verwendet werden:

Abbildung 5 AIDL-Audio-HAL-APIs

Bei dieser Konfiguration erhält der Dienst für Audiorichtlinien die folgenden Informationen von der AIDL-Audio-HAL:

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

Standard-AIDL-Audio-HAL-Ladeprogramm

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

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

• Konfiguration
• Strategien
• Bände
• Kriterien

Die Gebäudeinformationen 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 beim Audiorichtliniendienst abgerufen werden.

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

Struktur in der AIDL-Konfiguration

Unter Android 16 und höher ruft der Dienst für Audiorichtlinien die Strukturinformationen ab, indem er die ParameterFrameworkConfigurationCap.xml-Datei liest und analysiert. Insbesondere werden die Informationen aus der Strukturbeschreibungsdatei abgerufen:

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

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

Die Struktur stellt die Parameter dar, die gesteuert werden sollen. Daher sollten sie in der Konfiguration oder in den Domains referenziert werden. Dazu sollte 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.

Standardproduktstrategien

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 eingeführt, um den Übergang von HIDL zu AIDL für Geräte zu erleichtern, auf denen Standardstrategien verwendet wurden. Diese Formatänderung hat einige Auswirkungen auf die vorhandenen Dateien (z. B. PfW, XML), die zum Konfigurieren der Engine verwendet werden. Insbesondere sollten alle Verweise auf die Produktstrategie geändert werden, um die neuen Namen zu verwenden, 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 „Produktstrategie“ CapProductStrategies.xml 40 von Anbietern erweiterbare Produktstrategien von vx_1000 bis vx_1039. Alle Anbietererweiterungen müssen mit dem Präfix vx_ beginnen und mit einer Zahl fortgesetzt werden, die der Produktstrategie-ID in der Definition der AIDL-Audio-HAL-Produktstrategie entspricht. Die restlichen Definitionen (z. B. Audioattributgruppen, Name) werden aus dem Objekt AudioHALProductStrategy in der Audio HAL-Engine-Konfiguration abgerufen.

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

Produktstrategien

Mit Produktstrategien kannst du anpassen, wie Audiostreams kategorisiert und gruppiert werden. So können Audiogeräte flexibler konfiguriert werden, z. B. wie sie weitergeleitet und wie ihre Lautstärke verwaltet wird. Jede Produktstrategie kann eine oder mehrere Audioattributgruppen haben, mit denen Streams identifiziert werden, die mit dieser Produktstrategie verknüpft werden sollen. Diese Audioattributgruppen ermöglichen eine detailliertere Kategorisierung von Audioinhalten und können eine Mischung aus den folgenden Typen sein:

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

Dieser Auszug zeigt ein Beispiel für eine Produktstrategie, die in Autosimulatoren verwendet wird. Es enthält zwei Audioattribute mit den Werten „Medien“ und „Spiel“. Diese Produktstrategie entspricht dem MUSIC-Audiokontext, der im Audiodienst für Autos verwendet wird. Eine solche Übereinstimmung ist jedoch nicht erforderlich. Einer der Hauptvorteile für OEMs, die die CAP zusammen mit Android verwenden, ist die Möglichkeit, flexiblere Audiogruppierungsdefinitionen zuzulassen.

Volumegruppen

Außerdem muss jeder Gruppe von Audioattributen eine Lautstärkegruppe zugewiesen sein. Diese Lautstärkegruppe ist mit allen Streams verknüpft, die mit Audioattributen übereinstimmen, die zur Audioattributgruppe gehören. Die Beispielstrategie für Musikprodukte im Abschnitt Produktstrategien hat die Lautstärkegruppe media. Die Definition der Medienlautstärkegruppe lautet:

<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
• Gruppenminimimsindex
• Gruppenmaximalindex
• Kurven für Volumegruppen

Die Kurven der Lautstärkegruppe enthalten eine punktweise Zuordnung zwischen dem Index der Lautstärkegruppe und der Lautstärkeverstärkung in Millibel. Anhand der angegebenen Punkte wird der am besten passende Gewinn linear interpoliert, wenn das Volumen verwaltet wird. Jede Kurve der Lautstärkegruppe ist mit einer Kategorie des Gerätetyps verknüpft (z. B. Headset, Lautsprecher, externe Medien).

Die Lautstärkegruppe verwaltet die Lautstärke für die Streams, die zur Gruppe der Audioattribute gehören. Wenn beispielsweise ein Stream mit Audioattributen gestartet wird, die Musik oder ein Spiel enthalten, wird der zuletzt festgelegte Lautstärkeindex für die Medienlautstärkegruppe verwendet. In diesem Fall wird die entsprechende Kurve der Gerätekategorie 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 festlegen, wie sich der Ton verhalten soll. Diese Konfigurationen werden zur Laufzeit ausgewertet, um die entsprechenden Regeln auszuwählen, die je nach aktuellem Zustand 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 zu lösende Routingprobleme aufzuteilen (z. B. Gerät 1, Gerät 2).

Jede Domain hat Konfigurationen und jede Konfiguration hat eine Reihe von Regeln. Die Regeln basieren auf Kriterien, die von AudioPolicyManager bereitgestellt werden:

• Audiomodus
• Verfügbare Eingabe- und Ausgabegeräte
• Adressen verfügbarer Eingabe- 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 festlegen, die sich auf das Verhalten auswirken sollen. Die Reihenfolge der Konfigurationen ist wichtig. Achten Sie darauf, dass die Konfigurationen in der richtigen Reihenfolge sind. Nachdem die Regeln für eine Konfiguration validiert wurden, wird die Konfiguration ausgewählt.

Im folgenden Code ist ein Auszug aus einer Parameter-Framework-Datei zu sehen, 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

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

• Bluetooth-A2DP-Gerät für Musikproduktstrategie auswählen (ID 1000, vx_1000)
  • Wenn für Medien verwendet, schließt A2DP nicht aus
  • Wird für die Kommunikation verwendet, ist es kein BT-SCO.
  • Wenn verfügbare Geräte, BT A2DP angeben
• Busgerät auswählen
  • Wenn Busgeräte verfügbar sind
  • Wenn die Adresse BUS00_MEDIA ist
• Andernfalls Standardausgabegerät auswählen

Um die entsprechende XML-Datei für die konfigurierbare Policy 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 gegebenenfalls anderen PfW-Dateien hinzu.

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

3. Erstellen Sie die entsprechende Domaingenerierungsregel:

   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 vom Framework bereitgestellte Generierungsregel, mit der die PolicyConfigurableDomains.xml-Datei generiert wird. Die anderen Quelldateien (scrs), die in den Regeln zur Domaingenerierung enthalten sind, sind:

   Quelle	Beschreibung
   audio_policy_pfw_toplevel	Konfigurationsdatei des Parameter-Frameworks der obersten Ebene.
   audio_policy_pfw_structure_files	Domain Generation Structure-Dateien, mit denen die Konfigurationsdateien generiert werden.
   audio_policy_engine_criterion_types	XML-Datei mit Kriterientypen, die die bei der Generierung verwendeten Kriterien beschreiben.
   edd_files	Liste von Dateien für einzelne Domains, die jeweils ein einzelnes <ConfigurableDomain>-Tag enthalten.

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 mit den Regeln aus dem Beispiel für die 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>

CAP-Debugging

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

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. Im Folgenden sehen Sie einen Auszug aus dem Cuttlefish-Automobilgerät mit Bluetooth A2DP, Busgerät 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 zum Debuggen des CAP-Parameter-Frameworks finden Sie in diesem Tool:

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

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

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

Unter Android 15 und niedriger ist die Datei möglicherweise anders. 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 je nach Build-Image-Typ automatisch generiert. Sie können auch eine andere Datei für Release oder Debug für einen Legacy-Build verwenden. In einem Release-Build wird TuningAllowed auf false ohne Socket-Port festgelegt (Sockets sind in Release-Builds dafür nicht zulässig). Bei Entwicklungs- und userdebug-Builds wird es auf true mit dem verwendeten Socket-Port festgelegt. Beachten Sie, dass dies die Datei ist, auf die die audio_policy_pfw_toplevel verweist. Das Tool für Remote-Prozesse muss auch in der Make-Datei oder Build-Datei des Geräts enthalten sein:

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

Außerdem muss die entsprechende SELinux-Richtlinie zum Zulassen von Sockets 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

Aufgrund der erheblichen Änderungen, die die AIDL-Audio-HAL-CAP-Engine und die vorherigen Versionen mit sich bringen, sollten Sie verschiedene Szenarien für die Geräteüberleitung berücksichtigen. In diesem Abschnitt werden die wichtigsten Übergangsszenarien behandelt und Empfehlungen für die Aktivierung der CAP-Engine-Konfiguration gegeben.

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

Ein neues Gerät muss mit Android 16 oder höher auf der vendor-Partition gestartet werden. Das bedeutet, dass die konfigurierbare Audio Policy Engine-Konfiguration über die AIDL-Audio-HAL-Schnittstelle verfügbar gemacht werden muss. Die CAP-Engine-Konfiguration für das Gerät sollte aus den Beispielen kopiert werden. Auf der vendor-Partition darf keine PfW-CAP-Domaindefinition vorhanden sein.

Das für das Gerät verwendete System-Image ist Android 16 oder höher. Das Audiodienst-Framework erkennt die CAP-Konfiguration über die AIDL-Audio-HAL-Schnittstelle. Daher wird PfW mit der PfW-CAP-Domaindefinition aus dem System-Image initialisiert und die über AIDL empfangene Geräte-CAP-Konfiguration geladen.

Ein Beispiel ist das virtuelle Gerät „Cuttlefish“ für die Automobilbranche, das in dieser Änderung eingeführt wurde und auf das für die Einrichtung der erforderlichen Konfigurationsdateien erforderlichen Dateien, Build-Regeln und Make-Dateien verwiesen werden kann. Dies funktioniert mit den Ladern, die in der standardmäßigen AIDL-Audio-HAL bereitgestellt werden.

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

Ein neues Gerät muss mit Android 16 oder höher auf der vendor-Partition gestartet werden. Da der OEM jedoch eine verwendbare CAP-Engine-Konfiguration für das Gerät hat, möchte er diese als Ausgangspunkt verwenden oder vollständig wiederverwenden. Die AIDL-Version der CAP-Konfiguration hat einige Änderungen im Vergleich zu Android 15 und niedrigeren Versionen. Daher muss der Anbieter die vorhandene Konfiguration in AIDL konvertieren. Unter Produktstrategien finden Sie Informationen zu den erforderlichen Änderungen zwischen Android 16 und niedrigeren Versionen. Im Allgemeinen wird die CAP-Konfiguration vom Audio-Framework auf die gleiche Weise wie in Szenario 1 erkannt und geladen.

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

In diesem Szenario enthält die vendor-Partition die CAP-Konfiguration für Android 15 und niedriger sowie die PfW-CAP-Domaindefinition. Die vendor-Partition bleibt unverändert und verwendet weiterhin die HIDL HAL. Das Framework folgt dem Szenario für Android 15 und niedriger und lädt die gesamte CAP-bezogene Konfiguration aus der vendor-Partition.

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

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 Markteinführung neuer Geräte mit Android 16 verwendet werden, sondern nur, um vorhandene Geräte mit Android 15 auf Android 16 (system-Partitionsaktualisierung) zu aktualisieren.

Das Audio-Framework erkennt die Audiokonfiguration der AIDL-Audio-HAL ohne die CAP-Konfiguration. Für die CAP-Konfiguration lädt der Audiorichtliniendienst (Audio-Framework) die CAP-Konfiguration aus der vendor-Partition. In diesem Fall müssen sowohl die PfW-CAP-Domaindefinition als auch die Geräte-CAP-Konfiguration aus der vendor-Partition geladen werden.

Zusammenfassung der CAP-Migration

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