藍牙低功耗
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 在中央角色中提供內建的藍牙低功耗 (BLE) 平台支援,並提供應用程式可用於探索裝置、查詢服務和傳輸資訊的 API。
常見用途包括:
- 在鄰近裝置之間傳輸少量資料。
- 與接近度感應器互動,根據使用者的目前位置提供客製化體驗。
與傳統藍牙不同,BLE 的設計可大幅降低耗電量。這可讓應用程式與 BLE 裝置通訊,這些裝置的電力需求較嚴格,例如接近感應器、心率監測器和健身裝置。
注意:當使用者使用 BLE 將裝置與其他裝置配對時,兩部裝置之間傳輸的資料可供使用者裝置上的所有應用程式存取。
因此,如果您的應用程式擷取私密資料,應實作應用程式層安全性,以保護該資料的隱私權。
基本概念
支援 BLE 的裝置必須先建立通訊管道,才能在彼此之間傳輸資料。如要使用 Bluetooth LE API,您必須在資訊清單檔案中宣告多個權限。應用程式取得藍牙使用權限後,應用程式就必須存取 BluetoothAdapter
,並判斷裝置是否支援藍牙
如果支援藍牙,裝置就會掃描附近的 BLE 裝置。找到裝置後,系統會連線至 BLE 裝置上的 GATT 伺服器,藉此偵測 BLE 裝置的功能。連線完成後,您可以根據可用的服務和特徵,透過已連結的裝置傳輸資料。
重要詞彙與概念
以下是 BLE 重要術語和概念的摘要:
- 一般屬性設定檔 (GATT)
- GATT 設定檔是一種一般規格,可透過 BLE 連結傳送及接收稱為「屬性」的短資料片段。目前所有 BLE 應用程式設定檔都以 GATT 為基礎。詳情請參閱 GitHub 上的 Android BluetoothLeGatt 範例。
- 設定檔
- Bluetooth SIG 定義了許多 BLE 裝置的設定檔。設定檔是裝置在特定應用程式中運作方式的規格。請注意,裝置可以實作多個設定檔。舉例來說,裝置可能包含心率監測器和電池電量偵測器。
- 屬性通訊協定 (ATT)
- GATT 是建立在屬性通訊協定 (ATT) 之上,這也稱為 GATT/ATT。ATT 經過最佳化調整,適合在 BLE 裝置上執行。為此,它會盡可能使用最少的位元組。每個屬性都會透過通用專屬識別碼 (UUID) 進行專屬識別,這是用於識別資訊的字串 ID 的標準化 128 位元格式。ATT 傳輸的屬性會調整為「characteristics」和「services」格式。
- 特性
- 特徵包含單一值和 0 到 n 個描述項,用於說明特徵的值。特徵可視為一種類型,類似於類別。
- 描述元
- 描述元是定義的屬性,用於描述特徵值。舉例來說,描述元可能會指定人類可讀的說明、特性值的接受範圍,或特性值專屬的測量單位。
- 服務
- 服務是一組特性。舉例來說,您可以建立名為「心率監測器」的服務,其中包含「心率測量」等特徵。您可以在 bluetooth.org 上找到現有的 GATT 設定檔和服務清單。
角色和責任
當裝置與 BLE 裝置互動時,角色和職責會以兩種方式劃分:
如要瞭解中心-外圍裝置和伺服器-用戶端角色劃分的差異,請考慮以下範例:您有一部 Android 手機和支援 BLE 的活動追蹤器,可將感應器資料回報給手機。
應用程式的其他設計可能會讓手機扮演 GATT 伺服器的角色。詳情請參閱 BluetoothGattServer
。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[null,null,["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],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."]]