Bluetooth Low Energy
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Android zapewnia wbudowane wsparcie platformy dla Bluetootha Low Energy (BLE) w centralnej roli oraz interfejsy API, których aplikacje mogą używać do wykrywania urządzeń, wysyłania zapytań do usług i przesyłania informacji.
Oto typowe przypadki użycia:
- Przenoszenie niewielkich ilości danych między urządzeniami w pobliżu.
- Interakcja z czujnikami zbliżeniowymi w celu zapewnienia użytkownikom niestandardowych wrażeń na podstawie ich bieżącej lokalizacji.
W przeciwieństwie do klasycznego Bluetootha funkcja BLE została zaprojektowana z myślą o znacznie mniejszym zużyciu energii. Dzięki temu aplikacje mogą komunikować się z urządzeniami BLE, które mają bardziej rygorystyczne wymagania dotyczące zasilania, np. czujniki zbliżeniowe, pulsory czy urządzenia fitness.
Uwaga: gdy użytkownik sparuje swoje urządzenie z innym urządzeniem za pomocą BLE, dane przesyłane między tymi dwoma urządzeniami są dostępne dla wszystkich aplikacji na urządzeniu użytkownika.
Dlatego jeśli Twoja aplikacja rejestruje dane wrażliwe, musisz zaimplementować zabezpieczenia na poziomie aplikacji, aby chronić prywatność tych danych.
Podstawy
Aby urządzenia obsługujące BLE mogły przesyłać dane między sobą, muszą najpierw utworzyć kanał komunikacji. Aby korzystać z interfejsów Bluetooth LE API, musisz zadeklarować kilka uprawnień w pliku manifestu. Gdy aplikacja ma uprawnienia do korzystania z Bluetootha, musi uzyskać dostęp do BluetoothAdapter, aby sprawdzić, czy Bluetooth jest dostępny na urządzeniu. Jeśli tak, urządzenie skanuje dostępne urządzenia BLE.
Po znalezieniu urządzenia możliwości urządzenia BLE są wykrywane przez połączenie z serwerem GATT na urządzeniu BLE.
Po nawiązaniu połączenia dane mogą być przesyłane za pomocą połączonego urządzenia w zależności od dostępnych usług i charakterystyki.
Kluczowe terminy i pojęcia
Poniżej znajdziesz podsumowanie kluczowych pojęć i terminów związanych z BLE:
- Ogólny profil atrybutów (GATT)
- Profil GATT to ogólna specyfikacja wysyłania i odbierania krótkich fragmentów danych, zwanych „atrybutami”, przez połączenie BLE. Wszystkie obecne profile aplikacji BLE są oparte na GATT. Aby dowiedzieć się więcej, zapoznaj się z przykładem kodu Android BluetoothLeGatt na GitHubie.
- Profile
- Organizacja Bluetooth SIG definiuje wiele profili dla urządzeń BLE. Profil to specyfikacja sposobu działania urządzenia w konkretnej aplikacji. Pamiętaj, że urządzenie może mieć więcej niż 1 profil. Urządzenie może na przykład zawierać monitor tętna i detektor poziomu naładowania baterii.
- Protokół ATT
- Protokół GATT opiera się na protokole Attribute Protocol (ATT). Jest to również nazywane GATT/ATT. Zasady ATT są zoptymalizowane pod kątem wyświetlania na urządzeniach BLE. W tym celu używa jak najmniejszej liczby bajtów. Każdy atrybut jest jednoznacznie identyfikowany przez unikalny identyfikator uniwersalny (UUID), który jest standardowym 128-bitowym formatem identyfikatora ciągu tekstowego używanego do jednoznacznego identyfikowania informacji. Atrybuty przenoszone przez ATT są sformatowane jako cechy i usługi.
- Cecha
- Charakterystyka zawiera jedną wartość i 0–n elementów opisujących tę wartość. Charakterystykę można traktować jako typ, który jest analogiczny do klasy.
- Descriptor
- Deskryptory to zdefiniowane atrybuty opisujące wartość charakterystyczną. Na przykład deskryptor może zawierać opis zrozumiały dla człowieka, dopuszczalny zakres wartości cechy lub jednostkę miary właściwą dla wartości cechy.
- Usługa
- Usługa to zbiór cech. Możesz na przykład utworzyć usługę o nazwie „Pulsometr”, która oferuje parametry takie jak „pomiar tętna”. Listę istniejących profili i usług opartych na GATT znajdziesz na stronie bluetooth.org.
Role i obowiązki
Gdy urządzenie wchodzi w interakcję z urządzeniem BLE, role i odpowiedzialnie są rozdzielane na 2 sposoby:
Centralne a peryferyjne Dotyczy to samego połączenia BLE: urządzenie w roli centralnej skanuje, szukając reklamy, a urządzenie w roli peryferyjnej wyświetla reklamę. Dwa urządzenia, które obsługują tylko rolę peryferyjną, nie mogą ze sobą komunikować się nawzajem, tak samo jak dwa urządzenia, które obsługują tylko rolę centralną.
Serwer GATT a klient GATT Określa ono sposób komunikacji między dwoma urządzeniami po nawiązaniu połączenia. Urządzenie z rolą klienta wysyła żądania danych, a urządzenie z rolą serwera je realizuje.
Aby zrozumieć różnicę między podziałem ról na urządzenia peryferyjne i serwery oraz klientów, rozważ przykład, w którym masz telefon z Androidem i śledzący aktywność tracker z obsługą BLE, który przekazuje dane z czujników z powrotem do telefonu.
Telefon (urządzenie centralne) aktywnie skanuje w poszukiwaniu urządzeń BLE. Tracker aktywności (urządzenie peryferyjne) reklamuje się i czeka na żądanie połączenia.
Gdy telefon i aktywność trackera nawiążą połączenie, zaczną przesyłać sobie nawzajem metadane GATT. W tym przypadku aplikacja działająca na telefonie wysyła żądania danych, więc działa jako klient GATT. Moduł do śledzenia aktywności spełnia te żądania, więc działa jak serwer GATT.
Alternatywny projekt aplikacji może polegać na tym, że telefon będzie pełnił rolę serwera GATT. Więcej informacji znajdziesz w sekcji BluetoothGattServer.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
