Bluetooth Low Energy
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Android bietet integrierte Plattformunterstützung für Bluetooth Low Energy (BLE) und APIs, mit denen Apps Geräte finden, Dienste abfragen und Informationen übertragen können.
Zu den häufigsten Anwendungsfällen gehören:
- Übertragung kleiner Datenmengen zwischen Geräten in der Nähe
- Interagieren mit Näherungssensoren, um Nutzern eine personalisierte Nutzung basierend auf ihrem aktuellen Standort zu ermöglichen.
Im Gegensatz zu klassischem Bluetooth ist BLE für einen deutlich geringeren Energieverbrauch ausgelegt. So können Apps mit BLE-Geräten kommunizieren, die strengere Anforderungen an die Stromversorgung haben, z. B. Näherungssensoren, Herzfrequenzmesser und Fitnessgeräte.
Achtung:Wenn ein Nutzer sein Gerät über BLE mit einem anderen Gerät koppelt, können alle Apps auf dem Gerät des Nutzers auf die Daten zugreifen, die zwischen den beiden Geräten ausgetauscht werden.
Wenn Ihre App vertrauliche Daten erfasst, sollten Sie daher Sicherheitsmaßnahmen auf Anwendungsebene implementieren, um die Privatsphäre dieser Daten zu schützen.
Grundlagen
Damit BLE-fähige Geräte Daten untereinander übertragen können, müssen sie zuerst einen Kommunikationskanal bilden. Wenn Sie die Bluetooth LE APIs verwenden möchten, müssen Sie in Ihrer Manifestdatei mehrere Berechtigungen deklarieren. Sobald Ihre App die Berechtigung zur Verwendung von Bluetooth hat, muss sie auf BluetoothAdapter zugreifen und feststellen, ob Bluetooth auf dem Gerät verfügbar ist. Wenn Bluetooth verfügbar ist, sucht das Gerät nach BLE-Geräten in der Nähe.
Sobald ein Gerät gefunden wurde, werden die Funktionen des BLE-Geräts durch Herstellen einer Verbindung zum GATT-Server auf dem BLE-Gerät ermittelt.
Sobald eine Verbindung hergestellt wurde, können Daten je nach verfügbaren Diensten und Eigenschaften an das verbundene Gerät übertragen werden.
Wichtige Begriffe und Konzepte
Im Folgenden finden Sie eine Zusammenfassung der wichtigsten BLE-Begriffe und ‑Konzepte:
- Generic Attribute Profile (GATT)
- Das GATT-Profil ist eine allgemeine Spezifikation zum Senden und Empfangen kurzer Daten, die als „Attribute“ bezeichnet werden, über einen BLE-Link. Alle aktuellen BLE-Anwendungsprofile basieren auf GATT. Weitere Informationen finden Sie im Android BluetoothLeGatt-Beispiel auf GitHub.
- Profile
- Die Bluetooth SIG definiert viele Profile für BLE-Geräte. Ein Profil ist eine Spezifikation dafür, wie ein Gerät in einer bestimmten Anwendung funktioniert. Hinweis: Ein Gerät kann mehrere Profile implementieren. Ein Gerät kann beispielsweise einen Pulsmesser und einen Akkustandsensor enthalten.
- Attribute Protocol (ATT)
- GATT basiert auf dem Attribute Protocol (ATT). Dies wird auch als GATT/ATT bezeichnet. ATT ist für die Ausführung auf BLE-Geräten optimiert. Dazu werden so wenige Bytes wie möglich verwendet. Jedes Attribut wird durch eine Universally Unique Identifier (UUID) eindeutig identifiziert. Das ist ein standardisiertes 128-Bit-Format für eine String-ID, mit der Informationen eindeutig identifiziert werden. Die von ATT übermittelten Attribute sind als Merkmale und Dienste formatiert.
- Attribut
- Eine Eigenschaft enthält einen einzelnen Wert und 0–n Beschreibungen, die den Wert der Eigenschaft beschreiben. Eine Eigenschaft kann als ein Typ betrachtet werden, analog zu einer Klasse.
- Beschreibung
- Deskriptoren sind definierte Attribute, die einen charakteristischen Wert beschreiben. Ein Deskriptor kann beispielsweise eine visuell lesbare Beschreibung, einen zulässigen Bereich für den Wert einer Eigenschaft oder eine Maßeinheit angeben, die für den Wert einer Eigenschaft spezifisch ist.
- Dienst
- Ein Dienst ist eine Sammlung von Merkmalen. Sie könnten beispielsweise einen Dienst namens „Herzfrequenzmesser“ haben, der Merkmale wie „Herzfrequenzmessung“ enthält. Eine Liste der vorhandenen GATT-basierten Profile und Dienste finden Sie unter bluetooth.org.
Rollen und Verantwortlichkeiten
Wenn ein Gerät mit einem BLE-Gerät interagiert, sind Rollen und Verantwortlichkeiten auf zwei verschiedene Arten unterteilt:
Zentrale und periphere Geräte Das gilt für die BLE-Verbindung selbst: Das Gerät in der zentralen Rolle sucht nach Werbung und das Gerät in der peripheren Rolle sendet Werbung. Zwei Geräte, die nur die Peripherierolle unterstützen, können nicht miteinander kommunizieren. Das gilt auch für zwei Geräte, die nur die zentrale Rolle unterstützen.
GATT-Server und GATT-Client Damit wird festgelegt, wie die beiden Geräte miteinander kommunizieren, nachdem die Verbindung hergestellt wurde. Das Gerät in der Clientrolle sendet Anfragen an das Gerät in der Serverrolle, das sie erfüllt.
Um den Unterschied zwischen den Rollen „Zentralgerät“ und „Peripheriegerät“ und „Server“ und „Client“ zu verstehen, betrachten Sie ein Beispiel mit einem Android-Smartphone und einem BLE-fähigen Aktivitätstracker, der Sensordaten an das Smartphone zurücksendet.
Das Smartphone – das zentrale Gerät – sucht aktiv nach BLE-Geräten. Der Aktivitätstracker – das Peripheriegerät – sendet eine Werbung und wartet auf eine Verbindungsanfrage.
Nachdem das Smartphone und der Aktivitätstracker eine Verbindung hergestellt haben, beginnen sie, GATT-Metadaten miteinander zu übertragen. In diesem Fall sendet die auf dem Smartphone laufende App Datenanfragen und fungiert als GATT-Client. Der Aktivitätstracker erfüllt diese Anfragen und fungiert daher als GATT-Server.
Bei einem alternativen Design der App könnte das Smartphone stattdessen die Rolle des GATT-Servers übernehmen. Weitere Informationen finden Sie unter BluetoothGattServer.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# Bluetooth Low Energy\n\nAndroid provides built-in platform support for Bluetooth Low Energy (BLE) in the\ncentral role and provides APIs that apps can use to discover devices, query for\nservices, and transmit information.\n\nCommon use cases include the following:\n\n- Transferring small amounts of data between nearby devices.\n- Interacting with proximity sensors to give users a customized experience based on their current location.\n\nIn contrast to [classic Bluetooth](/develop/connectivity/bluetooth),\nBLE is designed for significantly lower power consumption. This allows apps to\ncommunicate with BLE devices that have stricter power requirements, such as\nproximity sensors, heart rate monitors, and fitness devices. \n\n**Caution:** When a user pairs their device with another device\nusing BLE, the data that's communicated between the two devices is\naccessible to **all** apps on the user's device.\n\n\nFor this reason, if your app captures sensitive data, you should implement\napp-layer security to protect the privacy of that data.\n\nThe basics\n----------\n\nFor BLE-enabled devices to transmit data between each other, they must first\nform a channel of communication. Use of the Bluetooth LE APIs requires you to\n[declare several permissions](/develop/connectivity/bluetooth/bt-permissions)\nin your manifest file. Once your app has permission to use Bluetooth, your app\nneeds to access the `BluetoothAdapter` and\n[determine if Bluetooth is available on the device](/develop/connectivity/bluetooth/setup)\nIf Bluetooth is available, the device will\n[scan for nearby BLE devices](/develop/connectivity/bluetooth/ble/find-ble-devices).\nOnce a device is found, the capabilities of the BLE device are discovered by\n[connecting to the GATT server on the BLE device](/develop/connectivity/bluetooth/ble/connect-gatt-server).\nOnce a connection is made,\n[data can be transferred with the connected device](/develop/connectivity/bluetooth/ble/transfer-ble-data)\nbased on the available services and characteristics.\n\nKey terms and concepts\n----------------------\n\nThe following is a summary of key BLE terms and concepts:\n\n-\n\n **Generic Attribute Profile (GATT)**\n : The GATT profile is a general specification for sending and receiving short\n pieces of data known as \"attributes\" over a BLE link. All current BLE\n application profiles are based on GATT. Review the [Android BluetoothLeGatt\n sample](https://github.com/android/platform-samples/tree/main/samples/connectivity/bluetooth/ble/src/main/java/com/example/platform/connectivity/bluetooth/ble)\n on GitHub to learn more.\n-\n\n **Profiles**\n : The **Bluetooth SIG** defines many\n [profiles](https://www.bluetooth.org/en-us/specification/adopted-specifications)\n for BLE devices. A profile is a specification for how a device works in a\n particular application. Note that a device can implement more than one\n profile. For example, a device could contain a heart rate monitor and a\n battery level detector.\n-\n\n **Attribute Protocol (ATT)**\n : GATT is built on top of the Attribute Protocol (ATT). This is also referred to\n as GATT/ATT. ATT is optimized to run on BLE devices. To this end, it uses as\n few bytes as possible. Each attribute is uniquely identified by a Universally\n Unique Identifier (UUID), which is a standardized 128-bit format for a string\n ID used to uniquely identify information. The *attributes* transported by ATT\n are formatted as *characteristics* and *services*.\n-\n\n **Characteristic**\n : A characteristic contains a single value and 0-n descriptors that describe the\n characteristic's value. A characteristic can be thought of as a type,\n analogous to a class.\n-\n\n **Descriptor**\n : Descriptors are defined attributes that describe a characteristic value. For\n example, a descriptor might specify a human-readable description, an\n acceptable range for a characteristic's value, or a unit of measure that is\n specific to a characteristic's value.\n-\n\n **Service**\n : A service is a collection of characteristics. For example, you could have a\n service called \"Heart Rate Monitor\" that includes characteristics such as\n \"heart rate measurement.\" You can find a list of existing GATT-based profiles\n and services on [bluetooth.org](https://www.bluetooth.org/en-us/specification/adopted-specifications).\n\n### Roles and responsibilities\n\nWhen a device interacts with a BLE device, roles and responsibilities are\ndivided in two different ways:\n\n- **Central versus peripheral.** This applies to the BLE connection itself---the\n device in the central role scans, looking for advertisement, and the device in\n the peripheral role advertises. Two devices that only support the peripheral\n role can't talk to each other, and neither can two devices that only support\n the central role.\n\n- **GATT server versus GATT client.** This determines how the two devices talk\n to each other after they've established the connection. The device in the\n client role sends requests for data, and the device in the server role\n fulfills them.\n\nTo understand the distinction between the central-peripheral and server-client\nrole divisions, consider an example where you have an Android phone and a\nBLE-enabled activity tracker that reports sensor data back to the phone.\n\n- The phone---the *central* device---actively scans for BLE devices. The activity\n tracker---the *peripheral* device---advertises and waits to receive a request for\n connection.\n\n- After the phone and the activity tracker have established a connection, they\n start transferring GATT metadata to each other. In this case, the app running\n on the phone sends requests for data, so it acts as the *GATT client* . The\n activity tracker fulfills those requests, so it acts as the *GATT server*.\n\nAn alternative design of the app might involve the phone playing the GATT server\nrole instead. See\n[`BluetoothGattServer`](/reference/android/bluetooth/BluetoothGattServer) for\nmore information."]]
