Konfigurieren von Audiorichtlinien

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Die Android 10-Version enthält eine signifikante Überarbeitung des Audio-Richtlinien-Managers, um mehr Flexibilität zur Unterstützung komplexer Anwendungsfälle im Automobilbereich zu bieten:

  • OEM-spezifische Routing-Strategien.
  • Anpassbare Volumengruppen für Gruppen von Legacy-Stream-Typen, die dieselben Volumenkurven verwenden.
  • Routing-Strategien, die von der Audiorichtlinien-Engine deklariert werden, anstatt fest codiert zu sein.
  • Lautstärkekurven und -gruppen, die von der Audiorichtlinien-Engine verwaltet werden.
  • Internes Refactoring, das sich auf eine zukünftige Aufteilung zwischen allgemeinem Code und konfigurierbarem Code vorbereitet und eine umfassendere Verwaltung von Audiogeräten bietet. Beispielsweise die Verwendung aller Geräteeigenschaften, nicht nur ihres Typs in Richtlinienregeln.

Android 7.0 hat ein Audiorichtlinien-Konfigurationsdateiformat (XML) zur Beschreibung Ihrer Audiotopologie eingeführt.

Frühere Android-Versionen erforderten die Verwendung von device/<company>/<device>/audio/audio_policy.conf , um die auf Ihrem Produkt vorhandenen Audiogeräte zu deklarieren (ein Beispiel dieser 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 Automobile zu beschreiben.

Android 7.0 audio_policy.conf als veraltet markiert und Unterstützung für die Definition einer Audiotopologie mithilfe eines XML-Dateiformats hinzugefügt, das besser lesbar ist, über eine breite Palette von Bearbeitungs- und Parsing-Tools verfügt und flexibel genug ist, um komplexe Audiotopologien zu beschreiben. Android 7.0 verwendet das Build-Flag USE_XML_AUDIO_POLICY_CONF zum Auswählen des XML-Formats von Konfigurationsdateien.

Vorteile des XML-Formats

Wie in der CONF-Datei ermöglicht die XML-Datei das Definieren der Anzahl und Typen von Ausgabe- und Eingabe-Stream-Profilen, für die Wiedergabe und Erfassung verwendbare Geräte und Audioattribute. Darüber hinaus bietet das XML-Format folgende Erweiterungen:

  • In Android 10 ist mehr als eine aktive Aufnahme-App gleichzeitig erlaubt.
    • Der Aufzeichnungsstart wird niemals aufgrund einer Nebenläufigkeitssituation abgelehnt.
    • Der registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) benachrichtigt Clients über Änderungen des Aufnahmepfads.
  • In den folgenden Situationen erhält ein Client stille Audio-Samples:
    • Ein datenschutzrelevanter Anwendungsfall (z. B. VOICE_COMMUNICATION ) ist aktiv.
    • Der Client verfügt nicht über einen Vordergrunddienst oder eine Vordergrundbenutzeroberfläche.
    • Spezielle Rollen werden von der Richtlinie anerkannt:
      • Barrierefreiheitsdienst: Kann aufzeichnen, selbst wenn ein datenschutzrelevanter Anwendungsfall aktiv ist.
      • Assistent: Wird als datenschutzsensibel angesehen, wenn die Benutzeroberfläche oben ist.
  • Audioprofile haben eine ähnliche Struktur wie einfache HDMI-Audiodeskriptoren und ermöglichen einen anderen Satz von Abtastraten/Kanalmasken für jedes Audioformat.
  • Es gibt explizite Definitionen für alle möglichen Verbindungen zwischen Geräten und Streams. Zuvor ermöglichte es eine implizite Regel, alle an dasselbe HAL-Modul angeschlossenen Geräte zu verbinden, wodurch verhindert wurde, dass die Audiorichtlinie Verbindungen steuert, die mit Audio-Patch-APIs angefordert wurden. Im XML-Format definiert die Topologiebeschreibung Verbindungsbeschränkungen.
  • Die Unterstützung für Includes vermeidet die Wiederholung von standardmäßigen A2DP-, USB- oder Umleitungsübermittlungsdefinitionen.
  • Lautstärkekurven sind anpassbar. Bisher waren Volumentabellen fest codiert. Im XML-Format werden Volumentabellen beschrieben und können angepasst werden.

Die Vorlage unter frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml zeigt viele dieser Features im Einsatz.

Dateiformat und Speicherort

Die neue Konfigurationsdatei für die Audiorichtlinie ist audio_policy_configuration.xml und befindet sich in /system/etc . Die folgenden Beispiele zeigen eine einfache Audiorichtlinienkonfiguration im XML-Dateiformat für Android 12 und für die Versionen unter Android 12.

Die Struktur der obersten Ebene enthält Module, die jedem Audio-HAL-Hardwaremodul entsprechen, wobei jedes Modul eine Liste von Mix-Ports, Geräteports und Routen enthält:

  • Mix-Ports beschreiben die möglichen Konfigurationsprofile für Streams, die am Audio-HAL zur Wiedergabe und Aufnahme geöffnet werden können.
  • Geräteports beschreiben die Geräte, die angeschlossen werden können, mit ihrem Typ (und optional Adresse und Audioeigenschaften, falls relevant).
  • Routen sind vom Mix-Port-Deskriptor getrennt, wodurch die Beschreibung von Routen von Gerät zu Gerät oder Stream zu Gerät ermöglicht wird.

Lautstärketabellen sind einfache Listen von Punkten, die die Kurve definieren, die verwendet wird, um einen UI-Index in eine Lautstärke in dB umzuwandeln. Eine separate Include-Datei stellt Standardkurven bereit, aber jede Kurve für einen bestimmten Anwendungsfall und eine bestimmte Gerätekategorie kann überschrieben werden.

Dateieinschlüsse

Die XML-Inclusions-Methode (XInclude) kann verwendet werden, um Konfigurationsinformationen für Audiorichtlinien einzuschließen, die sich in anderen XML-Dateien befinden. Alle enthaltenen Dateien müssen der oben beschriebenen Struktur mit folgenden Einschränkungen folgen:

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

Verwenden Sie Includes, um zu vermeiden, dass standardmäßige HAL-Modulkonfigurationsinformationen des Android Open Source Project (AOSP) in alle Konfigurationsdateien für Audiorichtlinien kopiert werden (was fehleranfällig ist). Für die folgenden Audio-HALs wird eine Standard-Audiorichtlinien-Konfigurations-XML-Datei bereitgestellt:

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

Organisation des Codes für Audiorichtlinien

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

Modul Beschreibung
/managerdefault Enthält die generischen Schnittstellen und Verhaltensimplementierungen, die allen Apps gemeinsam sind. Ähnlich wie AudioPolicyManager.cpp mit abstrahierter Engine-Funktionalität und allgemeinen Konzepten.
/common Definiert Basisklassen (z. B. Datenstrukturen für Eingangs-Ausgangs-Audiostromprofile, Audiogerätedeskriptoren, Audiopatches und Audioports). Dies wurde zuvor 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 implementiert eine Standardschnittstelle mit dem generischen Teil, um beispielsweise das geeignete Gerät für einen bestimmten Wiedergabe- oder Erfassungsanwendungsfall zu erhalten oder um verbundene Geräte oder einen externen Status (dh einen Anrufstatus der erzwungenen Verwendung) festzulegen, der das Routing ändern kann Entscheidung.

Verfügbar in zwei Versionen: konfigurierbar und Standard . Informationen zur Auswahl der Version finden Sie unter Konfiguration mit Parameter Framework .

/engineconfigurable Richtlinien-Engine-Implementierung, die auf Parameter Framework basiert (siehe unten). Die Konfiguration basiert auf dem Parameter Framework, wobei die Richtlinie durch XML-Dateien definiert wird.
/enginedefault Richtlinien-Engine-Implementierung basierend auf früheren Implementierungen von Android Audio Policy Manager. Dies ist die Standardeinstellung und enthält hartcodierte Regeln, die Nexus- und AOSP-Implementierungen entsprechen.
/service Umfasst Binderschnittstellen, Threading und Sperrimplementierung mit der Schnittstelle zum Rest des Frameworks.

Konfiguration mit Parameter Framework

Der Audiorichtliniencode ist so organisiert, dass er leicht verständlich und wartungsfreundlich ist und gleichzeitig eine vollständig durch Konfigurationsdateien definierte Audiorichtlinie unterstützt. Das Organisations- und Audio-Policy-Design basiert auf Intels Parameter Framework, einem Plugin-basierten und regelbasierten Framework zur Handhabung von Parametern.

Durch die Verwendung der konfigurierbaren Audiorichtlinie können OEMs von Anbietern Folgendes tun:

  • Beschreiben Sie die Struktur eines Systems und seine Parameter in XML.
  • Schreiben (in C++) oder Wiederverwenden eines Backends (Plugin) für den Zugriff auf beschriebene Parameter.
  • Definieren Sie (in XML oder in einer domänenspezifischen Sprache) Bedingungen/Regeln, nach denen ein bestimmter Parameter einen bestimmten Wert annehmen muss.

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

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

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

Routing-APIs für Audiorichtlinien

Android 6.0 führte eine öffentliche Aufzählungs- und Auswahl-API ein, die auf der Audio-Patch-/Audioport-Infrastruktur sitzt und es App-Entwicklern ermöglicht, eine Präferenz für einen bestimmten Geräteausgang oder -eingang für verbundene Audioaufzeichnungen oder -spuren anzugeben.

In Android 7.0 wird die Aufzählungs- und Auswahl-API durch CTS-Tests verifiziert und um das Routing für native C/C++ (OpenSL ES)-Audiostreams erweitert. Das Routing von nativen Streams erfolgt weiterhin in Java, mit dem Hinzufügen einer AudioRouting -Schnittstelle, die die expliziten Routing-Methoden ersetzt, kombiniert und veraltet, die für die AudioTrack und AudioRecord Klassen spezifisch waren.

Einzelheiten zur Aufzählungs- und Auswahl-API finden Sie unter Android-Konfigurationsschnittstellen und OpenSLES_AndroidConfiguration.h . Einzelheiten zum Audio-Routing finden Sie unter Audio- Routing .

Multi-Channel-Unterstützung

Wenn Ihre Hardware und Ihr Treiber Mehrkanal-Audio über HDMI unterstützen, können Sie den Audiostream direkt an die Audiohardware ausgeben (dadurch wird der AudioFlinger-Mixer umgangen, sodass er nicht auf zwei Kanäle heruntergemischt wird). unterstützt Mehrkanal-Audiofunktionen. Wenn die HAL ihre Fähigkeiten offenlegt, erlaubt der standardmäßige Richtlinienmanager die Mehrkanalwiedergabe über HDMI. Einzelheiten zur Implementierung finden Sie unter device/samsung/tuna/audio/audio_hw.c .

Um anzugeben, dass Ihr Produkt eine Mehrkanal-Audioausgabe enthält, bearbeiten Sie die Audiorichtlinien-Konfigurationsdatei, 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 Kanalmaske, was bedeutet, dass der Audio Policy Manager nach dem Verbinden die von der HDMI-Senke unterstützten Kanalmasken abfragt.

Sie können auch eine statische Kanalmaske wie AUDIO_CHANNEL_OUT_5POINT1 . Der Mixer von AudioFlinger mischt den Inhalt automatisch auf Stereo herunter, wenn er an ein Audiogerät gesendet wird, das Mehrkanal-Audio nicht unterstützt.

Medien-Codecs

Stellen Sie sicher, dass die Audio-Codecs, die Ihre Hardware und Treiber unterstützen, für Ihr Produkt richtig deklariert sind. Einzelheiten finden Sie unter Verfügbarmachen von Codecs für das Framework .