Unterstützung für konfigurierbare Audiorichtlinien in der AIDL HAL

Ab Android 16 wird die AIDL Audio HAL-Schnittstelle vollständig von der konfigurierbaren Audiorichtlinie (CAP) unterstützt.

Auf dieser Seite finden Sie den erforderlichen technischen Hintergrund, der Partnern und SoC-Anbietern bei der Migration ihrer Audiorichtlinienkonfigurationen helfen soll.

Parameter-Framework

Die Implementierung des CAP basiert auf dem Intel Parameter Framework. Die CAP wurde mit Android 6 eingeführt. Mit dem Parameter Framework (PfW) können Sie ein System in Form von Parametern beschreiben. Mithilfe einer Konfigurations-XML-Datei bindet der PfW die Parameter über Plug-ins an Aktionen und stellt Regeln für die Änderung der Parameter gemäß den aktuellen Kriterien bereit.

Struktur von CAP in HIDL

In HIDL wurde die gesamte Konfiguration für die CAP in XML angegeben. Weitere Informationen finden Sie unter Parameter-Framework und Konfiguration mit dem Parameter-Framework. Mit XML-Dateien wurde Folgendes angegeben:

  • Beschreibung der Struktur der Parameter (d. h. Beschreibung der Audiodomain für die PfW)
  • Definitionen für Kriterien
  • Regeln für Routingstrategien (Auswahl von Eingabe- und Ausgabegeräten)
  • Spezifikation für Volume-Tabellen

Mit HIDL konnte das Android-Framework diese XML-Dateien direkt aus der Anbieterpartition laden. Dies war zulässig, da für diese XML-Dateien als Teil der HAL API ein XSD-Schema definiert wurde. Jede Hauptversion der HIDL HAL hatte ein entsprechendes XSD-Schema. Für Hauptversionen war keine Abwärtskompatibilität erforderlich.

Struktur von CAP in AIDL

Bei der Umstellung auf AIDL müssen HAL API-Releases abwärtskompatibel bleiben. In HIDL-Terminologie ist jede Version der AIDL HAL ein „Nebenupdate“. XSD-Schemas können nicht mehr als Teil von HAL-APIs verwendet werden, da es keine etablierte Möglichkeit gibt, abwärtskompatible Updates für die Schemas zu definieren. Daher muss die zuvor in XML-Dateien definierte Konfiguration jetzt von der HAL mithilfe von AIDL-APIs bereitgestellt werden. Dazu wird die Struktur der CAP-Konfiguration in AIDL konvertiert, ähnlich wie Audio Policy Configuration-XMLs in AIDL Audio HAL für Android 15.

Datenstrukturen für die CAP werden den gemeinsamen stabilen Datentypen hinzugefügt und umfassen die folgenden Parcelable-Typen:

Der Einstiegspunkt für die CAP-Konfiguration befindet sich in der Struktur AudioHalEngineConfig.CapSpecificConfig. In den Kommentaren unter AudioHalCapConfiguration.aidl finden Sie ein Diagramm der CAP-Datenstrukturen.

Die Standardimplementierung der AIDL HAL enthält eine Hilfsklasse, die die AIDL-Parcelable-Objekte basierend auf dem Inhalt alter CAP-XML-Dateien ausfüllt, um die Migration für Partner zu vereinfachen.

Migrationsszenarien

Partner können die in diesem Abschnitt aufgeführten Optionen in Betracht ziehen, je nachdem, ob es sich um die erste Einführung eines Produkts handelt, für das bisher kein CAP verwendet wurde, oder um die Migration eines vorhandenen Produkts.

Neues Produkt

Bei einem neuen Produkt, für das CAP zur Implementierung von Audiorichtlinien verwendet wird, kann der OEM XML zum Speichern der CAP-Konfiguration auf Anbieterseite verwenden.

Der Vorteil der Verwendung von XML besteht darin, dass es eine Reihe von Scripttools gibt, die die Generierung der Konfiguration aus einer allgemeinen Beschreibung erleichtern.

Wenn der OEM XML zum Speichern der CAP-Konfiguration auf der Anbieterpartition verwendet, wird empfohlen, die Standardimplementierung des XML-Parsers zum Konvertieren der Konfiguration in AIDL zu verwenden.

Update für bestehendes Produkt

Wenn das Produkt bereits CAP verwendet und daher die XML-Konfiguration hat, können Sie das vorhandene CAP mit der AIDL-Version der HAL weiter verwenden.

Die Namenskonvention für Produktstrategien unterscheidet sich in den HIDL- und AIDL-Versionen der CAP-Konfiguration. In HIDL wurden für die integrierten („alten“) Strategien kurze Namen in Kleinbuchstaben wie media verwendet. In AIDL werden für integrierte Strategien dagegen Namen in Großbuchstaben mit dem Präfix STRATEGY_ verwendet, z. B. STRATEGY_MEDIA. Eine Liste der vordefinierten Strategien finden Sie unter CapProductStrategies.xml. In derselben Datei werden „vorab zugewiesene“ IDs für OEM-spezifische Strategien definiert, die dem Benennungsmuster vx_10xx mit den Zahlen 1000 bis 1039 folgen.

Legacy-Produkt

Wenn das Produkt, das auf CAP basiert, seine Anbieterpartition nicht aktualisiert und bei HIDL bleibt, können Sie die Systempartition auf Android 16 aktualisieren. Das Framework ist weiterhin mit der bisherigen CAP-Konfiguration kompatibel.

Beispielimplementierung

Um Partnern bei der Implementierung von CAP für ihre Plattformen zu helfen, enthält das AOSP ein Beispiel für die „Automotive“-Variante des virtuellen Cuttlefish-Geräts, das CAP mit AIDL HAL verwendet. Die gerätespezifische Konfiguration befindet sich unter device/google/cuttlefish/shared/auto/audio/policy/engine mit dem lunch-Zielnamen aosp_cf_x86_64_auto. Die Android.bp-Datei kann als Referenz zum Generieren der gesamten CAP-Anbieterdateien verwendet werden.