Bluetooth Low Energy-Audio

Bluetooth Low Energy Audio (LEA) sorgt dafür, dass Nutzer High-Fidelity-Audioinhalte empfangen 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 arbeiten im Dual-Modus, bis der Marktanteil für LEA-Quellgeräte wächst. Nutzer sollten beide Transporte über ihre Dual-Mode-Headsets koppeln und einrichten können.

Anwendungsfälle

In den folgenden Anwendungsfällen können Sie LEA einbinden:

  • Audio teilen: Nutzer können mehrere Audiostreams gleichzeitig mit einem oder mehreren Audiosenkengeräten teilen. Die Audiodaten werden zwischen dem Quellgerät und den verbundenen Geräten synchronisiert.

  • Audioübertragung: Nutzer können Audio an Freunde und Familienmitglieder übertragen und gleichzeitig eine Verbindung zu öffentlichen Broadcasts herstellen, um Informationen, Unterhaltung oder Zugänglichkeit zu erhalten.

  • LC3-Audio-Codec-Unterstützung: 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, neu konfigurierbar und qualitativ höher.

  • Verbesserte Audiosampling-Funktion: Headsets können bei Verwendung von Mikrofonen eine hohe Audioausgabequalität erzielen. Bei Bluetooth Classic wird die Audioqualität bei Verwendung von Bluetooth-Mikrofonen verringert. Mit BLE Audio können eine Abtastung von Eingangs- und -Ausgang bis zu 32 kHz erreicht werden.

  • Stereomikrofon: Hearables kann Audio mit Stereomikrofonen aufnehmen, um den Raumklang zu verbessern.

  • Unterstützung für Hearing Aid Profile (HAP): HAP bietet Nutzern eine bessere Zugänglichkeit 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 erweiterte Attributprotokoll (EATT): Mit EATT können Entwickler mehrere Befehle gleichzeitig an gekoppelte Hearables senden.

Wichtige Szenarien

Es gibt vier Hauptkategorien von Anwendungsfällen:

  1. Unterhaltung: Telefon- und VoIP-Anwendungen, die ein Kommunikations-Routing mit niedriger Latenz erfordern, bieten eine hohe Audioqualität und einen geringeren Akkuverbrauch.

  2. Gaming: Die gleichzeitige Wiedergabe von Mikrofon und High-Fidelity-Wiedergabe ermöglicht es, Audio in hoher Qualität auf Hearables zu streamen. Eine Gaming-App kann auf die BLE-Audioeingabe zugreifen, wenn ein Spiel das Bluetooth-Mikrofon als betriebsbereit aktiviert. Wenn ein Spieler dann eine Live-Unterhaltung mit einem Peer-Spieler startet, kann die Spiele-App die Mikrofondaten ohne Verzögerung verwenden.

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

  4. Barrierefreiheit: Hörgeräte, die BLE Audio unterstützen, können jetzt das Mikrofon verwenden. So können Nutzer ihr Hörgerät ständig für Anrufe verwenden.

BLE Audio APIs und -Methoden

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

Audio-Manager

  • setCommunicationDevice() wählt das Audiogerät aus, das für die Kommunikation verwendet werden soll, z. B. Sprach- oder Videoanrufe. Diese Methode kann von Sprach- oder Videochatanwendungen verwendet werden, um ein anderes Audiogerät als das standardmäßig von der Plattform ausgewählte Gerät auszuwä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. So soll den Nutzern beim Wechseln zwischen verschiedenen Anwendungen eine positive Nutzererfahrung geboten werden.

Bluetooth-Profil

InCall-Dienst für Telekommunikationsdienste

Audiogeräteinformationen

  • In AudioDeviceInfo.TYPE_BLE_HEADSET wird der Audiogerätetyp als LEA-Gerät beschrieben. Wird verwendet, um zu ermitteln, ob das hörbare Gerät ein LEA-Gerät ist.

Audiorekorder

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

Bluetooth-Adapter

Anleitungen basierend auf Anwendungsfall

Im Folgenden finden Sie Richtlinien für die Implementierung von LEA auf der Grundlage bestimmter Anwendungsfälle.

Sprachkommunikationsanwendungen

Sprachkommunikationsanwendungen können das Audiorouting und den Gerätestatus verwalten, indem sie ihren Status selbst verwalten oder die Telecom API verwenden, die das Audiorouting und die Statuslogik für Sie übernimmt.

Apps zur Audioaufnahme

  • Medienrekorder: Bei Audioaufzeichnungen mit dem Medienrekorder können Sie jetzt in Stereo aufnehmen, wenn das Bluetooth-Hearable LEA unterstützt. Weitere Informationen finden Sie im Leitfaden zur Audioaufnahme.

LEA-Empfehlungen für Headsets

Im Zuge der Veröffentlichung weiterer LEA-Headsets haben wir in realen Tests Probleme festgestellt, die die Nutzerfreundlichkeit beeinträchtigen. Die Spezifikation deckt nicht alle diese Probleme ab. Die folgende Tabelle enthält eine Liste von Empfehlungen, die Hersteller von LED-Headsets beachten sollten, um die End-to-End-Funktionalität für Android-Nutzer zu verbessern.

Beschreibung Kontext
Unterstützung der Cross Transport Key Derivation (CTKD) für Dual-Mode-Headsets:
  • Unterstützung der Schlüsselableitung für die Kopplung von Classic zu LE und von LE zu Classic.
 Die meisten neuen LEA-Headsets arbeiten im Dual-Mode-Modus, bis der Marktanteil der LEA-Quellgeräte wächst. Nutzer müssen ihre Dual-Mode-Headsets reibungslos koppeln und beide Transporte einrichten können. Das ist auch für das schnelle Pairing von Google wichtig.

Unterstütze Gezielte Ankündigungen (TAs), wenn du möchtest, dass deine LEA-Headsets eine zuverlässige Verbindung zu den Quellgeräten herstellen.

LE Audio-Kopfhörer sollten TAs verwenden, um eine eingehende Verbindung von den zentralen Geräten anzufordern.

Wird zur bevorstehenden BT SIG hinzugefügt.

 Im Gegensatz zum 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 neue Verbindung zum Peripheriegerät herstellen kann, ohne es zu 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 ordnungsgemäß unterstützen, damit sich das zentrale Gerät zuverlässig und ohne Behelfslösungen wieder verbinden kann, die Multi-Point-Verbindungen unter Umständen unterbrechen.
Optimierte Sichtbarkeit für Dual-Modus-Kopfhörer
  • Primärer Kopfhörer – BR/EDR-Komponente sollte unter Verwendung seiner öffentlichen Adresse werben und Anfragen und Seitenscans mit ihrem über EIR verfügbaren Namen ermöglichen. Außerdem sollte das LE-Audio-Bit 14 auf 1 unter „Major Service Categories of Device“ (CoD) gesetzt werden.
  • Primärer Kopfhörer – LE-Komponente: Der primäre Kopfhörer sollte eine anpassbare und erkennbare (eingeschränkte oder allgemeine) Anzeige mit derselben öffentlichen Adresse wie die BR/EDR-Komponente und mit demselben vollständigen lokalen Namen wie die BR/EDR-Komponente ausliefern. Dabei muss die Darstellungskategorie als passende Darstellungskategorie festgelegt werden, die dem Remote-Gerätetyp mit der Erwartung entspricht, dass das Gerät diese Informationen an die zentrale Darstellungs- und Audiokonfiguration verwendet.
  • Sekundärer Kopfhörer – nur LE: Der sekundäre Kopfhörer sollte eine verknüpfbare, nicht erkennbare Werbung mit seiner Darstellungskategorie als geeignete Darstellungskategorie ausführen, die dem Remote-Gerätetyp mit der Erwartung entspricht, dass das zentrale Gerät diese Informationen zum Anpassen seiner UI- und Audiorouting-Richtlinien verwendet.

    Die Kopfhörer sollten dynamisch einen Leader aus der CSIP-Gruppe als primäres Gerät auswählen. Wenn der Kopfhörer im Dual-Modus ist, muss das primäre Gerät im Dual-Modus sein, damit sowohl die LE- als auch die 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 könnte.

Die Dynamic Leader-Auswahl ist besonders wichtig für Dual-Mode-Geräte, die inkrementell gekoppelt sind. Wenn beispielsweise beim ersten Koppeln nur ein Kopfhörer verfügbar ist, sollte er sich als Dual-Mode-Gerät präsentieren. Wenn ein Nutzer später mit dem zweiten Kopfhörer gekoppelt wird, muss er nur mit der LE-Komponente gekoppelt werden und CSIP sorgt dafür, dass sie unter Android gruppiert werden.

Die Identitätsadresse wird für die Kopplung empfohlen, da die BR/EDR-Komponente die öffentliche Adresse des Geräts bereits für Geräte in der Nähe verfügbar macht.
Sie müssen das erweiterte Attribute Protocol (EATT) unterstützen. Reduziert die Kopplungs- und Verbindungslatenz.
Unterstützen Sie robustes GATT-Caching. Reduziert die Verbindungslatenz, insbesondere bei TWS-Kopfhörern.
Verbindungsunterbewertung unterstützen. Ermöglicht eine flexiblere Paketplanung und potenzielle Akkueinsparungen.
Achten Sie darauf, dass die Signalverarbeitungspipeline während der Vor- und Nachverarbeitung sowohl für die Wiedergabe als auch für die Erfassung mit 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-Erfassungspfade und die Medienwiedergabe unterstützt werden.
Unterstützung für LE Power Control Bessere Energieverwaltung

Unterstützung für Kontexttyp

Beschreibung Kontext
Verwenden Sie alle in Assigned Numbers 6.12.3 angegebenen Kontexttypen, es sei denn, das Headset unterstützt einen bestimmten Kontexttyp nicht explizit. Wenn der Kontexttyp „Spiel“ beispielsweise nicht unterstützt wird, sendet Android Spieltöne. Beachten Sie insbesondere, dass der Kontexttyp „Nicht angegeben“ keinen „Kontexttyp“ bedeutet und keine nicht unterstützten 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 Streamingroute, da es möglicherweise auf A2DP oder HFP zurückgreifen könnte. Das Peripheriegerät kann die ASCS-Interaktion verwenden, um festzustellen, ob das zentrale Gerät LE Audio zum Streaming verwendet.

Einige Beispiele für ASCS-Interaktionen sind Lesen, Schreiben und Registrieren für Benachrichtigungen.