Auf dieser Seite wird beschrieben, wie Sie das Audio-Framework und den Audio-HAL (AHAL) aktivieren, um synchrone verbindungsorientierte (SCO-)Verbindungen zu verwalten. Dieser Prozess wird als Audio Managed SCO (AMSCO) bezeichnet.
Unter Android 17 und höher wird das SCO-Routing vom Android-Audio-Framework mithilfe der SCO-Verwaltungsfunktion verwaltet. Zuvor wurde es vom Bluetooth-Framework (BT) übernommen. Bei dieser Migration wird der SCO-Verbindungsstatus von einem Status, der dem BT-Framework gehört, zu einer nachgelagerten Folge von Audio-Streaming-Aktivitäten verschoben.
Durch die Zentralisierung der Audio-Routing-Verantwortung im Audio-Framework wird die Implementierung der Audio-Hardwareabstraktionsschicht (HAL) für SCO an andere Bluetooth-Profile wie A2DP (Advanced Audio Distribution Profile) und LE Audio angeglichen. Durch diese Umgestaltung wird die Interaktion zwischen den Telekom- und BT-Stacks vereinfacht, was eine robustere und zentralisierte Architektur für das Audio-Routing ermöglicht.
Architekturübersicht
Die AMSCO-Architektur zentralisiert die SCO-Verbindungsverwaltung im Android-Audio-Framework, das Routing-Entscheidungen auf Audio-Streaming-Aktivitäten basiert. Diese Architektur unterscheidet sich vom vorherigen Modell, in dem der BT-Stack Verbindungen verwaltet hat. Die Rollen der einzelnen Komponenten in dieser Architektur sind:
Die AHAL startet und unterbricht die SCO-Sitzung nur, wenn die folgenden Bedingungen erfüllt sind:
- Ein aktiver Stream wird an ein SCO-Gerät weitergeleitet.
- Der Audiomodus ist festgelegt und es ist ein Patch für ein SCO-Gerät vorhanden.
Das Audio-Framework verhindert, dass ein A2DP-Gerät gleichzeitig einen Patch hat, wenn diese spezifischen Kriterien erfüllt sind. Das Audio-Framework sendet keine SCO-Statusänderungen oder A2DP-Unterbrechungen mehr an die AHAL.
Das Audio-Framework übernimmt die SCO-Verwaltung, sodass der BT-Stack nicht mehr „connect“ oder „disconnect audio“ aufruft. Bei einer präventiven SCO-Trennung oder einem Fehler informiert der BT-Stack das Audio-Framework mit AudioManager#onHfpAudioDisconnected.
Planen
Anhand der Informationen in diesem Abschnitt können Sie die folgenden Kompatibilitäts- und Architekturvoraussetzungen bewerten, bevor Sie das Refactoring der SCO-Verwaltung implementieren.
Abwärtskompatibilität
Damit das Framework weiterhin Geräte unterstützen kann, die möglicherweise Betriebssystemupdates erhalten, ohne ihre AHALs oder BT-AHALs zu aktualisieren, verwenden Sie eine Systemeigenschaft, um anzugeben, dass die neue SCO-Verwaltung aktiviert werden muss. Der Legacy-Pfad wird bis zu sechs Jahre lang beibehalten, wenn die Systemeigenschaft deaktiviert ist oder die HAL-Version veraltet ist.
HFP-Sitzung einrichten
Das AHAL muss den neuen HFP-Sitzungstyp (Hands-Free Profile) verwenden, um die Wiedergabe zu starten oder zu unterbrechen, ähnlich wie bei anderen BT-Sitzungstypen. Der Streamstatus wird letztendlich über verschiedene IBluetoothAudioProviders verwaltet, die von einer Factory-Klasse je nach verfügbaren Pfaden aufgezählt und erstellt werden.
Der Bluetooth-Stack verwendet nach Möglichkeit immer einen Hardware-Offload-Pfad. Die Reihenfolge der Codecs bei der Aushandlung ist wie folgt: LC3-Hardware wird gegenüber LC3-Software bevorzugt, gefolgt von mSBC-Hardware, dann mSBC-Software und schließlich CVSD-Hardware gegenüber CVSD-Software.
Die folgenden Sequenzdiagramme beschreiben die Interaktionen zwischen dem AHAL und dem Bluetooth-Stack, die zum Festlegen des Streamstatus erforderlich sind.
Hardware-Offload-Verfahren
Abbildung 1 zeigt, wie AHAL und der Bluetooth-Stack zusammenarbeiten, um einen direkten Hardware-Datenpfad für SCO-Audio einzurichten:
Abbildung 1. Hardware-Offload-Verfahren.
Software-Datenpfadverfahren
Abbildung 2 veranschaulicht den Prozess für die Verarbeitung von Audiodaten, für die eine Verarbeitung durch die Systemsoftware erforderlich ist:
Abbildung 2: Verfahren für den Software-Datenpfad.
Vorgang zur erneuten Codec-Aushandlung
Wenn das Audio-Gateway (AG) einen neuen BT-Befehl für verfügbare Codecs (AT+BAC) empfängt, startet das AG die Codec-Aushandlung neu. Abbildung 3 veranschaulicht die Neuverhandlung des Codecs:
Abbildung 3. Vorgang zur erneuten Aushandlung des Codecs.
Auswirkungen auf HeadsetStateMachine
Die Headset-Zustandsmaschine der Java-Ebene (dargestellt durch die Klasse HeadsetStateMachine) bleibt weitgehend unverändert, mit Ausnahme des Zustands AUDIO_CONNECTED, der durch Ereignisse des nativen Stacks gesteuert wird.
In der Java-Ebene werden connectAudioNative oder disconnectAudioNative nicht mehr vom System initiiert. Stattdessen reagiert das System auf Änderungen des Audioverbindungsstatus aus dem nativen Stack. Diese Änderungen werden durch die AHAL-Befehle auf IBluetoothAudioProvider oder IBluetoothAudioPort ausgelöst.
Implementierung
Um das Refactoring der SCO-Verwaltung zu integrieren, müssen Sie die Kommunikation zwischen dem BT-Stack und dem Audio-Framework aktualisieren.
So implementieren Sie die Funktion:
Das Audio-Framework wird über Änderungen am aktiven BT informiert, um die richtige Verwaltung der SCO-Initiierung und ‑Beendigung während der HFP-Geräteverbindungen zu unterstützen und Änderungen am aktiven Gerät zu verarbeiten. Verwenden Sie
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo), um diese Informationen für das Audio-Framework bereitzustellen.
Abbildung 4: HFP-Gerät verbinden
Das Audio-Framework verwendet den
AudioManagerAudioDeviceCallback#onAudioDevicesAdded-Callback anstelle von Legacy-Broadcasts, um den Status des Audiogeräts anzugeben.Implementieren Sie die AHAL-Streamsteuerung mit
setCommunicationDevice(AudioDeviceInfodevice)als primärem Kontrollpunkt zum Starten der SCO-Verbindung.Wenn
HfpTransport::StartRequestBluetoothAudioCtrlAck::PENDINGzurückgibt, muss das AHAL die Anfrage noch einmal senden, da die HFP-Zustandsmaschine nicht eingerichtet ist.
Anwendungsfälle
In den folgenden Abschnitten werden typische wichtige Nutzerverhaltensweisen (Critical User Journeys, CUJs) beschrieben.
Ablauf von Telekommunikationsanrufen
Durch das Refactoring der SCO-Verwaltung wird phoneStateChanged in eine blockierende Funktion geändert. Durch diese Änderung wartet Telecom, bis die Ausführung von phoneStateChanged innerhalb der Methode BluetoothInCallService.onCallAdded() abgeschlossen ist, bevor die Audio-Framework-API aufgerufen wird, um die SCO-Erstellung zu starten.
Abbildung 5: Anrufe über den Telekommunikationsanbieter annehmen oder starten
Ablauf von VoIP-Anrufen
Das Audio-Framework startet den Prozess durch Aufrufen der Methode BluetoothHeadset.startScoUsingVirtualVoiceCall. Nachdem der Bluetooth-Stack dem Audio-Framework ein Ergebnis geliefert hat, weist das Framework die AHAL an, startStream auszuführen. Die folgende Abbildung veranschaulicht diesen Ablauf:
Abbildung 6. Anrufe über VoIP annehmen oder starten
Spracherkennung
Sowohl für die Freisprechfunktion als auch für die vom AG initiierte Spracherkennung muss der BT-Stack das Audio-Framework anfordern, SCO mit AudioManager.setCommunicationDevice() zu öffnen. Dies wird in der folgenden Abbildung veranschaulicht:
Abbildung 7. SCO-Initiierung per Spracherkennung.
Audioverbindung
Der BT-Stack initiiert eine SCO-Verbindung, indem er das Audio-Framework mit AudioManager.setCommunicationDevice(AudioDeviceInfo) während der Spracherkennung anfordert. Wenn ein Anruf aktiv ist, fordert der BT-Stack stattdessen BluetoothInCallService#requestBluetoothAudio vom Telekommunikations-Stack an.
Dieser Vorgang wird in der folgenden Abbildung dargestellt:
Abbildung 8. Audioverbindung
Validierung und Tests
Um zu prüfen, ob die Funktion richtig integriert ist und den Qualitätsstandards entspricht, müssen Gerätehersteller die folgenden Tests durchführen:
- CTS Verifier: Verwenden Sie den CTS Verifier für interaktive Tests des Audio-Routings während Anrufen.
- Vendor Test Suite (VTS): Validieren Sie die AHAL- und BT AHAL-Interaktionen mit VTS.
Voraussetzungen
Für diese Funktion gelten die folgenden Anforderungen:
- AHAL: Für die Implementierung ist ein kompatibles AHAL erforderlich, das den refaktorierten SCO-Verwaltungspfad unterstützt.