Bluetooth Low Energy
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Android menyediakan dukungan platform bawaan untuk Bluetooth Hemat Energi (BLE) sebagai
peran pusat dan menyediakan API yang dapat digunakan aplikasi untuk menemukan perangkat, meminta
layanan, dan mengirimkan informasi.
Kasus penggunaan umum meliputi:
- Mentransfer sejumlah kecil data antar-perangkat terdekat.
- Berinteraksi dengan sensor kedekatan untuk memberi pengguna pengalaman khusus berdasarkan
lokasi mereka saat ini.
Berbeda dengan Bluetooth klasik,
BLE dirancang untuk konsumsi daya yang jauh lebih rendah. Hal ini memungkinkan aplikasi
berkomunikasi dengan perangkat BLE yang memiliki persyaratan daya yang lebih ketat, seperti
sensor kedekatan, pemantau detak jantung, dan perangkat kebugaran.
Perhatian: Saat pengguna menyambungkan perangkatnya dengan perangkat lain
menggunakan BLE, data yang dikomunikasikan antara kedua perangkat
dapat diakses oleh semua aplikasi di perangkat pengguna.
Karena alasan ini, jika aplikasi Anda mengambil data sensitif, Anda harus menerapkan keamanan lapisan aplikasi untuk melindungi privasi data tersebut.
Dasar-dasar
Agar perangkat yang kompatibel dengan BLE dapat mengirimkan data satu sama lain, perangkat tersebut harus membentuk saluran komunikasi terlebih dahulu. Penggunaan Bluetooth LE API mengharuskan Anda
mendeklarasikan beberapa izin
dalam file manifes. Setelah aplikasi memiliki izin untuk menggunakan Bluetooth, aplikasi
harus mengakses BluetoothAdapter
dan
menentukan apakah Bluetooth tersedia di perangkat
Jika Bluetooth tersedia, perangkat akan
memindai perangkat BLE di sekitar.
Setelah perangkat ditemukan, kemampuan perangkat BLE akan ditemukan dengan
terhubung ke server GATT di perangkat BLE.
Setelah koneksi dibuat,
data dapat ditransfer dengan perangkat yang terhubung
berdasarkan layanan dan karakteristik yang tersedia.
Istilah dan konsep utama
Berikut adalah ringkasan istilah dan konsep BLE utama:
- Profil Atribut Generik (GATT)
- Profil GATT adalah spesifikasi umum untuk mengirim dan menerima potongan data
pendek yang dikenal sebagai "atribut" melalui link BLE. Semua profil aplikasi BLE
saat ini didasarkan pada GATT. Tinjau contoh
Android BluetoothLeGatt
di GitHub untuk mempelajari lebih lanjut.
- Profil
- Bluetooth SIG menentukan banyak
profil
untuk perangkat BLE. Profil adalah spesifikasi untuk cara kerja perangkat dalam
aplikasi tertentu. Perhatikan bahwa perangkat dapat menerapkan lebih dari satu
profil. Misalnya, perangkat dapat berisi monitor detak jantung dan
detektor level baterai.
- Attribute Protocol (ATT)
- GATT dibuat di atas Attribute Protocol (ATT). Hal ini juga disebut
sebagai GATT/ATT. ATT dioptimalkan untuk dijalankan pada perangkat BLE. Untuk tujuan ini, DHCP menggunakan
sesedikit mungkin {i>byte<i}. Setiap atribut diidentifikasi secara unik oleh Universally Unique Identifier (UUID), yang merupakan format 128-bit terstandardisasi untuk ID string yang digunakan untuk mengidentifikasi informasi secara unik. Atribut yang ditransmisikan oleh ATT
diformat sebagai karakteristik dan layanan.
- Karakteristik
- Karakteristik berisi nilai tunggal dan deskriptor 0-n yang menjelaskan
nilai karakteristik. Karakteristik dapat dianggap sebagai jenis,
yang analog dengan class.
- Deskripsi
- Deskriptor adalah atribut yang didefinisikan yang menjelaskan nilai karakteristik. Misalnya, deskriptor dapat menentukan deskripsi yang dapat dibaca manusia, rentang yang dapat diterima untuk nilai karakteristik, atau unit pengukuran yang
khusus untuk nilai karakteristik.
- Layanan
- Layanan adalah kumpulan karakteristik. Misalnya, Anda dapat memiliki
layanan yang disebut "Pemantau Denyut Jantung" yang mencakup karakteristik seperti
"pengukuran detak jantung". Anda dapat menemukan daftar profil dan layanan
berbasis GATT yang ada di bluetooth.org.
Peran dan tanggung jawab
Saat perangkat berinteraksi dengan perangkat BLE, peran dan tanggung jawab
dibagi dengan dua cara yang berbeda:
Sentral versus periferal. Hal ini berlaku untuk koneksi BLE itu sendiri—perangkat
dalam peran sentral memindai, mencari iklan, dan perangkat dalam
peran periferal mengiklankan. Dua perangkat yang hanya mendukung peran periferal
tidak dapat saling berkomunikasi, begitu juga dua perangkat yang hanya mendukung
peran sentral.
Server GATT versus klien GATT. Ini menentukan cara kedua perangkat berkomunikasi
satu sama lain setelah berhasil membuat koneksi. Perangkat dalam
peran klien mengirimkan permintaan data, dan perangkat dalam peran server
memenuhinya.
Untuk memahami perbedaan antara pembagian peran pusat-periferal dan server-klien, pertimbangkan contoh saat Anda memiliki ponsel Android dan pelacak aktivitas yang kompatibel dengan BLE yang melaporkan data sensor kembali ke ponsel.
Ponsel—perangkat pusat—secara aktif memindai perangkat BLE. Pelacak
aktivitas—perangkat periferal—mengumumkan dan menunggu untuk menerima permintaan
koneksi.
Setelah ponsel dan pelacak aktivitas membuat koneksi, mereka
mulai mentransfer metadata GATT satu sama lain. Dalam hal ini, aplikasi yang berjalan
di ponsel mengirimkan permintaan data, sehingga bertindak sebagai klien GATT. Pelacak
aktivitas memenuhi permintaan tersebut, sehingga bertindak sebagai server GATT.
Desain alternatif aplikasi mungkin melibatkan ponsel yang memainkan peran server
GATT. Lihat
BluetoothGattServer
untuk
mengetahui informasi selengkapnya.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]