Bluetooth Low Energy-Audio

Bluetooth Low Energy Audio (LEA) sorgt dafür, dass Nutzer Audioinhalte in hoher Qualität hören können, ohne die Akkulaufzeit zu beeinträchtigen. Außerdem können sie nahtlos zwischen verschiedenen Anwendungsfällen wechseln. Android 13 (API‑Level 33) bietet integrierte Unterstützung für LEA.

Die meisten LEA-Headsets sind Dual-Mode-Headsets, bis der Marktanteil von LEA-Quellgeräten wächst. Nutzer sollten beide Übertragungsarten auf ihren Dual-Mode-Headsets koppeln und einrichten können.

Anwendungsfälle

Sie können LEA für die folgenden Anwendungsfälle einbinden:

• Audiofreigabe: Nutzer können mehrere Audiostreams gleichzeitig für ein oder mehrere Audio-Senkengeräte freigeben. Audio wird zwischen dem Quellgerät und den verbundenen Geräten synchronisiert.

• Audioübertragung: Nutzer können Audioinhalte für Freunde und Familie übertragen und sich gleichzeitig mit öffentlichen Übertragungen verbinden, um Informationen zu erhalten, sich unterhalten zu lassen oder die Barrierefreiheit zu nutzen.

• Unterstützung für den LC3-Audio-Codec: Dies ist der Standard-Audio-Codec und ersetzt den SBC-Codec, der für A2DP (Media) und mSBC in HFP (Voice) verwendet wird. LC3 ist effizienter, rekonfigurierbar und bietet eine höhere Qualität.

• Verbesserungen bei der Audioabtastung: Headsets können bei der Verwendung von Mikrofonen eine hohe Audioqualität beibehalten. Bei Bluetooth Classic wird die Audioqualität bei der Verwendung von Bluetooth-Mikrofonen verringert. Mit BLE Audio kann die Abtastung bei der Eingabe und Ausgabe 32 kHz erreichen.

• Stereomikrofon: Hearables können Audio mit Stereomikrofonen aufnehmen, um die räumliche Audioqualität zu verbessern.

• Unterstützung für das Hearing Aid Profile (HAP): HAP bietet Nutzern mehr Barrierefreiheit und Nutzungsmöglichkeiten als die vorherigen ASHA-Protokolle. Nutzer können ihre Hörgeräte für Anrufe und VoIP-Anwendungen verwenden.

• Unterstützung für das Enhanced Attribute Protocol (EATT): Mit EATT können Entwickler mehrere Befehle gleichzeitig an gekoppelte Hearables senden.

Wichtige Szenarien

Es gibt vier Hauptkategorien von Anwendungsfällen:

1. Gespräche: Dialer- und VoIP-Anwendungen, die ein Kommunikationsrouting mit niedriger Latenz erfordern, bieten eine hohe Audioqualität und eine geringere Akkunutzung.

2. Gaming: Gleichzeitige Mikrofon- und Hi-Fi-Wiedergabe ermöglicht es Spielen, Audio in hoher Qualität an Hearables zu streamen. Eine Gaming-App kann auf die BLE-Audioeingabe zugreifen, wenn ein Spiel das Bluetooth-Mikrofon als einsatzbereit aktiviert. Wenn ein Spieler dann ein Live-Gespräch mit einem anderen Spieler beginnt, kann die Gaming-App die Mikrofondaten ohne Verzögerung verwenden.

3. Media: Media-Anwendungen dürfen das bevorzugte Gerät des Audio-Managers festlegen. Der Nutzer kann dies überschreiben, indem er das bevorzugte Gerät in den Systemeinstellungen ändert.

4. Barrierefreiheit: Hörgeräte, die BLE Audio unterstützen, können jetzt das Mikrofon verwenden, sodass Nutzer ihre Hörgeräte für einen Anruf verwenden können.

BLE Audio-APIs und ‑Methoden

Die folgenden APIs und Methoden sind erforderlich, um BLE Audio-Hearables zu unterstützen:

AudioManager

• setCommunicationDevice() wählt das Audiogerät aus, das für Kommunikationsanwendungsfälle verwendet werden soll, z. B. für Sprach- oder Videoanrufe. Diese Methode kann von Sprach- oder Videoanruf-Anwendungen verwendet werden, um ein anderes Audiogerät als das auszuwählen, das standardmäßig von der Plattform ausgewählt wird. Diese API ersetzt die folgenden verworfenen APIs: startBluetoothSco(), stopBluetoothSco(), und setSpeakerphoneOn().
• clearCommunicationDevice() wird aufgerufen, nachdem Ihre App einen Anruf oder eine Sitzung beendet hat, damit der Nutzer beim Wechsel zwischen verschiedenen Anwendungen eine gute Erfahrung hat.

BluetoothProfile

• BluetoothLeAudio steuert den Bluetooth-Dienst über ein Proxy-Objekt.

Telecom InCallService

• InCallService#requestCallEndpointChange() ersetzt die verworfenen InCallService.setAudioRoute() und InCallService.requestBluetoothAudio() APIs, damit Apps das Audio-Routing zu einem bestimmten CallEndpointanfordern können. Clients sollten beim Anfordern einer Änderung keinen eigenen CallEndpoint definieren. Stattdessen sollte der neue Endpunkt einer der gültigen Endpunkte sein, die von InCallService.onAvailableCallEndpointsChanged(java.util.List) bereitgestellt werden.
• CallEndpoint.TYPE_BLUETOOTH leitet den Audiostream über Bluetooth weiter.
• Diese oben genannten InCallService APIs sind für die Verwendung durch die Standard-Telefon App auf einem Android-Smartphone oder andere Anrufoberflächen wie Wearables, Autos oder andere Bluetooth-Geräte vorgesehen, die das Audio-Routing beeinflussen möchten.

Telecom CallControl

• Die neue CallControl Klasse wird in API‑Level 34 eingeführt, um Connection und ConnectionService nur für VoIP Anwendungen zu ersetzen.
• CallControl.requestCallEndpointChange() fordert auch eine Änderung von CallEndpoint an. Diese API ersetzt die verworfenen Connection.requestBluetoothAudio() und Connection.setAudioRoute() APIs.
• Neben den aktualisierten Telecom-Plattform-APIs wird die Telecom Jetpack-Bibliothek dringend empfohlen, wenn Sie Anwendungen für Sprach und/oder Videoanrufe entwickeln. Diese Bibliothek kann den Integrationsprozess erheblich vereinfachen und VoIP-Anrufe auf allen Android-Oberflächen verbessern.

Audio Device Info

• AudioDeviceInfo.TYPE_BLE_HEADSET beschreibt den Audiogerätetyp als LEA-Gerät. Wird verwendet, um zu ermitteln, ob das Hearable-Gerät ein LEA-Gerät ist.

Audiorekorder

• setPreferredDevice() legt das bevorzugte Gerät für das Audio-Routing fest. Der Nutzer kann dies in den Systemeinstellungen überschreiben.

Bluetooth-Adapter

• isLeAudioSupported(): Gibt eine @BluetoothStatusCodes -Konstante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED oder einen Fehlercode) zurück, die angibt, ob die Gerätehardware LE Audio unterstützt.
• isLeAudioBroadcastSourceSupported(): Gibt eine @BluetoothStatusCodes Konstante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED oder einen Fehlercode) zurück, die angibt, ob die Gerätehardware die LE Audio-Übertragungsquelle unterstützt.

Anleitungen nach Anwendungsfall

Im Folgenden finden Sie Richtlinien für die Implementierung von LEA basierend auf bestimmten Anwendungsfällen.

Sprachkommunikationsanwendungen

Sprachkommunikationsanwendungen können das Audio-Routing und den Gerätestatus selbst verwalten oder die Telecom API verwenden, die das Audio-Routing und die Statuslogik für Sie übernimmt.

• Selbstverwaltet: Wenn Sie Anwendungen verwenden, die derzeit startBluetoothSco(), stopBluetoothSco(), und setSpeakerphoneOn() verwenden oder den Audio-Routing-Status selbst verwalten möchten, folgen Sie der Anleitung für selbstverwaltete Anrufe im Audio Manager.

• Verwaltet: Verwenden Sie die Telecom Jetpack-Bibliothek oder Telecom-Plattform-APIs, um eine Anwendung für Audio- oder Video anrufe zu erstellen.

Mit diesen beiden Lösungen können Sie das Audio-Routing schnell und einfach steuern und zwischen Bluetooth-Geräten wechseln. Weitere Informationen finden Sie in der Anleitung für verwaltete Anrufe in Telecom.

Audioaufnahme-Anwendungen

• Media Recorder: Wenn Sie Audio mit dem Media Recorder aufnehmen, können Sie jetzt in Stereo aufnehmen, wenn das Bluetooth-Hearable LEA unterstützt. Weitere Informationen finden Sie in der Anleitung zur Audioaufnahme.

Empfehlungen für LE Audio-Headsets

Da immer mehr LEA-Headsets auf den Markt kommen, haben wir bei Tests in der Praxis Probleme festgestellt, die die Nutzererfahrung beeinträchtigen. Die Spezifikation deckt nicht alle diese Probleme ab. In der folgenden Tabelle finden Sie eine Liste von Empfehlungen, die Hersteller von LEA-Headsets befolgen sollten, um die End-to-End-Erfahrung für Android-Nutzer zu verbessern.

Beschreibung	Kontext
Unterstützung von Cross Transport Key Derivation (CTKD) für Dual-Mode-Headsets: Unterstützung der Schlüsselableitung für die Kopplung von Classic zu LE und LE zu Classic.	Die meisten neuen LEA-Headsets sind Dual-Mode-Headsets, bis der Marktanteil von LEA-Quellgeräten wächst. Es ist wichtig, dass Nutzer ihre Dual-Mode-Headsets nahtlos koppeln und beide Übertragungsarten einrichten können. Das ist auch für Google Schnelles Pairing wichtig.
Unterstützung von Targeted Announcements (TAs) , wenn Ihre LEA-Headsets zuverlässig wieder mit den Quellgeräten verbunden werden sollen. LEA-Ohrhörer sollten TAs verwenden, um eine eingehende Verbindung von den zentralen Geräten anzufordern. Wird demnächst in die BT SIG aufgenommen.	Anders als beim Paging-Modell von BR/EDR, bei dem eine Verbindung entweder vom Smartphone oder vom Headset initiiert werden kann, muss eine Verbindung in LEA vom zentralen Gerät initiiert werden. Derzeit verwenden viele Headsets keine TAs. Das bedeutet, dass das zentrale Gerät möglicherweise keine Verbindung zum Peripheriegerät herstellen kann, ohne es einer Zulassungsliste hinzuzufügen. Eine Zulassungsliste kann jedoch verhindern, dass das Headset eine Verbindung zu einem anderen zentralen Gerät herstellt. Daher ist es wichtig, dass LEA-Headsets TAs richtig unterstützen, damit das zentrale Gerät zuverlässig wieder eine Verbindung herstellen kann, ohne dass Workarounds erforderlich sind, die Mehrpunktverbindungen unterbrechen könnten.
Optimierte Erkennbarkeit für Dual-Mode-Ohrhörer Der primäre Ohrhörer – BR/EDR-Komponente sollte mit seiner öffentlichen Adresse werben, die Abfrage und den Paging-Scan mit seinem Namen über EIR aktivieren und das LE Audio-Bit 14 in den Major Service Classes der Class of Device (CoD) auf 1 setzen. Primärer Ohrhörer – LE-Komponente: Der primäre Ohrhörer sollte eine Connectable- und Discoverable-Ankündigung (entweder Limited oder General) mit derselben öffentlichen Adresse wie die BR/EDR Komponente und demselben vollständigen lokalen Namen wie die BR/EDR Komponente ausführen. Die Appearance Category sollte auf eine geeignete Appearance Category festgelegt sein, die dem Typ des Remote-Geräts entspricht. Es wird erwartet, dass das zentrale Gerät diese Informationen verwendet, um seine UI- und Audio-Routing-Richtlinien anzupassen. Sekundärer Ohrhörer – nur LE: Der sekundäre Ohrhörer sollte eine Connectable-Ankündigung ohne Erkennbarkeit ausführen. Die Appearance Category sollte auf eine geeignete Appearance Category festgelegt sein, die dem Typ des Remote-Geräts entspricht. Es wird erwartet, dass das zentrale Gerät diese Informationen verwendet, um seine UI- und Audio-Routing-Richtlinien anzupassen. Die Ohrhörer sollten dynamisch einen Leader aus der CSIP Gruppe als primäres Gerät auswählen. Wenn der Ohrhörer ein Dual-Mode-Ohrhörer ist, muss das primäre Gerät ein Dual-Mode-Gerät sein, damit sowohl die LE- als auch die Classic Funktionen nach der Kopplung richtig funktionieren.	Dadurch wird verhindert, dass Dual-Mode-LEA-Ohrhörer in den Bluetooth-Einstellungen als doppelte Einträge angezeigt werden, was Nutzer verwirren und die LEA-Kopplungserfahrung beeinträchtigen könnte. Die dynamische Leader-Auswahl ist besonders wichtig für Dual-Mode Geräte, die schrittweise gekoppelt werden. Wenn beispielsweise bei der ersten Kopplung nur ein Ohrhörer verfügbar ist, sollte er sich als Dual-Mode-Gerät präsentieren. Wenn ein Nutzer später den zweiten Ohrhörer koppelt, muss er nur die LE-Komponente koppeln. CSIP sorgt dafür, dass sie auf Android gruppiert werden. Die Identitätsadresse wird bei der Kopplung empfohlen, da die BR/EDR Komponente die öffentliche Adresse des Geräts bereits für Geräte in der Nähe freigibt.
Unterstützung des Enhanced Attribute Protocol (EATT).	Reduziert die Latenz bei der Kopplung und Verbindung.
Unterstützung von robustem GATT-Caching.	Reduziert die Latenz bei der Verbindung, insbesondere bei TWS-Ohrhörern.
Unterstützung von Verbindungs-Subrating.	Ermöglicht eine flexiblere Paketplanung und potenzielle Energieeinsparungen
Achten Sie darauf, dass die Wiedergabe und Aufnahme während der Vor- und Nachbearbeitung, die Signalverarbeitungspipeline mit 16, 24, 32 und 48 kHz arbeiten kann und auch höhere Frequenzen unterstützt.	Nutzt die höheren Abtastraten, die für LEA-Anrufe oder VoIP-Aufnahmepfade und die Medienwiedergabe unterstützt werden.
Unterstützung von LE Power Control	Verbessertes Energiemanagement

Unterstützung für Kontexttypen

Beschreibung	Kontext
Verwenden Sie alle in Assigned Numbers 6.12.3 angegebenen Kontexttypen, es sei denn, das Headset unterstützt einen bestimmten Kontexttyp nicht.	Wenn beispielsweise der Kontexttyp „Game“ nicht unterstützt wird, sendet Android Spielsounds. Beachten Sie insbesondere, dass der Kontexttyp „Unspecified“ nicht „beliebiger Kontexttyp“ bedeutet und nicht unterstützte Kontexttypen nicht abdeckt.
Wenn das zentrale Gerät mit dem ASCS des Peripheriegeräts interagiert, muss sich das Peripheriegerät mit dem MCS und TBS des zentralen Geräts verbinden. Das zentrale Gerät verwendet LE Audio möglicherweise nicht immer als Streaming route, da es möglicherweise auf A2DP oder HFP zurückgreift. Das Peripheriegerät kann die ASCS-Interaktion als Hinweis darauf verwenden, ob das zentrale Gerät LE Audio für das Streaming verwendet. Einige Beispiele für ASCS-Interaktionen sind Lesen, Schreiben und Registrieren für Benachrichtigungen.

Hinweis: Gemäß der Spezifikation können Headsets Kontexttypen jederzeit und für alle verbundenen Geräte aus den verfügbaren Kontexttypen entfernen, auch für ein Gerät, das derzeit einen bestimmten Kontexttyp streamt. Es wird empfohlen, dass das Headset den derzeit gestreamten Kontexttyp nicht aus den verfügbaren Kontexttypen auf dem Gerät entfernt, das diesen Kontexttyp streamt.