Die kombinierte Audiogeräte-Routing-Funktion unterstützt das Streaming von Audio auf mehrere Audiogeräte gleichzeitig. Mit dieser Funktion können berechtigte Apps über System-APIs mehrere bevorzugte Geräte für eine bestimmte Strategie auswählen. Mithilfe der öffentlichen APIs, die von dieser Funktion bereitgestellt werden, können Apps die Funktionen von Audiogeräten genauer ermitteln. Bei Android-Versionen 11 und niedriger unterstützt die Audio-Framework-Implementierung nur eingeschränkt die gleichzeitige Verbindung mehrerer Audiogeräte desselben Typs (z. B. zwei Bluetooth-A2DP-Headsets). Mit den Standardregeln für die Audioweiterleitung können Nutzer auch nicht mehrere Geräte desselben Typs für einen bestimmten Anwendungsfall auswählen.
Ab Android 12 werden diese Einschränkungen aufgehoben, um neue Anwendungsfälle wie Audioübertragung, Multicasting an eine Gruppe von BLE-Audio-Kopfhörern oder die gleichzeitige Auswahl mehrerer USB-Soundkarten zu ermöglichen. Das gleichzeitige Weiterleiten an mehrere USB-Geräte wird nicht unterstützt.
Ab Android 14 unterstützt das USB-Framework das Weiterleiten an mehrere USB-Geräte, sofern es sich um USB-Geräte verschiedener Audiogerätetypen handelt und der Kernel und der Anbieter die gleichzeitige Verbindung mehrerer USB-Geräte unterstützen.
Auf dieser Seite erfahren Sie, wie Sie die Unterstützung für das Streaming von Audio auf mehrere Audiogeräte implementieren und wie Sie die Implementierung dieser Funktion validieren.
Unterstützung für das Streamen von Audio auf mehrere Audiogeräte
In Android 12 gibt es zwei APIs, die diese Funktion unterstützen:
- Die System-APIs verarbeiten mehrere bevorzugte Geräte für eine Strategie.
- Die HIDL-Schnittstelle, die vom Anbieter als Teil der Audio-HAL implementiert wird, meldet die Gerätefunktionen.
In den folgenden Abschnitten werden diese APIs genauer beschrieben.
Mehrere bevorzugte Geräte für eine Strategie verwenden
Der Audio Policy Manager bietet System-APIs, um das Streaming von Audio auf mehrere Audiogeräte gleichzeitig besser zu unterstützen. Mit diesen System-APIs können Sie mehrere bevorzugte Geräte für eine bestimmte Strategie festlegen, abrufen und entfernen. Bis Android 12 wurde diese Funktion nur für ein einzelnes Gerät unterstützt.
Der Audio Policy Manager führt das Konzept aktiver Mediengeräte ein, um die Geräte zu beschreiben, die am wahrscheinlichsten für die Medienwiedergabe ausgewählt werden. Wenn ein abnehmbares Gerät angeschlossen ist, müssen die Audio-HAL-Ausgabestreams, die an dieses Gerät weitergeleitet werden können, möglicherweise geöffnet und auf unterstützte Attribute geprüft werden.
Beim Öffnen eines Ausgabestreams muss ein Audiogerät angegeben werden. Das aktive Mediengerät ist das Gerät, das verwendet wird, wenn Ausgabestreams in diesem Kontext geöffnet werden.
Die Auswahl des aktiven Mediengeräts kann sich je nach den tatsächlich verbundenen oder getrennten Geräten ändern. Der Audio Policy Manager verwendet die folgenden Regeln, um aktive Mediengeräte auszuwählen:
- Wenn alle bevorzugten Geräte für Medien verfügbar sind, werden sie alle als aktive Geräte ausgewählt.
- Andernfalls wird das zuletzt verbundene Wechseldatenträger ausgewählt.
- Wenn keine Wechseldatenträger angeschlossen sind, werden die Standardregeln der Audiorichtlinien für die Auswahl von Ausgabegeräten angewendet, um aktive Geräte auszuwählen.
Ein Ausgabestream muss die folgenden Kriterien erfüllen, um wieder geöffnet und an die aktiven Geräte weitergeleitet zu werden, damit die beste Konfiguration für die Wiedergabe ausgewählt wird:
- Der Ausgabestream muss die aktiven Geräte unterstützen.
- Der Ausgabestream muss dynamische Profile unterstützen.
- Der Ausgabestream darf derzeit nicht an aktive Geräte weitergeleitet werden.
Um eine neue Geräteauswahl anzuwenden, schließt und öffnet der Audio Policy Manager einen Ausgabestream bei der Geräteverbindung, wenn der Ausgabestream inaktiv ist, oder verschiebt die Anwendung auf den Zeitpunkt, zu dem der Ausgabestream in den Ruhemodus versetzt wird.
Der Audio Policy Manager bietet die folgende Liste von System-APIs(wie in AudioManager.java definiert):
setPreferredDeviceForStrategyHier legen Sie das bevorzugte Gerät für die Audioweiterleitung für eine bestimmte Strategie fest. Das Gerät ist möglicherweise nicht verfügbar, wenn Sie das bevorzugte Gerät festlegen. Es wird jedoch verwendet, sobald es verfügbar ist.
removePreferredDeviceForStrategyDie bevorzugten Audiogeräte, die zuvor mit
setPreferredDeviceForStrategyodersetPreferredDevicesForStrategyfestgelegt wurden, werden entfernt.getPreferredDeviceForStrategyGibt das bevorzugte Gerät für eine Audiostrategie zurück, die zuvor mit
setPreferredDeviceForStrategyodersetPreferredDevicesForStrategyfestgelegt wurde.setPreferredDevicesForStrategyHier legen Sie die bevorzugten Geräte für eine bestimmte Strategie fest.
getPreferredDevicesForStrategyGibt die bevorzugten Geräte für eine Audiostrategie zurück, die zuvor mit
setPreferredDeviceForStrategyodersetPreferredDevicesForStrategyfestgelegt wurde.OnPreferredDevicesForStrategyChangedListenerDefiniert eine Schnittstelle für Benachrichtigungen zu Änderungen an den bevorzugten Audiogeräten, die für eine bestimmte Audiostrategie festgelegt sind.
addOnPreferredDevicesForStrategyChangedListenerHiermit wird ein Listener hinzugefügt, um über Änderungen am bevorzugten Audiogerät der Strategie informiert zu werden.
removeOnPreferredDevicesForStrategyChangedListenerEntfernt einen zuvor hinzugefügten Listener für Änderungen am von der Strategie bevorzugten Audiogerät.
Gerätefunktionen melden
Im Rahmen der Audio HAL-Implementierung implementieren Anbieter die APIs, die die Meldung von Gerätefunktionen unterstützen. In diesem Abschnitt werden die Datentypen und Methoden erläutert, die zum Melden von Gerätefunktionen verwendet werden. Außerdem werden einige Änderungen aufgeführt, die in der Audio-HIDL HAL V7 zur Unterstützung mehrerer Geräte vorgenommen wurden.
Datentypen
In der Audio-HIDL HAL V7 werden Gerätefunktionen mit den Strukturen AudioProfile und AudioTransport gemeldet. Die AudioTransport-Struktur beschreibt die Fähigkeiten eines Audioports mit AudioProfile für bekannte Audioformate oder mit Rohhardware-Beschreibungen für Formate, die der Plattform nicht bekannt sind. Die Struktur AudioProfile enthält das Audioformat, die vom Profil unterstützten Abtastraten und die Liste der Kanalmasken, wie im folgenden Codeblock aus types.hal zu sehen:
/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
AudioFormat format;
/** List of the sample rates (in Hz) supported by the profile. */
vec<uint32_t> sampleRates;
/** List of channel masks supported by the profile. */
vec<AudioChannelMask> channelMasks;
};
In der Audio-HIDL HAL V7 wird der Datentyp AudioPort mit den Strukturen AudioTransport und AudioProfile definiert, um die Funktionen des Geräts zu beschreiben.
Audio HAL-Methoden
Der Audio Policy Manager verwendet die folgenden Methoden, um die Funktionen des Geräts abzufragen:
getParameters:Eine generische Methode zum Abrufen von anbieterspezifischen Parameterwerten wie unterstützten Audioformaten und ihren jeweiligen Abtastraten.getAudioPort:Gibt die Liste der unterstützten Attribute (z. B. Abtastrate, Formate, Kanalmasken, Verstärkungsregler) für einen bestimmten Audioport zurück.
Der folgende Code aus IDevice.hal zeigt die Schnittstelle für die getAudioPort-Methode:
/**
* Returns the list of supported attributes for a given audio port.
*
* As input, 'port' contains the information (type, role, address etc...)
* needed by the HAL to identify the port.
*
* As output, 'resultPort' contains possible attributes (sampling rates,
* formats, channel masks, gain controllers...) for this port.
*
* @param port port identifier.
* @return retval operation completion status.
* @return resultPort port descriptor with all parameters filled up.
*/
getAudioPort(AudioPort port)
generates (Result retval, AudioPort resultPort);
Änderungen an der Legacy API
Zur Unterstützung mehrerer Audioprofile wird in Version 3.2 der alten API eine neue Struktur namens audio_port_v7 hinzugefügt. Weitere Informationen finden Sie im Quellcode.
Da audio_port_v7 hinzugefügt wurde, wird in Version 3.2 der alten API eine neue API namens get_audio_port_v7 hinzugefügt, um die Funktionen von Geräten mithilfe der Struktur audio_port_v7 abzufragen.
Der folgende Code aus audio.h zeigt die Definition der get_audio_port_v7 API:
/**
* Fills the list of supported attributes for a given audio port.
* As input, "port" contains the information (type, role, address etc...)
* needed by the HAL to identify the port.
* As output, "port" contains possible attributes (sampling rates,
* formats, channel masks, gain controllers...) for this port. The
* possible attributes are saved as audio profiles, which contains audio
* format and the supported sampling rates and channel masks.
*/
int (*get_audio_port_v7)(struct audio_hw_device *dev,
struct audio_port_v7 *port);
Daten aus der alten get_audio_port API müssen in das neue AudioPort-Format umgewandelt werden, wenn die Version der alten API unter 3.2 liegt und die HIDL HAL-Version 7 oder höher ist. In diesem Fall wird davon ausgegangen, dass alle gemeldeten Abtastrate und Kanalmasken aus get_audio_port für alle zurückgegebenen Formate unterstützt werden. So können get_audio_port-Werte einfach in die neue AudioPort-Struktur zugeordnet werden.
Beispiel-API-Implementierungen
In diesem Abschnitt werden mehrere Testsuites mit Methoden beschrieben, die die in den vorherigen Abschnitten beschriebenen APIs verwenden. In diesen Methoden finden Sie einige Beispiele dafür, wie diese APIs implementiert und verwendet werden.
Ein Beispiel für die Verwendung der System-APIs setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy und OnPreferredDevicesForStrategyChangedListener ist die Methode PreferredDeviceRoutingTest in GTS.
Ein Beispiel für die neue Struktur in AudioDeviceInfo finden Sie in der CTS-Methode AudioManagerTest#testGetDevices.
Ein Beispiel für die Implementierung für get_audio_port_v7 findest du unter audio_hal.c. Dort wird gezeigt, wie Funktionen für mehrere Geräte abgefragt werden.
Zertifizierungsstufe
In diesem Abschnitt finden Sie Informationen zur CTS- und GTS- (Google Mobile Services Test Suite) Validierung des Audiomanagers.
CTS-Tests
CTS-Tests befinden sich unter android.media.cts.AudioManagerTest.
Die folgende Liste enthält die verfügbaren Audio Manager-Tests:
AudioManagerTest#testGetDevicesPrüft die genauen Funktionen des Audiogeräts. Außerdem wird geprüft, ob die zurückgegebenen Audioprofile im
AudioDeviceInfo-Format den Inhalt des älteren, flachen Arrayformats beibehalten, aber im neuenAudioProfile-Format vorliegen.AudioManagerTest#testPreferredDevicesForStrategyundAudioManagerTest#testPreferredDeviceForCapturePresetPrüfen Sie, ob die bevorzugten Geräte für die Strategie und die Aufnahme von vordefinierten API-Tests erfolgreich abgeschlossen wurden.
GTS-Tests
GTS-Tests befinden sich unter com.google.android.gts.audioservice.AudioServiceHostTest.
Führen Sie die Tests AudioServiceHostTest#testPreferredDeviceRouting und AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset aus, um zu prüfen, ob die APIs für bevorzugte Geräte für Strategie und Aufnahmevorlage richtig funktionieren.