Audiorichtlinien konfigurieren

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

  • OEM-spezifische Routingstrategien
  • Anpassbare Lautstärkegruppen für Gruppen von Legacy-Streamtypen, die dieselben Lautstärkekurven verwenden
  • Routingstrategien, die von der Audio Policy Engine deklariert werden, anstatt hartcodiert zu sein
  • Lautstärkekurven und ‑gruppen, die von der Audio Policy Engine verwaltet werden
  • Interne Überarbeitung zur Vorbereitung auf eine zukünftige Trennung zwischen gemeinsamem Code und konfigurierbarem Code und zur Bereitstellung einer umfassenderen Verwaltung von Audiogeräten Beispielsweise die Verwendung aller Geräteeigenschaften und nicht nur des Typs in Richtlinienregeln

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

In früheren Android-Versionen mussten Sie device/<company>/<device>/audio/audio_policy.conf verwenden, 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 begrenzt ist, um komplexe Topologien für Branchen wie Fernseher und Autos zu beschreiben.

In Android 7.0 wurde audio_policy.conf verworfen und die Unterstützung für die Definition einer Audiotopologie mithilfe eines XML-Dateiformats hinzugefügt, das besser lesbar ist, eine breite Palette von Bearbeitungs- und Parsing-Tools bietet und flexibel genug ist, um komplexe Audiotopologien 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 Sie 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 definieren. Darüber hinaus bietet das XML-Format die folgenden Verbesserungen:

  • In Android 10 sind mehrere aktive Aufnahmeprogramme gleichzeitig zulässig.
    • Der Aufnahmestart wird aufgrund einer Parallelitätssituation nie abgelehnt.
    • Der registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) Callback benachrichtigt Clients über Änderungen am Aufnahmepfad.
  • In den folgenden Situationen erhalten Clients stumme Audiobeispiele:
    • Ein datenschutzrelevanter Anwendungsfall (z. B. VOICE_COMMUNICATION) ist aktiv.
    • Der Client hat keinen Vordergrunddienst oder keine Vordergrund-UI.
    • Sonderrollen werden von der Richtlinie erkannt:
      • Bedienungshilfe: Kann auch dann aufnehmen, wenn ein datenschutzrelevanter Anwendungsfall aktiv ist.
      • Assistant: Gilt als datenschutzrelevant, wenn die UI im Vordergrund ist.
  • Audioprofile haben eine ähnliche Struktur wie einfache HDMI-Audio-Deskriptoren, sodass für jedes Audioformat unterschiedliche Abtastraten/Kanalmasken verwendet werden können.
  • 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 angehängt sind. Dadurch konnte die Audiopolicy keine Verbindungen steuern, die mit Audio-Patch-APIs angefordert wurden. Im XML-Format werden in der Topologiebeschreibung Verbindungseinschränkungen definiert.
  • Die Unterstützung für includes vermeidet die Wiederholung von Standarddefinitionen für A2DP, USB oder die Umleitung von Übermittlungen.
  • Lautstärkekurven sind anpassbar. Bisher waren Lautstärketabellen hartcodiert. Im XML-Format werden Lautstärketabellen 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 Audiopolicys ist audio_policy_configuration.xml und befindet sich unter /system/etc. In den folgenden Beispielen wird eine einfache Konfiguration für Audiopolicys im XML-Dateiformat für Android 12 und für Versionen unter Android 12 gezeigt.

Die Struktur der obersten Ebene enthält Module, die den einzelnen Audio-HAL-Hardwaremodulen entsprechen. Jedes Modul enthält eine Liste von Mix-Ports, Geräteports 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äteports beschreiben die Geräte, die mit ihrem Typ angehängt werden können (optional auch mit Adresse und Audioeigenschaften, falls relevant).
  • Routen sind 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 eine Lautstärke in dB umgewandelt 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 XML-Inclusion-Methode (XInclude) können Sie Konfigurationsinformationen für Audiopolicys einfügen, die sich in anderen XML-Dateien befinden. Alle eingeschlossenen Dateien müssen der oben beschriebenen Struktur entsprechen und die folgenden Einschränkungen erfüllen:

  • 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 des Open-Source-Projekts für Android (AOSP) in alle Konfigurationsdateien für Audiopolicys kopiert werden (was fehleranfällig ist). Für die folgenden Audio-HALs wird eine Standard-XML-Datei für die Konfiguration von Audiopolicys bereitgestellt:

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

Organisation des Audiopolicy-Codes

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 Implementierung des Verhaltens, die für alle Apps gleich sind. Ähnlich wie AudioPolicyManager.cpp, wobei die Engine-Funktionalität und allgemeine Konzepte abstrahiert wurden.
/common Definiert Basisklassen (z. B. Datenstrukturen für Audio-Streamprofile für Ein- und Ausgabe, Audiogerätedeskriptoren, Audio-Patches und Audio-Ports). Dies wurde zuvor in AudioPolicyManager.cpp definiert.
/engine

Implementiert die Regeln, die definieren, welches Gerät und welche Lautstärken für einen bestimmten Anwendungsfall verwendet werden sollen. Es implementiert eine Standardschnittstelle mit dem generischen Teil, z. B. um das geeignete Gerät für einen bestimmten Anwendungsfall für die Wiedergabe oder Aufnahme abzurufen oder um verbundene Geräte oder einen externen Status (d. h. einen Anrufstatus der erzwungenen Verwendung) festzulegen, der die Routingentscheidung ä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 Policy Engine, die auf dem Parameter Framework basiert (siehe unten). Die Konfiguration basiert auf dem Parameter Framework und darauf, wo die Richtlinie durch XML-Dateien definiert wird.
/enginedefault Implementierung der Policy Engine, die auf früheren Implementierungen des Android Audio Policy Manager basiert. Dies ist die Standardeinstellung und enthält hartcodierte Regeln, die den Nexus- und AOSP-Implementierungen entsprechen.
/service Enthält Binder-Schnittstellen, Threading und die Implementierung der Sperrung mit der Schnittstelle zum Rest des Frameworks.

Konfiguration mit dem Parameter Framework

Der Audiopolicy-Code ist so organisiert, dass er leicht zu verstehen und zu warten ist und gleichzeitig eine Audiopolicy unterstützt, die vollständig durch Konfigurationsdateien definiert wird. Die Organisation und das Design der Audiopolicy basieren auf dem Parameter Framework von Intel, einem pluginbasierten und regelbasierten Framework für die Verarbeitung von Parametern.

Mit der konfigurierbaren Audiopolicy können Anbieter und OEMs Folgendes tun:

  • Die Struktur eines Systems und seine Parameter in XML beschreiben.
  • Ein Backend (Plug-in) in C++ schreiben oder wiederverwenden, um auf die beschriebenen Parameter zuzugreifen.
  • Bedingungen/Regeln in XML oder in einer domänenspezifischen Sprache definieren, unter denen ein bestimmter Parameter einen bestimmten Wert annehmen muss.

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

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

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

Routing-APIs für Audiopolicys

In Android 6.0 wurde eine öffentliche Enumeration and Selection API eingeführt, die auf der Audio-Patch-/Audio-Port-Infrastruktur basiert und App-Entwicklern die Möglichkeit bietet, eine Präferenz für eine bestimmte Geräteausgabe oder ‑eingabe für verbundene Audioaufnahmen oder ‑tracks anzugeben.

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 eine AudioRouting-Schnittstelle hinzugefügt, die die expliziten Routingmethoden ersetzt, kombiniert und verwirft, die spezifisch für die Klassen AudioTrack und AudioRecord waren.

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 für mehrere Kanäle

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 der Audiostream nicht auf zwei Kanäle heruntergemischt wird. Die Audio-HAL muss angeben, ob ein Ausgabestreamprofil Mehrkanal-Audiofunktionen unterstützt. Wenn die HAL ihre Funktionen verfügbar macht, ermöglicht der Standard-Policy Manager die Mehrkanalwiedergabe über HDMI. Implementierungsdetails 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 Audiopolicys, um die Mehrkanalausgabe für Ihr Produkt zu beschreiben. Im folgenden Beispiel aus frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml wird eine dynamische Kanalmaske verwendet. Das bedeutet, dass der Audio Policy Manager nach der Verbindung die von der HDMI-Senke unterstützten Kanalmasken abfragt.

Sie können auch eine statische Kanalmaske wie AUDIO_CHANNEL_OUT_5POINT1 angeben. Der Mixer von AudioFlinger mischt die Inhalte automatisch auf Stereo herunter, 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 ordnungsgemäß für Ihr Produkt deklariert sind. Weitere Informationen finden Sie unter Codecs für das Framework verfügbar machen.