Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Bluetooth Low Energy

Bluetooth Low Energy (BLE), verfügbar ab Android 4.3, stellt kurze Verbindungen zwischen Geräten her, um Daten in kurzen Intervallen zu übertragen. BLE bleibt im Ruhemodus, wenn keine Verbindung besteht. Dadurch bietet BLE im Vergleich zu Classic Bluetooth eine geringere Bandbreite und einen geringeren Stromverbrauch. BLE eignet sich ideal für Apps wie Herzfrequenzmesser oder kabellose Tastaturen. Damit BLE verwendet werden kann, muss auf den Geräten ein Chipsatz vorhanden sein, der BLE unterstützt.

Implementierung

Alle aktuellen BLE-App-Profile basieren auf dem GATT-Profil (Generic Attribute Profile) . Wenn ein Android-Gerät mit einem BLE-Gerät interagiert, ist das Gerät, das Informationen sendet, der Server und das Gerät, das Informationen empfängt, der Client. Android enthält Entwickler-APIs für BLE, einschließlich APIs für die Interaktion zwischen GATT-Servern und GATT-Clients. Um die BLE APIs optimal nutzen zu können, müssen Sie die Android Bluetooth HCI-Anforderungen implementieren.

Gerätemodi

Bei Verwendung von BLE kann ein Android-Gerät als Peripheriegerät, als zentrales Gerät oder als beides fungieren. Im Peripheriemodus können Geräte Werbepakete senden. Im zentralen Modus können Geräte nach Broadcasts suchen. Ein Android-Gerät, das sowohl als Peripherie- als auch als zentrales Gerät fungiert, kann mit anderen BLE-Peripheriegeräten kommunizieren, während es im Peripheriemodus Werbung sendet. Geräte, die Bluetooth 4.1 und niedriger unterstützen, können BLE nur im zentralen Modus verwenden. Ältere Chipsätze unterstützen den BLE-Peripheriemodus möglicherweise nicht.

BLE-Suche

Ein Android-Gerät kann mit BLE bestimmte Bluetooth-Geräte effizienter ansteuern und nach ihnen suchen. Mit BLE-APIs können App-Entwickler Filter erstellen, um Geräte mit weniger Beteiligung des Hostcontrollers zu finden.

Achtung:Für das BLE-Scanning sind in der Regel Standortberechtigungen erforderlich, da beim BLE-Scanning Objekte identifiziert werden, die für die Geolocation verwendet werden können. Wenn Sie die Standortdienste deaktivieren, wird auch die Bluetooth-Suche deaktiviert. In Android 12 und höher können Apps, die neverForLocation deklarieren, Ergebnisse der Bluetooth-Suche erhalten, auch wenn die Standortdienste deaktiviert sind. Weitere Informationen finden Sie unter Tristate-Standortberechtigungen.

Standortscan

Die Standortdienste eines Geräts können Bluetooth verwenden, um Bluetooth-Beacons zu erkennen und einen genaueren Standort zu ermitteln. So aktivieren Nutzer die Funktion:

Gehen Sie zu den Einstellungen > Sicherheit & Standort > Standort.
Der Schieberegler für „Standort“ Ein/Aus muss sich in der Position Ein befinden.
Rufen Sie den Modus auf.
Wählen Sie entweder den Modus Hohe Genauigkeit oder Energiesparmodus aus.

Unter Android 11 und niedriger benötigen einzelne Apps Standortberechtigungen, um BLE-Scans zu verwenden, auch wenn sie nur nach Geräten suchen, mit denen sie sich verbinden können. Wenn der Nutzer die Standortsuche deaktiviert oder einer App keine Standortberechtigungen gewährt, erhält die App keine BLE-Scanergebnisse.

In Android 12 und höher können Apps mit den Berechtigungen BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE und BLUETOOTH_CONNECT nach Geräten in der Nähe suchen, ohne die Berechtigung zur Standortermittlung anfordern zu müssen. Weitere Informationen finden Sie unter Bluetooth-Berechtigungen.

Nutzer können die Bluetooth-Hintergrundsuche auf Systemebene deaktivieren, indem sie zu Einstellungen > Sicherheit & Standort > Standort > Suche gehen und den Schalter Bluetooth-Suche auf „Aus“ stellen. Die BLE-Suche nach Standorten oder lokalen Geräten ist davon nicht betroffen.

Scanergebnisse filtern

Android 6.0 und höher umfasst BLE-Scanning und Filterabgleich auf dem Bluetooth-Controller. Ein Gerät kann Scanergebnisse filtern und Gefunden- und Verloren-Ereignisse im Zusammenhang mit BLE-Geräten an den Anwendungsprozessor (AP) melden. Die Filterung funktioniert auch bei Batch-Scans, was dazu beiträgt, Strom zu sparen, da das Gerät das BLE-Scannen an die Firmware auslagert. Durch Batch-Scans wird die Häufigkeit reduziert, mit der der AP aufgrund von BLE-Scans nach Geräten oder Beacons aktiviert wird.

Die Funktion OnFound/OnLost wird im Bluetooth-Controller implementiert und dann getestet, um zu bestätigen, dass BLE-Geräte bei Scans nicht übersehen werden. Das spart Energie und kann auch folgende Vorteile bieten:

Bei einem OnFound-Ereignis wird der primäre AP aktiviert, wenn ein bestimmtes Gerät erkannt wird.
Bei einem OnLost-Ereignis wird der AP aktiviert, wenn ein bestimmtes Gerät nicht gefunden werden kann.
Framework-Apps erhalten weniger unerwünschte Benachrichtigungen, wenn sich ein Gerät in der Nähe in Reichweite befindet.
Durch kontinuierliche Scans können Framework-Apps benachrichtigt werden, wenn sich ein Gerät außerhalb der Reichweite befindet.

Ein Scanfilter kann auf der Erkennung von Geräte-Advertisements (dem OnFound-Ereignis) basieren. In der Java-Ebene können Parameter wie die erste Erkennung (oder eine bestimmte Anzahl von Anzeigen seit der ersten Erkennung) angegeben werden. Implementieren Sie die BLE-Filterung mit dem HCI-Befehl Advertising Packet Content Filter.