Bluetooth Low Energy-Audio

Hinweis :Bei isLeAudioSupported() und isLeAudioBroadcastSourceSupported() wird True zurückgegeben, wenn das Gerät BLE Audio unterstützt.

Bluetooth Low Energy Audio (LEA) sorgt dafür, dass Nutzer High-Fidelity-Audio ohne Abstriche bei der Akkulaufzeit erhalten und nahtlos zwischen verschiedenen Anwendungsfällen wechseln können. Android 13 (API-Level 33) bietet eine integrierte Unterstützung für LEA.

Die meisten LE Audio-Kopfhörer werden bis dahin einen Dual-Modus haben. Nutzer sollten mit ihren Dual-Modus-Headsets beide Transporte koppeln und einrichten können.

Anwendungsfälle

In den folgenden Anwendungsfällen sollten Sie LEA einbinden:

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

• Audio-Broadcasts: Nutzer können Audioinhalte an Freunde und Familienmitglieder senden und sich gleichzeitig für Informationen, Unterhaltung oder Barrierefreiheit mit öffentlichen Übertragungen verbinden.

• Unterstützung des LC3-Audiocodecs: Dies ist der Standard-Audiocodec und ersetzt den SBC-Codec, der für A2DP (Medien) und mSBC in HFP (Sprache) verwendet wird. LC3 ist effizienter, neu konfigurierbar und von höherer Qualität.

• Verbesserungen bei der Audio-Stichprobenerhebung: Headsets können bei Verwendung von Mikrofonen eine hohe Audioqualität bei der Ausgabe aufrechterhalten. Bei der Verwendung von Bluetooth-Mikrofonen wird die Audioqualität durch Bluetooth Classic verringert. Mit BLE Audio kann die Abtastrate für Eingabe und Ausgabe 32 kHz erreichen.

• Stereomikrofon: Hearables können Audio mit Stereomikrofonen aufnehmen, um den räumlichen Klang zu verbessern.

• Unterstützung für das Hörgeräteprofil (Hearing Aid Profile, HAP): HAP bietet Nutzern eine bessere Barrierefreiheit und Nutzung als frühere ASHA-Protokolle. Nutzer können ihre Hörgeräte für Telefonanrufe und VoIP-Anwendungen verwenden.

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

Wichtige Szenarien

Es gibt vier Hauptkategorien von Anwendungsfällen:

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

2. Gaming: Durch die gleichzeitige Nutzung von Mikrofon und High-Fidelity-Wiedergabe können Spiele hochwertige Audioinhalte an Hearables streamen. Eine Gaming-App kann auf die BLE-Audioeingabe zugreifen, wenn ein Spiel das Bluetooth-Mikrofon als einsatzbereit markiert. Wenn ein Spieler dann eine Live-Unterhaltung mit einem Peer-Spieler startet, kann die Spiel-App die Mikrofondaten ohne Verzögerung verwenden.

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

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

BLE Audio APIs und ‑Methoden

Die folgenden APIs und Methoden sind erforderlich, um BLE Audio-In-Ear-Kopfhörer zu unterstützen:

AudioManager

• Mit setCommunicationDevice() wird das Audiogerät ausgewählt, das für Kommunikationsanwendungen wie Sprach- oder Videoanrufe verwendet werden soll. Mit dieser Methode können Sprach- oder Videoanruf-Apps ein anderes Audiogerät als das von der Plattform standardmäßig ausgewählte auswählen. Diese API ersetzt die folgenden eingestellten APIs: startBluetoothSco(), stopBluetoothSco() und setSpeakerphoneOn().
• clearCommunicationDevice() wird aufgerufen, nachdem Ihre App einen Aufruf oder eine Sitzung beendet hat, um für eine reibungslose Navigation zwischen verschiedenen Apps zu sorgen.

BluetoothProfile

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

Telecom InCallService

• InCallService#requestCallEndpointChange() ersetzt die eingestellten APIs InCallService.setAudioRoute() und InCallService.requestBluetoothAudio(). So können Apps das Audio-Routing an eine bestimmte CallEndpoint anfordern. Clients sollten beim Anfordern einer Änderung nicht ihr eigenes CallEndpoint definieren. Stattdessen sollte der neue Endpunkt einer der gültigen Endpunkte von InCallService.onAvailableCallEndpointsChanged(java.util.List) sein.
• CallEndpoint.TYPE_BLUETOOTH leitet den Audiostream über Bluetooth.
• Diese oben genannten InCallService APIs sind für die Verwendung durch die Standardtelefon-App auf einem Android-Smartphone oder andere Anrufoberflächen wie Wearables, Autos oder andere Bluetooth-Geräte konzipiert, bei denen das Audiorouting beeinflusst werden soll.

Telecom CallControl

• Die neue Klasse CallControl wird mit 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 veralteten APIs Connection.requestBluetoothAudio() und Connection.setAudioRoute().
• Neben den aktualisierten APIs der Telecom-Plattform wird die Telecom Jetpack-Bibliothek beim Erstellen von Sprach- und/oder Videoanrufanwendungen dringend empfohlen. Diese Bibliothek kann den Integrationsprozess erheblich vereinfachen und VoIP-Anrufe auf allen Android-Oberflächen verbessern.

Informationen zum Audiogerät

• In AudioDeviceInfo.TYPE_BLE_HEADSET wird der Audiogerätetyp als LEA-Gerät beschrieben. Wird verwendet, um zu ermitteln, ob es sich bei dem Hörgerät um ein LEA-Gerät handelt.

Audiorekorder

• Mit setPreferredDevice() wird das bevorzugte Gerät für das Audiorouting festgelegt. Der Nutzer kann dies in den Systemeinstellungen überschreiben.

Bluetooth-Adapter

• isLeAudioSupported() wird zurückgegeben, wenn die Hardware der Plattform LEA unterstützt.
• isLeAudioBroadcastSourceSupported() wird zurückgegeben, wenn die Hardware der Plattform LEA unterstützt.

Leitfäden nach Anwendungsfall

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

Sprachkommunikationsanwendungen

Bei Sprachkommunikationsanwendungen können Sie 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 für Anwendungen derzeit startBluetoothSco(), stopBluetoothSco() und setSpeakerphoneOn() verwenden oder den Audio-Routing-Status selbst verwalten möchten, folgen Sie der Anleitung für selbstverwaltete Anrufe mit Audio Manager.

• Verwaltet: Verwenden Sie die Telecom Jetpack-Bibliothek oder die Telecom-Plattform-APIs, um eine Audio- oder Videoanrufanwendung 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 im Leitfaden zu verwalteten Anrufen in der Telekommunikationsbranche.

Audioaufnahme-Apps

• Media Recorder: Wenn Sie Audio mit dem Media Recorder aufnehmen, können Sie jetzt in Stereo aufnehmen, wenn das Bluetooth-In-Ear-Gerät LEA unterstützt. Weitere Informationen finden Sie im Leitfaden für Audioaufnahmen.

Empfehlungen für LE Audio (LEA)-Headsets

Wenn immer mehr LEA-Headsets auf den Markt kommen, haben wir bei Tests in der Praxis Probleme entdeckt, die die Nutzererfahrung beeinträchtigen. Die Spezifikation deckt nicht alle diese Probleme ab. Die folgende Tabelle enthält eine Liste von Empfehlungen, die LEA-Headset-Hersteller befolgen sollten, um die End-to-End-Nutzererfahrung für Android-Nutzer zu verbessern.

Beschreibung	Kontext
Unterstützung von Cross Transport Key Derivation (CTKD) für Dual-Mode-Headsets: Schlüsselableitung sowohl für die Kopplung zwischen Classic und LE als auch für die Kopplung zwischen LE und Classic unterstützen	Die meisten neuen LE Audio-Kopfhörer werden Dual-Mode-Kopfhörer sein, bis der Marktanteil von LE Audio-Quellgeräten steigt. Es ist wichtig, dass Nutzer ihre Dual-Mode-Headsets nahtlos koppeln und beide Übertragungsmethoden einrichten können. Das ist auch für Google Fast Pair wichtig.
Unterstützen Sie gezielte Ansagen, wenn Sie möchten, dass Ihre LEA-Kopfhörer zuverlässig wieder mit den Quellgeräten verbunden werden. LE Audio-In-Ear-Kopfhörer sollten TAs verwenden, um eine eingehende Verbindung von den zentralen Geräten anzufordern. Wird der kommenden BT-SIG hinzugefügt.	Im Gegensatz zum Paging-Modell von BR/EDR, bei dem eine Verbindung entweder vom Smartphone oder vom Headset gestartet werden kann, muss eine Verbindung in LEA vom zentralen Gerät gestartet werden. Viele Headsets verwenden derzeit keine TAs. Das bedeutet, dass sich das zentrale Gerät möglicherweise nicht wieder mit dem Peripheriegerät verbinden kann, ohne es einer Zulassungsliste hinzuzufügen. Eine Problemumgehung für die Zulassungsliste kann jedoch verhindern, dass sich das Headset mit einem anderen zentralen Gerät verbindet. Daher ist es wichtig, dass LEA-Headsets TAs ordnungsgemäß unterstützen, damit das zentrale Gerät zuverlässig wieder verbunden werden kann, ohne dass es zu Umgehungslösungen kommt, die Multipoint-Verbindungen unterbrechen könnten.
Optimierte Auffindbarkeit für In-Ear-Kopfhörer mit Dual-Modus Der primäre In-Ear-Kopfhörer – BR/EDR-Komponente sollte mit seiner öffentlichen Adresse werben und die Abfrage und den Seitenscan mit seinem über EIR verfügbaren Namen aktivieren. Außerdem muss das LE-Audiobit 14 in den Hauptdienstklassen der Geräteklasse (Class of Device, CoD) auf 1 gesetzt werden. Primärer Kopfhörer – LE-Komponente: Der primäre Kopfhörer sollte eine anknüpfbare und sichtbare Anzeige (entweder eingeschränkt oder allgemein) unter Verwendung derselben öffentlichen Adresse wie die BR/EDR-Komponente und demselben vollständigen lokalen Namen wie die BR/EDR-Komponente schalten. Die Darstellungskategorie muss als Darstellungskategorie festgelegt sein, die dem Typ des Remote-Geräts entspricht und die Erwartung, dass das zentrale Gerät diese Informationen zum Routing verwendet. Sekundärer Kopfhörer – nur LE: Der sekundäre Kopfhörer sollte eine ansteckbare, nicht sichtbare Anzeige schalten, wobei die Darstellungskategorie dem Remote-Gerätetyp entspricht. Dabei wird davon ausgegangen, dass das zentrale Gerät diese Informationen verwendet, um seine UI und die Richtlinien für das Audiorouting anzupassen. Die Kopfhörer sollten dynamisch einen Leader aus der CSIP-Gruppe als primäres Gerät festlegen. Wenn der In-Ear-Kopfhörer Dualband unterstützt, muss auch das primäre Gerät Dualband unterstützen, damit sowohl LE- als auch Classic-Funktionen nach dem Koppeln ordnungsgemäß funktionieren.	Dadurch wird verhindert, dass Dual-Mode-LEA-Kopfhörer als doppelte Einträge in den Bluetooth-Einstellungen angezeigt werden, was Nutzer verwirren und die LEA-Kopplung beeinträchtigen kann. Die dynamische Wahl des Leaders ist besonders wichtig für Dual-Mode-Geräte, die inkrementell gekoppelt werden. Wenn bei der Erstkopplung beispielsweise nur ein In-Ear-Kopfhörer verfügbar ist, sollte er sich als Dual-Mode-Gerät präsentieren. Wenn ein Nutzer später den zweiten In-Ear-Kopfhörer koppelt, muss er nur die LE-Komponente koppeln. CSIP sorgt dann dafür, dass die beiden Geräte auf Android-Geräten gruppiert werden. Die Identitätsadresse wird während des Koppelns empfohlen, da die BR/EDR-Komponente die öffentliche Adresse des Geräts bereits für Geräte in der Nähe freigibt.
Unterstützung von Enhanced Attribute Protocol (EATT)	Verringert die Kopplungs- und Verbindungslatenz.
Unterstützung von robustem GATT-Caching	Verringert die Verbindungslatenz, insbesondere bei TWS-Ohrstöpseln.
Unterstützung von Unterbewertungen von Verbindungen	Ermöglicht eine flexiblere Paketzuweisung und potenzielle Akkueinsparungen.
Während der Vor- und Nachverarbeitung sowohl für die Wiedergabe als auch für die Erfassung muss die Signalverarbeitungspipeline bei 16, 24, 32 und 48 kHz arbeiten und höhere Frequenzen unterstützen kann.	Nutzt die höheren Abtastraten, die für LEA-Anruf- oder VoIP-Aufnahmepfade und die Medienwiedergabe unterstützt werden.
LE Power Control unterstützen	Bessere Energieverwaltung

Unterstützung für Kontexttypen

Beschreibung	Kontext
Verwenden Sie alle Kontexttypen, die in Zugewiesene Nummern 6.12.3 angegeben sind, es sei denn, das Headset unterstützt einen bestimmten Kontexttyp nicht ausdrücklich.	Wenn der Kontexttyp „Spiel“ beispielsweise nicht unterstützt wird, sendet Android Spielgeräusche. Beachten Sie insbesondere, dass der Kontexttyp „Nicht angegeben“ nicht „einen Kontexttyp“ bedeutet und nicht unterstützte Kontexttypen abdeckt.
Wenn das zentrale Gerät mit dem ASCS des Peripheriegeräts interagiert, muss das Peripheriegerät eine Verbindung zum MCS und TBS des zentralen Geräts herstellen. Das zentrale Gerät verwendet möglicherweise nicht immer LE Audio als Streaming-Route, da es möglicherweise auf A2DP oder HFP zurückgreift. Das Peripheriegerät kann die ASCS-Interaktion nutzen, um anzugeben, 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 von einem Gerät, auf dem gerade ein bestimmter Kontexttyp gestreamt wird. Es wird empfohlen, dass das Headset den aktuell gestreamten Kontexttyp nicht aus den verfügbaren Kontexttypen auf dem Gerät entfernt, auf dem dieser Kontexttyp gestreamt wird.