Android 4.3 及更高版本中提供的蓝牙低功耗 (BLE) 功能可在多个设备之间实现短促连接,以传输暴增的数据。未建立连接时,BLE 会处于睡眠模式。这样一来,BLE 可以提供比传统蓝牙更低的带宽和功耗。此功能适用于心率监测器或无线键盘等应用。如需使用 BLE,用户需要确保设备上安装支持 BLE 的芯片组。
实现
所有最新的 BLE 应用配置文件都基于通用属性配置文件 (GATT)。当 Android 设备与 BLE 设备互动时,发送信息的设备是服务器,而接收信息的设备则是客户端。Android 包括用于 BLE 的开发者 API,其中包含用于 GATT 服务器和 GATT 客户端之间互动的 API。如需充分利用 BLE API,请实现 Android 蓝牙 HCI 要求。
设备模式
使用 BLE 时,Android 设备可发挥外围设备、中心设备的作用,或同时发挥两者的作用。外围设备模式可让设备发送广告包。中心模式可让设备扫描广告。在同时发挥外围设备和中心设备的作用时,Android 设备可以一边在外围设备模式下发送广告,一边与其他 BLE 外围设备进行通信。支持蓝牙 4.1 及更低版本的设备只能在中心模式下使用 BLE。较旧的设备芯片组可能不支持 BLE 外围设备模式。
BLE 扫描
使用 BLE 时,Android 设备可以更高效地定位和扫描特定的蓝牙设备。BLE API 可让应用开发者创建过滤器,供他们从主机控制器查找参与度较低的设备。
用户可以通过以下方式停用系统级蓝牙后台扫描:依次转到设置 > 安全性和位置信息 > 位置信息 > 扫描,然后关闭蓝牙扫描开关。这不会影响对位置或本地设备的 BLE 扫描。
过滤扫描结果
Android 6.0 及更高版本在蓝牙控制器上提供 BLE 扫描和过滤器匹配功能。设备可以过滤扫描结果,并将与 BLE 设备相关的 found 和 lost 事件报告给应用处理器 (AP)。过滤功能也适用于批量扫描,这将有助于节省电量,因为 BLE 扫描已分流到固件中。批量扫描可降低 AP 因设备或信标的 BLE 扫描而唤醒的频率。
OnFound/OnLost 功能在蓝牙控制器中实现,然后经过测试以确认在扫描过程中未错过 BLE 设备。这样可以节省电量,并且还有以下好处:
对于 OnFound 事件,主 AP 在发现特定设备时唤醒。
对于 OnLost 事件,AP 在找不到特定设备时唤醒。
当附近设备在检测范围内时,框架应用会收到较少的无用通知。
连续扫描功能使框架应用能够在设备超出检测范围时收到通知。
扫描过滤器可根据发现的设备广播(OnFound 事件)创建。Java 层可以指定参数,例如首次发现(或自首次发现以来的指定广告数量)。用户可以使用广告包内容过滤器 HCI 命令实现 BLE 过滤。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-06-12。"],[],[],null,["Bluetooth Low Energy (BLE), available in Android 4.3 and higher, creates\nshort connections between devices to transfer bursts of data. BLE remains\nin sleep mode when not connected. This lets BLE provide lower bandwidth and\nreduced power consumption compared to Classic Bluetooth. BLE is ideal for\napps such as a heart-rate monitor or a wireless keyboard. To use BLE,\ndevices need to have a chipset that supports BLE.\n\nImplementation\n\nAll current BLE app profiles are based on the\n[Generic Attribute (GATT) Profile](https://www.bluetooth.com/specifications/gatt).\nWhen an Android-powered device interacts with a BLE device, the device that\nsends information is the server and the device that receives information is\nthe client. Android includes\n[developer APIs for BLE](https://developer.android.com/guide/topics/connectivity/bluetooth-le),\nincluding APIs for interactions between GATT servers and GATT clients. To\ntake full advantage of the BLE APIs, implement the\n[Android Bluetooth HCI Requirements](/docs/core/connect/bluetooth/hci_requirements).\n\nDevice modes\n\nWhen using BLE, an Android-powered device can act as a peripheral device, a\ncentral device, or both. Peripheral mode lets devices send advertisement\npackets. Central mode lets devices scan for advertisements. An Android\ndevice acting as both a peripheral and central device can communicate with\nother BLE peripheral devices while sending advertisements in peripheral\nmode. Devices supporting Bluetooth 4.1 and lower can use BLE only in\ncentral mode. Older device chipsets might not support BLE peripheral mode.\n\nBLE scanning\n\nAn Android-powered device can target and scan for specific Bluetooth devices\nmore efficiently when using BLE. BLE APIs let app developers create filters\nfor finding devices with less involvement from the host controller.\n| **Caution:** BLE scanning typically needs location permissions because BLE scanning identifies objects that can be used for geolocation. Turning off location services turns off Bluetooth scanning. n Android 12 and higher, apps that declare `neverForLocation` can get Bluetooth scanning results even when location services are off. For more details, see [Tristate location permissions](/docs/core/permissions/tristate-perms).\n\nLocation scanning\n\nA device's location services can use Bluetooth to detect Bluetooth beacons\nand provide a more accurate location. This is how users enable the feature:\n\n1. Go to **Settings** \\\u003e **Security \\& Location** \\\u003e **Location**.\n2. Check that the Location **On** /**Off** toggle is in the **On** position.\n3. Go to **Mode**.\n4. Select either **High accuracy** or **Battery saving** mode.\n\nIn Android 11 and lower, individual apps require location permissions to use\nBLE scanning, even if they're scanning only to find devices to connect to.\nIf the user disables location scanning, or doesn't grant an app location\npermissions, then the app won't receive any BLE scanning results.\n\nIn Android 12 and higher, the\n[`BLUETOOTH_SCAN`](https://developer.android.com/reference/android/Manifest.permission#BLUETOOTH_SCAN),\n[`BLUETOOTH_ADVERTISE`](https://developer.android.com/reference/android/Manifest.permission#BLUETOOTH_ADVERTISE),\nand\n[`BLUETOOTH_CONNECT`](https://developer.android.com/reference/android/Manifest.permission#BLUETOOTH_CONNECT)\npermissions can allow apps to scan for nearby devices without needing to\nrequest the location permission. For more information, see\n[Bluetooth permissions](https://developer.android.com/about/versions/12/features/bluetooth-permissions).\n\nUsers can disable system-level Bluetooth background scanning by going to\n**Settings** \\\u003e **Security \\& Location** \\\u003e **Location** \\\u003e **Scanning** and\nclicking the **Bluetooth scanning** toggle to the off position. This\ndoesn't affect BLE scanning for location or local devices.\n\nFilter scan results\n\nAndroid 6.0 and higher includes BLE scanning and filter-matching on the\nBluetooth controller. A device can filter scan results and report\n**found** and **lost** events related to BLE devices to the application\nprocessor (AP). Filtering also works for batch scans, which helps save\npower as the device offloads BLE scanning to the firmware. Batch scans\nreduce how often the AP wakes up due to BLE scanning for devices or\nbeacons.\n\nThe `OnFound`/`OnLost` feature is implemented in the Bluetooth controller\nand then tested to confirm that BLE devices aren't missed in scans. This\nprovides power savings, and it can also provide the following benefits:\n\n- For an `OnFound` event, the main AP wakes up upon the discovery of a specific device.\n- For an `OnLost` event, the AP wakes up when a specific device can't be found.\n- Framework apps get fewer unwanted notifications when a nearby device is in range.\n- Continuous scans enable framework apps to be notified when a device is out of range.\n\nA scan filter can be based on the discovery of a device's advertisements\n(the `OnFound` event). The Java layer can specify parameters such as first\ndiscovery (or a specified number of advertisements since first discovery).\nImplement BLE filtering using the\n[Advertising Packet Content Filter HCI command](/docs/core/connect/bluetooth/hci_requirements#advertising-packet-content-filter)."]]