Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die Android 10-Version beinhaltet eine wesentliche Umgestaltung 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 älterer Stream-Typen, die dieselben Volumenkurven verwenden.
Routing-Strategien werden von der Audio-Richtlinien-Engine deklariert und nicht fest codiert.
Von der Audio-Richtlinien-Engine verwaltete Lautstärkekurven und -gruppen.
Internes Refactoring bereitet auf eine zukünftige Aufteilung zwischen allgemeinem Code und konfigurierbarem Code vor und bietet eine umfassendere Audiogeräteverwaltung. Beispielsweise die Verwendung aller Geräteeigenschaften, nicht nur ihres Typs, in Richtlinienregeln.
Mit Android 7.0 wurde 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 ). Allerdings ist CONF ein einfaches, proprietäres Format, das zu begrenzt ist, um komplexe Topologien für Branchen wie Fernseher und Autos zu beschreiben.
Android 7.0 hat 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 an Bearbeitungs- und Analysetools verfügt 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 ermöglicht die XML-Datei die Definition der Anzahl und Art der Ausgabe- und Eingabestream-Profile, der für die Wiedergabe und Aufnahme verwendbaren Geräte sowie der 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 Parallelitätssituation abgelehnt.
Der Rückruf registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) benachrichtigt Clients über Änderungen des Erfassungspfads.
In den folgenden Situationen erhält ein Client stille Audiobeispiele:
Ein datenschutzrelevanter Anwendungsfall (z. B. VOICE_COMMUNICATION ) ist aktiv.
Der Client verfügt weder über einen Vordergrunddienst noch über eine Vordergrund-Benutzeroberfläche.
Besondere Rollen werden von der Richtlinie anerkannt:
Barrierefreiheitsdienst: Kann auch dann aufzeichnen, wenn ein datenschutzrelevanter Anwendungsfall aktiv ist.
Assistent: Gilt als datenschutzrelevant, 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 eine implizite Regel die Verbindung aller an dasselbe HAL-Modul angeschlossenen Geräte, wodurch verhindert wurde, dass die Audiorichtlinie die mit Audio-Patch-APIs angeforderten Verbindungen steuerte. Im XML-Format definiert die Topologiebeschreibung Verbindungsbeschränkungen.
Durch die Unterstützung von Includes wird die Wiederholung von standardmäßigen A2DP-, USB- oder Reroute-Submit-Definitionen vermieden.
Volumenkurven sind anpassbar. Zuvor waren Volumentabellen fest codiert. Im XML-Format werden Volumentabellen beschrieben und können individuell angepasst werden.
Die Vorlage unter frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml zeigt viele dieser verwendeten Funktionen.
Dateiformat und Speicherort
Die neue Audiorichtlinien-Konfigurationsdatei heißt 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.
Beispiel für eine Audiorichtlinie für Android 12 anzeigen
Die Struktur der obersten Ebene enthält Module, die jedem Audio-HAL-Hardwaremodul entsprechen, wobei jedes Modul über eine Liste von Mix-Ports, Geräte-Ports und Routen verfügt:
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 mit ihrem Typ (und optional Adress- und Audioeigenschaften, falls relevant) angeschlossen werden können.
Routen sind vom Mix-Port-Deskriptor getrennt und ermöglichen die Beschreibung von Routen von Gerät zu Gerät oder Stream zu Gerät.
Lautstärketabellen sind einfache Listen von Punkten, die die Kurve definieren, die zur Übersetzung von einem UI-Index in eine Lautstärke in dB verwendet wird. Eine separate Include-Datei stellt Standardkurven bereit, aber jede Kurve für einen bestimmten Anwendungsfall und eine bestimmte Gerätekategorie kann überschrieben werden.
Die Methode „XML Inclusions“ (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 den folgenden Einschränkungen folgen:
Dateien können nur Elemente der obersten Ebene enthalten.
Dateien dürfen keine XInclude-Elemente enthalten.
Die Verwendung umfasst das Vermeiden des Kopierens von Standard-Audio-HAL-Modulkonfigurationsinformationen des Android Open Source Project (AOSP) in alle Audiorichtlinien-Konfigurationsdateien (was fehleranfällig ist). Für die folgenden Audio-HALs wird eine standardmäßige XML-Konfigurationsdatei für Audiorichtlinien bereitgestellt:
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 allgemeinen 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 Eingabe-Ausgabe-Audiostream-Profile, Audiogerätedeskriptoren, Audio-Patches und Audio-Ports). Dies wurde zuvor in AudioPolicyManager.cpp definiert.
/engine
Implementiert die Regeln, die definieren, welche Geräte und Volumes für einen bestimmten Anwendungsfall verwendet werden sollen. Es implementiert eine Standardschnittstelle mit dem generischen Teil, um beispielsweise das entsprechende Gerät für einen bestimmten Wiedergabe- oder Aufnahmeanwendungsfall abzurufen oder um verbundene Geräte oder einen externen Status (d. h. einen Anrufstatus mit erzwungener 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
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 Android Audio Policy Manager-Implementierungen. Dies ist die Standardeinstellung und umfasst hartcodierte Regeln, die den Nexus- und AOSP-Implementierungen entsprechen.
/service
Beinhaltet Binderschnittstellen, Threading und Sperrimplementierung mit der Schnittstelle zum Rest des Frameworks.
Konfiguration mit Parameter Framework
Der Audiorichtliniencode ist so organisiert, dass er leicht zu verstehen und zu verwalten ist und gleichzeitig eine Audiorichtlinie unterstützt, die vollständig durch Konfigurationsdateien definiert wird. Das Design der Organisations- und Audiorichtlinien basiert auf dem Parameter Framework von Intel, einem Plugin-basierten und regelbasierten Framework für den Umgang mit Parametern.
Mithilfe der konfigurierbaren Audiorichtlinie können OEMs von Anbietern Folgendes tun:
Beschreiben Sie die Struktur eines Systems und seine Parameter in XML.
Schreiben Sie (in C++) oder verwenden Sie ein Backend (Plugin) für den Zugriff auf beschriebene Parameter wieder.
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 einer Audiorichtlinien-Konfigurationsdatei, die das Parameter Framework unter Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml verwendet. Einzelheiten finden Sie in der Intel-Dokumentation zum Parameter Framework .
In Android 10 oder niedriger wird die konfigurierbare Audiorichtlinie mithilfe 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:
Mit Android 6.0 wurde eine öffentliche Enumerations- und Auswahl-API eingeführt, die sich über der Audio-Patch-/Audio-Port-Infrastruktur befindet 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 Enumeration and Selection API durch CTS-Tests verifiziert und um Routing für native C/C++ (OpenSL ES)-Audiostreams erweitert. Das Routing nativer Streams erfolgt weiterhin in Java, mit der Hinzufügung einer AudioRouting Schnittstelle, die die expliziten Routing-Methoden, die für die Klassen AudioTrack und AudioRecord spezifisch waren, ersetzt, kombiniert und veraltet.
Einzelheiten zur Enumerations- und Auswahl-API finden Sie unter Android-Konfigurationsschnittstellen und OpenSLES_AndroidConfiguration.h . Einzelheiten zum Audio-Routing finden Sie unter AudioRouting .
Mehrkanalunterstützung
Wenn Ihre Hardware und Ihr Treiber Mehrkanal-Audio über HDMI unterstützen, können Sie den Audiostream direkt an die Audio-Hardware ausgeben (dadurch wird der AudioFlinger-Mixer umgangen, sodass er nicht auf zwei Kanäle heruntergemischt wird). Die Audio-HAL muss offenlegen, ob ein Ausgabestream-Profil vorhanden ist unterstützt Mehrkanal-Audiofunktionen. Wenn der HAL seine Fähigkeiten offenlegt, ermöglicht der Standardrichtlinienmanager 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 Mehrkanal-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, was bedeutet, dass der Audio-Richtlinienmanager nach der Verbindung die von der HDMI-Senke unterstützten Kanalmasken abfragt.
Beispiel für die Konfiguration eines HDMI-Geräts anzeigen
Sie können auch eine statische Kanalmaske wie AUDIO_CHANNEL_OUT_5POINT1 angeben. Der Mixer von AudioFlinger mischt den Inhalt automatisch auf Stereo herunter, wenn er an ein Audiogerät gesendet wird, das kein Mehrkanal-Audio unterstützt.
Mediencodecs
Stellen Sie sicher, dass die von Ihrer Hardware und Ihren Treibern unterstützten Audio-Codecs für Ihr Produkt ordnungsgemäß deklariert sind. Einzelheiten finden Sie unter Verfügbarmachen von Codecs für das Framework .
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.