Die kombinierte Audiogeräte-Routing-Funktion bietet Unterstützung für das gleichzeitige Streamen von Audio an mehrere Audiogeräte. Mit dieser Funktion können privilegierte Apps über System-APIs mehrere bevorzugte Geräte für eine bestimmte Strategie auswählen. Apps können die Funktionen von Audiogeräten genauer erkennen, indem sie die von dieser Funktion bereitgestellten öffentlichen APIs verwenden. Für Android-Versionen 11 und niedriger bietet die Audio-Framework-Implementierung begrenzte Unterstützung für mehrere gleichzeitig verbundene Audiogeräte desselben Typs (z. B. 2 Bluetooth-A2DP-Headsets). Die standardmäßigen Audio-Routing-Regeln erlauben es Benutzern außerdem nicht, für einen bestimmten Anwendungsfall mehrere Geräte desselben Typs auszuwählen.
Ab Android 12 werden diese Einschränkungen entfernt, um neue Anwendungsfälle wie Audioübertragung, Multicasting an eine Gruppe von BLE-Audiokopfhörern oder die gleichzeitige Auswahl mehrerer USB-Soundkarten zu ermöglichen. Das gleichzeitige Routing an mehrere USB-Geräte wird nicht unterstützt.
Ab Android 14 unterstützt das USB-Framework das Routing zu mehreren USB-Geräten, sofern es sich bei den USB-Geräten um unterschiedliche Audiogerätetypen handelt und es Kernel- und Herstellerunterstützung für den gleichzeitigen Anschluss mehrerer USB-Geräte gibt.
Auf dieser Seite erfahren Sie, wie Sie die Unterstützung für das Streamen von Audio auf mehrere Audiogeräte implementieren und wie Sie Ihre Implementierung dieser Funktion validieren.
Unterstützt das Streamen von Audio auf mehrere Audiogeräte
Es gibt zwei Sätze von APIs in Android 12, die diese Funktion unterstützen:
- Die System-APIs verwalten mehrere bevorzugte Geräte für eine Strategie.
- Die vom Anbieter als Teil des Audio-HAL implementierte HIDL-Schnittstelle meldet Gerätefunktionen.
In den folgenden Abschnitten wird jede dieser APIs ausführlicher erläutert.
Behandeln Sie mehrere bevorzugte Geräte für eine Strategie
Der Audio Policy Manager bietet System-APIs, um das gleichzeitige Streamen von Audio auf mehrere Audiogeräte besser zu unterstützen. Diese System-APIs ermöglichen das Festlegen, Abrufen und Entfernen mehrerer bevorzugter Geräte für eine bestimmte Strategie. 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 überprüft werden.
Beim Öffnen eines Ausgabestreams muss ein Audiogerät angegeben werden. Das aktive Mediengerät ist das Gerät, das verwendet wird, wenn in diesem Kontext Ausgabestreams geöffnet werden.
Die Auswahl des aktiven Mediengeräts kann sich abhängig von den tatsächlich angeschlossenen 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 Wechselgeräte angeschlossen sind, werden die Standard-Audiorichtlinienregeln für die Auswahl von Ausgabegeräten auf die Auswahl aktiver Geräte angewendet.
Ein Ausgabestream muss die folgenden Kriterien erfüllen, um erneut 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 der Audio Policy Manager einen Ausgabestream bei der Geräteverbindung und öffnet ihn erneut, wenn der Ausgabestream inaktiv ist, oder verschiebt ihn, bis der Ausgabestream in den Standby-Modus versetzt wird.
Der Audio Policy Manager bietet die folgende Liste von System-APIs (wie in AudioManager.java definiert):
setPreferredDeviceForStrategyLegt das bevorzugte Gerät für das Audio-Routing für eine bestimmte Strategie fest. Beachten Sie, dass das Gerät zum Zeitpunkt der Einstellung des bevorzugten Geräts möglicherweise nicht verfügbar ist, aber verwendet wird, sobald es verfügbar ist.
removePreferredDeviceForStrategyEntfernt die bevorzugten Audiogeräte, die zuvor mit
setPreferredDeviceForStrategyodersetPreferredDevicesForStrategyfestgelegt wurden.getPreferredDeviceForStrategyGibt das bevorzugte Gerät für eine Audiostrategie zurück, die zuvor mit
setPreferredDeviceForStrategyodersetPreferredDevicesForStrategyfestgelegt wurde.setPreferredDevicesForStrategyLegt 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 zur Benachrichtigung über Änderungen an den bevorzugten Audiogeräten, die für eine bestimmte Audiostrategie festgelegt sind.
addOnPreferredDevicesForStrategyChangedListenerFügt einen Listener hinzu, um über Änderungen am von der Strategie bevorzugten Audiogerät benachrichtigt zu werden.
removeOnPreferredDevicesForStrategyChangedListenerEntfernt einen zuvor hinzugefügten Listener von Änderungen am von der Strategie bevorzugten Audiogerät.
Gerätefunktionen melden
Im Rahmen der Audio-HAL-Implementierung implementieren Anbieter die APIs, die Berichtsgerätefunktionen unterstützen. In diesem Abschnitt werden die Datentypen und Methoden erläutert, die zum Melden von Gerätefunktionen verwendet werden, und einige Änderungen aufgeführt, die in Audio HIDL HAL V7 vorgenommen wurden, um mehrere Geräte zu unterstützen.
Datentypen
In Audio HIDL HAL V7 werden Gerätefunktionen mithilfe der Strukturen AudioProfile und AudioTransport gemeldet. Die AudioTransport Struktur beschreibt die Fähigkeit eines Audio-Ports mit AudioProfile für bekannte Audioformate oder mit rohen Hardware-Deskriptoren für Formate, die der Plattform nicht bekannt sind. Die AudioProfile Struktur enthält das Audioformat, die vom Profil unterstützten Abtastraten und die Liste der Kanalmasken, wie im folgenden Codeblock types.hal :
/**
* 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 Audio HIDL HAL V7 wird der AudioPort Datentyp 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 Fähigkeiten des Geräts abzufragen:
-
getParameters:Eine generische Methode zum Abrufen herstellerspezifischer Parameterwerte wie unterstützter Audioformate und ihrer jeweiligen Abtastraten. -
getAudioPort:Gibt die Liste der unterstützten Attribute (wie Abtastraten, Formate, Kanalmasken, Verstärkungsregler) für einen bestimmten Audio-Port 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
Um mehrere Audioprofile zu unterstützen, fügt Version 3.2 der Legacy-API eine neue Struktur namens audio_port_v7 hinzu. Weitere Einzelheiten finden Sie im Quellcode .
Aufgrund der Hinzufügung von audio_port_v7 fügt Version 3.2 der Legacy-API eine neue API namens get_audio_port_v7 hinzu, um die Funktionen von Geräten mithilfe der audio_port_v7 Struktur abzufragen.
Der folgende Code von 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 eingefügt werden, wenn die alte API-Version niedriger als 3.2 und die HIDL-HAL-Version 7 oder höher ist. In diesem Fall wird davon ausgegangen, dass alle von get_audio_port gemeldeten Abtastraten und Kanalmasken für alle zurückgegebenen Formate unterstützt werden, was eine einfache Zuordnung von get_audio_port -Werten zur neuen AudioPort Struktur ermöglicht.
Beispiel-API-Implementierungen
In diesem Abschnitt werden mehrere Testsuiten beschrieben, die Methoden enthalten, die die in den vorherigen Abschnitten behandelten APIs verwenden. In diesen Methoden finden Sie einige Beispiele für die Implementierung und Verwendung dieser APIs.
Ein Beispiel für die Verwendung der System- setPreferredDevicesForStrategy “, „ getPreferredDevicesForStrategy , removePreferredDeviceForStrategy “ und „ OnPreferredDevicesForStrategyChangedListener “ ist die Methode PreferredDeviceRoutingTest “, die sich in GTS befindet.
Ein Beispiel für die verwendete neue Struktur in AudioDeviceInfo finden Sie in der Methode AudioManagerTest#testGetDevices , die sich in CTS befindet.
Ein Beispiel für die Implementierung für get_audio_port_v7 befindet sich in audio_hal.c und zeigt, wie Funktionen für mehrere Geräte abgefragt werden.
Validierung
Dieser Abschnitt enthält Informationen zur CTS- und GTS-Validierung (Google Mobile Services Test Suite) des Audio Managers.
CTS-Tests
CTS-Tests befinden sich in android.media.cts.AudioManagerTest .
Im Folgenden finden Sie die Liste der verfügbaren Audio Manager-Tests:
AudioManagerTest#testGetDevicesÜberprüft die genauen Fähigkeiten des Audiogeräts. Außerdem wird überprüft, ob die zurückgegebenen Audioprofile in der
AudioDeviceInfoStruktur den Inhalt des älteren, abgeflachten Array-Formats beibehalten, aber im neuenAudioProfileFormat vorliegen.AudioManagerTest#testPreferredDevicesForStrategyundAudioManagerTest#testPreferredDeviceForCapturePresetStellen Sie sicher, dass die bevorzugten Geräte für die Strategie- und Capture-Voreinstellungen zu API-Tests erfolgreich abgeschlossen werden.
GTS-Tests
GTS-Tests befinden sich in com.google.android.gts.audioservice.AudioServiceHostTest .
Um zu überprüfen, ob die APIs für bevorzugte Geräte für Strategie und Aufnahmevoreinstellung ordnungsgemäß funktionieren, führen Sie die Tests AudioServiceHostTest#testPreferredDeviceRouting und AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset aus.