Die Android 10-Version enthält eine umfassende Refaktorisierung des Audiorichtlinienmanagers, um komplexe Anwendungsfälle im Automobilbereich flexibler zu unterstützen:
OEM-spezifische Routingstrategien
Benutzerdefinierte Lautstärkegruppen für Gruppen von älteren Streamtypen, die dieselben Lautstärkekurven verwenden.
Routingstrategien, die von der Audiorichtlinien-Engine deklariert und nicht hartcodiert werden.
Lautstärkekurven und -gruppen, die von der Audiorichtlinien-Engine verwaltet werden.
Internes Refactoring zur Vorbereitung auf eine zukünftige Aufteilung in gemeinsamen Code und konfigurierbaren Code sowie eine erweiterte Audiogeräteverwaltung. Beispielsweise die Verwendung aller Geräteeigenschaften, nicht nur des Typs, in Richtlinienregeln.
Mit Android 7.0 wurde ein Audiorichtlinienkonfigurationsdateiformat (XML) zum Beschreiben Ihrer Audiotopologie eingeführt.
Bei früheren Android-Releases mussten die Audiogeräte auf Ihrem Produkt mit device/<company>/<device>/audio/audio_policy.conf deklariert werden. Ein Beispiel für diese Datei für die Audiohardware von Galaxy Nexus 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.
In Android 7.0 wurde audio_policy.conf eingestellt und die Unterstützung für die Definition einer Audiotopologie mit einem XML-Dateiformat hinzugefügt, das für Menschen besser lesbar ist, eine breite Palette von Bearbeitungs- und Parsing-Tools bietet und flexibel genug ist, um komplexe Audiotopologien zu beschreiben. Android 7.0 verwendet das Build-Flag USE_XML_AUDIO_POLICY_CONF zur Auswahl des XML-Formats von Konfigurationsdateien.
Vorteile des XML-Formats
Wie in der CONF-Datei können Sie in der XML-Datei die Anzahl und die Typen der Ausgabe- und Eingabestreamprofile, die für die Wiedergabe und Aufnahme nutzbaren Geräte sowie die Audioattribute definieren. Außerdem bietet das XML-Format folgende Verbesserungen:
In Android 10 ist mehr als eine aktive Aufnahme-App gleichzeitig zulässig.
Der Aufnahmestart wird aufgrund einer Gleichzeitigkeitslage nicht abgelehnt.
Über den registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)-Callback werden Clients über Änderungen am Aufnahmepfad informiert.
In den folgenden Fällen erhält ein Kunde stumme Audiobeispiele:
Ein datenschutzsensibler Anwendungsfall (z. B. VOICE_COMMUNICATION) ist aktiv.
Der Client hat keinen Dienst oder keine Benutzeroberfläche im Vordergrund.
Die Richtlinie erkennt folgende Sonderrollen an:
Bedienungshilfe: Kann auch dann aufzeichnen, wenn ein datenschutzfreundlicher Anwendungsfall aktiv ist.
Assistant: Wird als datenschutzrelevant eingestuft, wenn die Benutzeroberfläche im Vordergrund ist.
Audioprofile haben eine ähnliche Struktur wie einfache HDMI-Audio-Beschreibungen und ermöglichen für jedes Audioformat eine andere Abtastrate/Kanalmaske.
Es gibt eindeutige Definitionen für alle möglichen Verbindungen zwischen Geräten und Streams.
Zuvor ermöglichte eine implizite Regel, alle Geräte zu verbinden, die mit demselben HAL-Modul verbunden waren. Dadurch konnte die Audiorichtlinie keine Verbindungen steuern, die über Audio Patch APIs angefordert wurden. Im XML-Format werden in der Topologiebeschreibung Verbindungseinschränkungen definiert.
Durch die Unterstützung von includes müssen keine Standarddefinitionen für A2DP, USB oder Weiterleitungen wiederholt werden.
Lautstärkekurven können angepasst werden. Bisher wurden Volumentabellen hartcodiert. Im XML-Format werden Volumentabellen beschrieben und können angepasst werden.
In der Vorlage unter frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml sind viele dieser Funktionen zu sehen.
Dateiformat und Speicherort
Die neue Konfigurationsdatei für die Audiorichtlinien heißt audio_policy_configuration.xml und befindet sich unter /system/etc. Die folgenden Beispiele zeigen eine einfache Audiorichtlinienkonfiguration im XML-Dateiformat für Android 12 und für die Versionen unter Android 12.
Beispiel für eine Audiorichtlinie für Android 12 anzeigen
Die oberste Struktur 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 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 Adress- und Audioeigenschaften, falls relevant).
Routes ist vom Mix-Port-Beschreibungsblock getrennt, sodass Routen von Gerät zu Gerät oder 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 Dezibel umgewandelt wird. Eine separate Include-Datei enthält Standardkurven. Jede Kurve für einen bestimmten Anwendungsfall und eine Gerätekategorie kann jedoch überschrieben werden.
Mit der XInclude-Methode (XML Inclusions) können Konfigurationsinformationen für Audiorichtlinien aus anderen XML-Dateien eingefügt werden. Alle enthaltenen Dateien müssen der oben beschriebenen Struktur mit den folgenden Einschränkungen entsprechen:
Dateien dürfen nur Elemente der obersten Ebene enthalten.
Dateien dürfen keine XInclude-Elemente enthalten.
Außerdem wird dadurch vermieden, dass Informationen zu den Standardkonfigurationen des Audio-HAL-Moduls von Android Open Source Project (AOSP) in alle Konfigurationsdateien der Audiorichtlinien kopiert werden müssen, was zu Fehlern führen kann. Für die folgenden Audio-HALs wird eine standardmäßige XML-Konfigurationsdatei für Audiorichtlinien bereitgestellt:
A2DP:a2dp_audio_policy_configuration.xml
Submix neu leiten:rsubmix_audio_policy_configuration.xml
USB:usb_audio_policy_configuration.xml
Organisation von Audiorichtliniencode
AudioPolicyManager.cpp ist in mehrere Module unterteilt, 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 für alle Apps gemeinsam sind. Ähnlich wie AudioPolicyManager.cpp, bei der Engine-Funktionen und allgemeine Konzepte abstrahiert sind.
/common
Hier werden Basisklassen definiert, z. B. Datenstrukturen für Audiostream-Profile für Eingabe und Ausgabe, Audiogerätebeschreibungen, Audio-Patches und Audioports. Dieser wurde zuvor in AudioPolicyManager.cpp definiert.
/engine
Hier werden die Regeln implementiert, die festlegen, welches Gerät und welche Volumes für einen bestimmten Anwendungsfall verwendet werden sollen. Es implementiert eine Standardschnittstelle mit dem generischen Teil, z. B. um das richtige Gerät für einen bestimmten Wiedergabe- oder Aufnahmefall zu erhalten oder verbundene Geräte oder den externen Status (d. h. einen Anrufstatus der erzwungenen Nutzung) festzulegen, der die Routingentscheidung ändern kann.
Implementierung der Richtlinien-Engine, die auf dem Parameter-Framework basiert (siehe unten).
Die Konfiguration basiert auf dem Parameter Framework und dort, wo die Richtlinie durch XML-Dateien definiert wird.
/enginedefault
Richtlinien-Engine-Implementierung, die auf früheren Implementierungen des Android Audio Policy Managers basiert. Dies ist die Standardeinstellung und umfasst hartcodierte Regeln, die Nexus- und AOSP-Implementierungen entsprechen.
/service
Umfasst Binder-Schnittstellen, Threading und Sperren-Implementierung mit der Schnittstelle zum Rest des Frameworks.
Konfiguration mit dem Parameter-Framework
Der Code für Audiorichtlinien ist so organisiert, dass er leicht verständlich und zu verwalten ist. Außerdem wird eine Audiorichtlinie unterstützt, die vollständig durch Konfigurationsdateien definiert ist. Die Organisation und das Design der Audiorichtlinien basieren auf dem Parameter-Framework von Intel, einem Plug-in- und regelbasierten Framework für die Parameterverwaltung.
Mit der konfigurierbaren Audiorichtlinie können Anbieter und OEMs Folgendes tun:
Struktur und Parameter eines Systems in XML beschreiben
Erstellen Sie (in C++) oder verwenden Sie ein Back-End (Plug-in), um auf die beschriebenen Parameter zuzugreifen.
Definieren Sie (in XML oder in einer domänenspezifischen Sprache) Bedingungen/Regeln, unter denen ein bestimmter Parameter einen bestimmten Wert haben 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 verwendet. Weitere Informationen finden Sie in der Intel-Dokumentation zum Parameter-Framework.
Unter Android 10 oder niedriger wird die konfigurierbare Audiorichtlinie über die Build-Option USE_CONFIGURABLE_AUDIO_POLICY ausgewählt.
Unter Android 11 oder höher wird die Version der Audiorichtlinien-Engine in der Datei audio_policy_configuration.xml ausgewählt.
Zum Auswählen der konfigurierbaren Audiorichtlinien-Engine legen Sie den Wert des Attributs engine_library des Elements globalConfiguration wie im folgenden Beispiel auf configurable fest:
Mit Android 6.0 wurde eine öffentliche Enumeration and Selection API eingeführt, die auf der Audio-Patch-/Audio-Port-Infrastruktur basiert und es App-Entwicklern ermöglicht, eine Präferenz für eine bestimmte Geräteausgabe oder ‑eingabe für verbundene Audiodatensätze oder ‑tracks anzugeben.
Unter 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 Routingmethoden ersetzt, kombiniert und veraltet, die für die Klassen AudioTrack und AudioRecord spezifisch waren.
Weitere Informationen zur Enumeration and Selection API finden Sie unter Android-Konfigurationsoberflächen und OpenSLES_AndroidConfiguration.h.
Weitere Informationen zum Audio-Routing finden Sie unter AudioRouting.
Support über 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-Mischer umgangen, damit er nicht auf zwei Kanäle heruntergemischt wird. Die Audio-HAL muss angeben, ob ein Ausgabestream-Profil Mehrkanal-Audiofunktionen unterstützt. Wenn der HAL seine Funktionen offenlegt, erlaubt der Standardrichtlinienmanager die Mehrkanalwiedergabe über HDMI. Einzelheiten zur Implementierung finden Sie unter device/samsung/tuna/audio/audio_hw.c.
Wenn Sie angeben möchten, dass Ihr Produkt einen mehrkanaligen Audioausgang hat, bearbeiten Sie die Konfigurationsdatei der Audiorichtlinie, um die mehrkanalige Ausgabe 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. Das bedeutet, dass der Audio Policy Manager nach der Verbindung die vom HDMI-Sink unterstützten Kanalmasken abfragt.
Beispiel für die HDMI-Gerätekonfiguration anzeigen
Sie können auch eine statische Kanalmaske wie AUDIO_CHANNEL_OUT_5POINT1 angeben. Der AudioFlinger-Mixer 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 Audiocodecs, die von Ihrer Hardware und Ihren Treibern unterstützt werden, für Ihr Produkt korrekt deklariert sind. Weitere Informationen finden Sie unter Codecs für das Framework freigeben.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.