Audiorichtlinien konfigurieren

Die Veröffentlichung von Android 10 umfasst eine erhebliche Refaktorierung des Audio Policy Manager, um mehr Flexibilität für komplexe Automotive-Anwendungsfälle zu bieten:

  • OEM-spezifische Routingstrategien.
  • Anpassbare Volumengruppen für Gruppen von Legacy-Streamtypen mit denselben Volumenkurven.
  • Routingstrategien, die von der Audio Policy Engine deklariert werden, anstatt fest codiert zu sein.
  • Von der Audio Policy Engine verwaltete Lautstärkekurven und ‑gruppen.
  • Internes Refactoring zur Vorbereitung auf eine zukünftige Aufteilung zwischen gemeinsamem Code und konfigurierbarem Code sowie für eine erweiterte Verwaltung von Audiogeräten. Beispielsweise können in Richtlinienregeln alle Geräteattribute und nicht nur der Gerätetyp verwendet werden.

Mit Android 7.0 wurde ein Konfigurationsdateiformat für die Audiopolicy (XML) eingeführt, mit dem Sie Ihre Audiotopologie beschreiben können.

In früheren Android-Versionen musste device/<company>/<device>/audio/audio_policy.conf verwendet werden, um die auf Ihrem Produkt vorhandenen Audiogeräte zu deklarieren. Ein Beispiel für diese Datei für die Galaxy Nexus-Audiohardware finden Sie unter device/samsung/tuna/audio/audio_policy.conf. CONF ist jedoch ein einfaches, proprietäres Format, das zu eingeschränkt ist, um komplexe Topologien für Branchen wie Fernseher und Autos zu beschreiben.

In Android 7.0 wurde audio_policy.conf eingestellt und die Unterstützung für die Definition einer Audio-Topologie mithilfe eines XML-Dateiformats hinzugefügt, das besser lesbar ist, eine Vielzahl von Bearbeitungs- und Parsing-Tools bietet und flexibel genug ist, um komplexe Audio-Topologien zu beschreiben. In Android 7.0 wird das Build-Flag USE_XML_AUDIO_POLICY_CONF verwendet, um das XML-Format von Konfigurationsdateien auszuwählen.

Vorteile des XML-Formats

Wie in der CONF-Datei können in der XML-Datei die Anzahl und die Typen von Ausgabestream- und Eingabestreamprofilen, Geräte, die für die Wiedergabe und Aufnahme verwendet werden können, sowie Audioattribute definiert werden. Außerdem bietet das XML-Format die folgenden Verbesserungen:

  • Unter Android 10 sind mehrere aktive Aufzeichnungs-Apps gleichzeitig zulässig.
    • Der Aufnahmestart wird nie aufgrund einer gleichzeitigen Nutzung abgelehnt.
    • Der registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)-Callback benachrichtigt Clients über Änderungen am Aufnahmepfad.
  • In den folgenden Situationen erhält ein Client stumme Audio-Samples:
    • Ein datenschutzsensibler Anwendungsfall (z. B. VOICE_COMMUNICATION) ist aktiv.
    • Der Client hat keinen Dienst im Vordergrund und keine Benutzeroberfläche im Vordergrund.
    • Die folgenden speziellen Rollen werden von der Richtlinie berücksichtigt:
      • Barrierefreiheitsdienst: Kann auch dann aufzeichnen, wenn ein datenschutzsensibler Anwendungsfall aktiv ist.
      • Assistant: Gilt als datenschutzrelevant, wenn die Benutzeroberfläche oben angezeigt wird.
  • Audioprofile haben eine ähnliche Struktur wie einfache HDMI-Audio-Deskriptoren. Für jedes Audioformat ist ein anderer Satz von Samplingraten/Kanalmasken möglich.
  • Es gibt explizite Definitionen für alle möglichen Verbindungen zwischen Geräten und Streams. Bisher war es durch eine implizite Regel möglich, alle Geräte zu verbinden, die an dasselbe HAL-Modul angeschlossen sind. Dadurch konnte die Audiopolicy keine Verbindungen steuern, die mit Audio-Patch-APIs angefordert wurden. Im XML-Format werden in der Topologiebeschreibung Verbindungsbeschränkungen definiert.
  • Die Unterstützung für includes vermeidet die Wiederholung von Standarddefinitionen für A2DP, USB oder das Senden von Umleitungen.
  • Lautstärkekurven können angepasst werden. Bisher waren Volumentabellen fest codiert. Im XML-Format werden Volumentabellen beschrieben und können angepasst werden.

In der Vorlage unter frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml werden viele dieser Funktionen verwendet.

Dateiformat und Speicherort

Die neue Konfigurationsdatei für die Audio-Richtlinie ist audio_policy_configuration.xml und befindet sich unter /system/etc. Die folgenden Beispiele zeigen eine einfache Audiokonfiguration in der XML-Datei für Android 12 und für die Versionen unter Android 12.

Die Struktur der obersten Ebene enthält Module, die den einzelnen Audio-HAL-Hardwaremodulen entsprechen. Jedes Modul hat eine Liste von Mix-Ports, Geräte-Ports und Routen:

  • Mix-Ports beschreiben die möglichen Konfigurationsprofile für Streams, die in der Audio-HAL für die Wiedergabe und Aufnahme geöffnet werden können.
  • Geräteanschlüsse beschreiben die Geräte, die mit ihrem Typ (und optional mit Adresse und Audioeigenschaften, falls relevant) angeschlossen werden können.
  • Routen ist vom Mix-Port-Deskriptor getrennt, sodass Routen von Gerät zu Gerät oder von Stream zu Gerät beschrieben werden können.

Lautstärketabellen sind einfache Listen von Punkten, die die Kurve definieren, mit der ein UI-Index in einen Lautstärkepegel in dB umgerechnet wird. Eine separate Include-Datei enthält Standardkurven, aber jede Kurve für einen bestimmten Anwendungsfall und eine bestimmte Geräteklasse kann überschrieben werden.

Dateieinschlüsse

Mit der Methode „XML Inclusions“ (XInclude) können Sie Konfigurationsinformationen für Audiopolicys aus anderen XML-Dateien einfügen. Alle enthaltenen Dateien müssen der oben beschriebenen Struktur entsprechen und die folgenden Einschränkungen beachten:

  • Dateien dürfen nur Elemente der obersten Ebene enthalten.
  • Dateien dürfen keine XInclude-Elemente enthalten.

Verwenden Sie „includes“, um zu vermeiden, dass Konfigurationsinformationen für Standard-Audio-HAL-Module (Hardware Abstraction Layer) des Android Open Source Project (AOSP) in alle Audio-Richtlinienkonfigurationsdateien kopiert werden, was fehleranfällig ist. Für die folgenden Audio-HALs wird eine XML-Datei mit einer Standardkonfiguration für Audioprichtlinien bereitgestellt:

  • A2DP:a2dp_audio_policy_configuration.xml
  • Submix umleiten:rsubmix_audio_policy_configuration.xml
  • USB:usb_audio_policy_configuration.xml

Organisation des Audio-Richtliniencodes

AudioPolicyManager.cpp ist in mehrere Module unterteilt, um die Wartung und Konfiguration zu erleichtern. Die Organisation von frameworks/av/services/audiopolicy umfasst die folgenden Module.

Modul Beschreibung
/managerdefault Enthält die generischen Schnittstellen und die Verhaltensimplementierung, die für alle Apps üblich sind. Ähnlich wie AudioPolicyManager.cpp, wobei die Engine-Funktionen und gängigen Konzepte abstrahiert wurden.
/common Definiert Basisklassen (z. B. Datenstrukturen für Ein-/Ausgabe-Audiostreamprofile, Audiogerätedeskriptoren, Audio-Patches und Audioanschlüsse). Bisher wurde dies in AudioPolicyManager.cpp definiert.
/engine

Implementiert die Regeln, die definieren, welches Gerät und welche Volumes für einen bestimmten Anwendungsfall verwendet werden sollen. Es wird eine Standardschnittstelle mit dem generischen Teil implementiert, z. B. um das geeignete Gerät für einen bestimmten Wiedergabe- oder Aufnahme-Anwendungsfall abzurufen oder um verbundene Geräte oder den externen Status (d. h. einen Anrufstatus der erzwungenen Nutzung) festzulegen, der die Routing-Entscheidung ändern kann.

In zwei Versionen verfügbar: Konfigurierbar und Standard. Informationen zum Auswählen der Version finden Sie unter Konfiguration mit dem Parameter Framework.
/engineconfigurable Implementierung der Richtlinien-Engine, die auf dem Parameter Framework basiert (siehe unten). Die Konfiguration basiert auf dem Parameter Framework und die Richtlinie wird durch XML-Dateien definiert.
/enginedefault Implementierung der Richtlinien-Engine basierend auf früheren Implementierungen des Android Audio Policy Manager. Dies ist die Standardeinstellung und umfasst hartcodierte Regeln, die den Nexus- und AOSP-Implementierungen entsprechen.
/service Enthält Binder-Schnittstellen, Threading und Locking-Implementierung mit der Schnittstelle zum Rest des Frameworks.

Konfiguration mit dem Parameter Framework

Der Audiorichtliniencode ist so organisiert, dass er leicht zu verstehen und zu warten ist. Außerdem wird eine Audiorichtlinie unterstützt, die vollständig durch Konfigurationsdateien definiert wird. Die Organisation und das Design der Audio-Richtlinie basieren auf dem Parameter Framework von Intel, einem Plug-in- und regelbasierten Framework für die Verarbeitung von Parametern.

Mit der konfigurierbaren Audio-Richtlinie können Anbieter und OEMs:

  • Beschreiben Sie die Struktur eines Systems und seine Parameter in XML.
  • Schreiben Sie (in C++) oder verwenden Sie ein Backend (Plug-in) für den Zugriff auf die beschriebenen Parameter.
  • Definieren Sie (in XML oder in einer domänenspezifischen Sprache) Bedingungen/Regeln, unter denen ein bestimmter Parameter einen bestimmten Wert annehmen muss.

AOSP enthält ein Beispiel für eine Audiokonfigurationsdatei, in der das Parameter-Framework unter Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml verwendet wird. Weitere Informationen finden Sie in der Intel-Dokumentation zum Parameter Framework.

In Android 10 oder niedriger wird die konfigurierbare Audio-Richtlinie mit der Build-Option USE_CONFIGURABLE_AUDIO_POLICY ausgewählt. In Android 11 oder höher wird die Version der Audio-Richtlinien-Engine in der Datei audio_policy_configuration.xml ausgewählt. Um die konfigurierbare Audio-Richtlinien-Engine auszuwählen, legen Sie den Wert des Attributs engine_library des Elements globalConfiguration auf configurable fest, wie im folgenden Beispiel:

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

APIs für das Audio-Richtlinien-Routing

Mit Android 6.0 wurde eine öffentliche Enumeration and Selection API eingeführt, die auf der Infrastruktur für Audio-Patches/-Ports basiert und mit der App-Entwickler eine Präferenz für eine bestimmte Geräteausgabe oder ‑eingabe für verbundene Audioaufnahmen oder ‑tracks angeben können.

In Android 7.0 wird die Enumeration and Selection API durch CTS-Tests überprüft und um das Routing für native C/C++-Audiostreams (OpenSL ES) erweitert. Das Routing von nativen Streams erfolgt weiterhin in Java. Es wurde jedoch eine AudioRouting-Schnittstelle hinzugefügt, die die expliziten Routing-Methoden, die für die Klassen AudioTrack und AudioRecord spezifisch waren, ersetzt, kombiniert und als veraltet kennzeichnet.

Weitere Informationen zur Enumeration and Selection API finden Sie unter Android-Konfigurationsschnittstellen und OpenSLES_AndroidConfiguration.h. Weitere Informationen zum Audio-Routing finden Sie unter AudioRouting.

Support über mehrere Kanäle

Wenn deine Hardware und dein Treiber Mehrkanal-Audio über HDMI unterstützen, kannst du den Audio-Stream direkt an die Audio-Hardware ausgeben. Dadurch wird der AudioFlinger-Mixer umgangen, sodass der Stream nicht auf zwei Kanäle heruntergemischt wird. Die Audio-HAL muss angeben, ob ein Ausgabestreamprofil Mehrkanal-Audiofunktionen unterstützt. Wenn das HAL seine Funktionen offenlegt, erlaubt der Standardrichtlinienmanager die Mehrkanalwiedergabe über HDMI. Weitere Informationen zur Implementierung finden Sie unter device/samsung/tuna/audio/audio_hw.c.

Wenn Sie angeben möchten, dass Ihr Produkt eine Mehrkanal-Audioausgabe enthält, bearbeiten Sie die Konfigurationsdatei für die Audio-Richtlinie, um die Mehrkanalausgabe für Ihr Produkt zu beschreiben. Das folgende Beispiel aus frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml zeigt eine dynamische Channel-Maske. Das bedeutet, dass der Audio Policy Manager nach der Verbindung die vom HDMI-Senkgerät unterstützten Channel-Masken abfragt.

Sie können auch eine statische Channelmaske wie AUDIO_CHANNEL_OUT_5POINT1 angeben. Der Mixer von AudioFlinger führt automatisch ein Downmixen der Inhalte zu Stereo durch, wenn sie an ein Audiogerät gesendet werden, das kein Mehrkanal-Audio unterstützt.

Medien-Codecs

Achten Sie darauf, dass die von Ihrer Hardware und Ihren Treibern unterstützten Audio-Codecs für Ihr Produkt richtig deklariert sind. Weitere Informationen finden Sie unter Codecs für das Framework verfügbar machen.