Kombiniertes Audiogeräte-Routing

Die Funktion für das kombinierte Audio-Geräterouting bietet Unterstützung für das gleichzeitige Streamen von Audioinhalten auf 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 mithilfe der öffentlichen APIs dieser Funktion genauer ermitteln. Bei Android-Versionen 11 und niedriger werden mehrere Audiogeräte desselben Typs (z. B. zwei Bluetooth-A2DP-Headsets), die gleichzeitig verbunden sind, nur eingeschränkt unterstützt. Die Standardregeln für das Audio-Routing erlauben es Nutzern auch nicht, für einen bestimmten Anwendungsfall mehrere Geräte desselben Typs auszuwählen.

Ab Android 12 werden diese Einschränkungen aufgehoben, um neue Anwendungsfälle wie Audio-Broadcasting, Multicasting an eine Gruppe von BLE-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 Routing zu mehreren USB-Geräten, sofern die USB-Geräte unterschiedliche Audiogerätetypen haben und Kernel- und Vendor-Support für das gleichzeitige Verbinden mehrerer USB-Geräte vorhanden ist.

Auf dieser Seite wird beschrieben, wie du die Unterstützung für das Streamen von Audioinhalten auf mehrere Audiogeräte implementierst und wie du deine Implementierung dieser Funktion validierst.

Streaming von Audio auf mehrere Audiogeräte unterstützen

In Android 12 gibt es zwei API-Sets, 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 Gerätefunktionen.

In den folgenden Abschnitten werden die einzelnen APIs genauer beschrieben.

Mehrere bevorzugte Geräte für eine Strategie verarbeiten

Der Audio Policy Manager bietet System-APIs, um das Streamen von Audioinhalten auf mehrere Audiogeräte gleichzeitig besser zu unterstützen. Mit diesen System-APIs können mehrere bevorzugte Geräte für eine bestimmte Strategie festgelegt, abgerufen und entfernt werden. Bis Android 12 wurde diese Funktion nur für ein einzelnes Gerät unterstützt.

Mit dem Audio Policy Manager wird das Konzept der aktiven Mediengeräte eingeführt, 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 in diesem Kontext Ausgabestreams 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:

  1. Wenn alle bevorzugten Geräte für Medien verfügbar sind, werden sie alle als aktive Geräte ausgewählt.
  2. Andernfalls wird das zuletzt verbundene Wechselspeichermedium ausgewählt.
  3. Wenn keine Wechseldatenträger angeschlossen sind, werden die Standardregeln für die Audioausgaberichtlinie angewendet, um aktive Geräte auszuwählen.

Ein Ausgabestream muss die folgenden Kriterien erfüllen, damit er wieder geöffnet und an die aktiven Geräte weitergeleitet wird und 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.

Damit eine neue Geräteauswahl angewendet werden kann, schließt der Audio Policy Manager bei einer Geräteverbindung einen Ausgabestream und öffnet ihn wieder, wenn der Ausgabestream im Leerlauf ist. Andernfalls wird die neue Geräteauswahl auf den Standby-Modus des Ausgabestreams verschoben.

Der Audio Policy Manager bietet die folgende Liste von System-APIs(wie in AudioManager.java definiert):

  • setPreferredDeviceForStrategy

    Legt das bevorzugte Gerät für das Audio-Routing für eine bestimmte Strategie fest. Hinweis: Das Gerät ist möglicherweise nicht verfügbar, wenn das bevorzugte Gerät festgelegt wird. Es wird jedoch verwendet, sobald es verfügbar ist.

  • removePreferredDeviceForStrategy

    Entfernt die bevorzugten Audiogeräte, die zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegt wurden.

  • getPreferredDeviceForStrategy

    Gibt das bevorzugte Gerät für eine Audiostrategie zurück, die zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegt wurde.

  • setPreferredDevicesForStrategy

    Legt die bevorzugten Geräte für eine bestimmte Strategie fest.

  • getPreferredDevicesForStrategy

    Gibt die bevorzugten Geräte für eine Audiostrategie zurück, die zuvor mit setPreferredDeviceForStrategy oder setPreferredDevicesForStrategy festgelegt wurde.

  • OnPreferredDevicesForStrategyChangedListener

    Definiert eine Schnittstelle für Benachrichtigungen über Änderungen an den bevorzugten Audiogeräten, die für eine bestimmte Audiostrategie festgelegt sind.

  • addOnPreferredDevicesForStrategyChangedListener

    Fügt einen Listener hinzu, der über Änderungen am bevorzugten Audiogerät der Strategie benachrichtigt wird.

  • removeOnPreferredDevicesForStrategyChangedListener

    Entfernt einen zuvor hinzugefügten Listener für Änderungen am bevorzugten Audio-Gerät der Strategie.

Gerätefunktionen melden

Im Rahmen der Audio HAL-Implementierung implementieren Anbieter die APIs, die das Melden von Gerätefunktionen unterstützen. In diesem Abschnitt werden die Datentypen und Methoden beschrieben, die zum Melden von Gerätefunktionen verwendet werden. Außerdem werden einige Änderungen aufgeführt, die im Audio-HIDL-HAL V7 vorgenommen wurden, um mehrere Geräte zu unterstützen.

Datentypen

Im Audio-HIDL-HAL V7 werden Gerätefunktionen mit den Strukturen AudioProfile und AudioTransport gemeldet. Die AudioTransport-Struktur beschreibt die Funktion eines Audioanschlusses mit AudioProfile für bekannte Audioformate oder mit Roh-Hardware-Deskriptoren 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 Channelmasken, wie im folgenden Codeblock aus types.hal zu sehen ist:

/**
* 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;
};

Im 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 anbieterspezifischer Parameterwerte wie unterstützte Audioformate und ihre jeweiligen Samplingraten.
  • getAudioPort:Gibt die Liste der unterstützten Attribute (z. B. Samplingraten, Formate, Channel-Masken, Verstärkungsregler) für einen bestimmten Audio-Port zurück.

Der folgende Code aus IDevice.hal zeigt die Schnittstelle für die Methode getAudioPort:

   /**
    * 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 Legacy-API eine neue Struktur namens audio_port_v7 eingeführt. Weitere Informationen finden Sie im Quellcode.

Durch das Hinzufügen von audio_port_v7 wird in Version 3.2 der alten API eine neue API namens get_audio_port_v7 eingeführt, mit der die Funktionen von Geräten mithilfe der audio_port_v7-Struktur abgefragt werden können.

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 übertragen werden, wenn die alte API-Version unter 3.2 und die HIDL HAL-Version 7 oder höher ist. In diesem Fall wird davon ausgegangen, dass alle gemeldeten Sampleraten und Channelmasken aus get_audio_port für alle zurückgegebenen Formate unterstützt werden. So ist eine einfache Zuordnung von get_audio_port-Werten zur neuen AudioPort-Struktur möglich.

Beispiele für API-Implementierungen

In diesem Abschnitt werden mehrere Testsuiten mit Methoden beschrieben, 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-APIs setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy und OnPreferredDevicesForStrategyChangedListener finden Sie in der Methode PreferredDeviceRoutingTest in GTS.

Ein Beispiel für die Verwendung der neuen Struktur in AudioDeviceInfo finden Sie in der Methode AudioManagerTest#testGetDevices im CTS.

Ein Beispiel für die Implementierung für get_audio_port_v7 finden Sie 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-Validierung (Google Mobile Services Test Suite) des Audio Manager.

CTS-Tests

CTS-Tests befinden sich in android.media.cts.AudioManagerTest.

Die folgende Liste zeigt die verfügbaren Audio Manager-Tests:

  • AudioManagerTest#testGetDevices

    Prüft die genauen Funktionen des Audiogeräts. Außerdem wird geprüft, ob die zurückgegebenen Audioprofile in der Struktur AudioDeviceInfo den Inhalt des alten, zusammengeführten Arrayformats beibehalten, aber im neuen Format AudioProfile vorliegen.

  • AudioManagerTest#testPreferredDevicesForStrategy und AudioManagerTest#testPreferredDeviceForCapturePreset

    Prüfen Sie, ob die API-Tests für die bevorzugten Geräte für Strategie- und Capture-Voreinstellungen erfolgreich abgeschlossen wurden.

GTS-Tests

GTS-Tests befinden sich in 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 die Strategie- und Erfassungs-Voreinstellung richtig funktionieren.