企业官网建设流程全解析

简介：面向Android蓝牙开发初学者和物联网应用开发者的完整源码包，以实际工程演示蓝牙初始化、BLE扫描、设备连接与数据读写等核心技术路线，解决不会调用系统蓝牙API、不知如何组织项目结构的常见问题。包体共23个文件，内含Java源码、class编译产物、AndroidManifest.xml配置、APK安装包及DEX可执行文件，还有PNG图标和XML布局资源；整个压缩包仅约91KB，结构紧凑，便于快速查看与学习。源码从BluetoothManager获取BluetoothAdapter开始，覆盖startScan扫描、ScanCallback回调解析设备地址/名称/RSSI、connectGatt建立GATT连接，以及readCharacteristic/writeCharacteristic数据读写等关键环节，并涉及权限配置与不同扫描模式处理。可直接导入Eclipse工程运行观察效果，配套资源包含Android蓝牙开发的基础示例，能帮助读者将官方API文档落地成可运行的代码，适合课程设计、毕业设计或实际项目前期调研。已有208人学习下载，是一份轻量实用的Android蓝牙开发参考资源。 很多朋友在找“android 蓝牙开发源码”的时候，大概都是同一个心态：GitHub 上搜了一堆项目，不是三四年前的老 Demo，就是连编译都过不了的半成品；好不容易跑起来一个，发现在自己真机上扫码配对、数据收发各种莫名失败。这篇文章不搞虚的，直接把我自己在经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）两条开发线上的完整源码思路、核心代码片段、权限适配和调试手段全部拆开讲，覆盖从 Android Studio 环境准备到 RSSI 测距、蓝牙打印、ESP32 联动的实际落地场景。内容更偏向“能直接抄作业”的工程实现，而不是贴一堆官网文档翻译。

我把这些年做蓝牙项目踩过的坑、验证过的写法、以及那些网上搜不到却又极其关键的细节都放在后面，希望能帮你在拿到源码之后少走几周弯路。

1. 蓝牙开发前的第一道坎：权限与系统版本适配

1.1 不同 Android 版本下的权限模型

Android 蓝牙开发看着简单，实际一上手就会碰到权限问题，而且 Android 12（API 31）之后权限模型发生了翻天覆地的变化，网上很多老源码在这里就直接废了。

如果你还在用targetSdkVersion 30以下的旧项目，权限只需要声明三个：

<uses-permission android:name="android.permission.BLUETOOTH" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

但一旦 targetSdk 升到 31 及以上，Android 把蓝牙权限从位置权限中彻底拆了出来，新增了三个运行时权限：

<uses-permission android:name="android.permission.BLUETOOTH_SCAN" /> <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" /> <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />

其中BLUETOOTH_SCAN对应扫描设备，BLUETOOTH_CONNECT对应连接和配对，BLUETOOTH_ADVERTISE对应广播。注意这里有个很阴间的细节：如果你的应用只做中心设备（Central）去扫描和连接外设，那BLUETOOTH_ADVERTISE可以不申请；但如果你的手机要作为外设（Peripheral）被别的设备扫描到，就必须申请。

不过别高兴太早，Google 的兼容逻辑是从 Android 12 开始才强制新权限，所以你在代码里要同时保留旧权限声明，否则在 Android 11 及以下的设备上安装时会直接因缺少权限崩溃。我项目里的做法是直接把两套权限全部声明，运行时按系统版本动态申请：

private fun checkPermissions(): Boolean { val permissions = mutableListOf<String>() if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { permissions.add(Manifest.permission.BLUETOOTH_SCAN) permissions.add(Manifest.permission.BLUETOOTH_CONNECT) if (isPeripheralMode) { permissions.add(Manifest.permission.BLUETOOTH_ADVERTISE) } } else { permissions.add(Manifest.permission.BLUETOOTH) permissions.add(Manifest.permission.BLUETOOTH_ADMIN) permissions.add(Manifest.permission.ACCESS_FINE_LOCATION) } // 低版本还需要定位权限用于扫描结果回调 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.S) { permissions.add(Manifest.permission.ACCESS_FINE_LOCATION) } // 动态请求... }

1.2 一个让无数人崩溃的细节：扫描必须开定位服务

很多新手照着官方文档写好了 BLE 扫描代码，结果在真机上一扫就报错或者回调一直没有数据，最后发现是手机的位置服务没打开。在 Android 6.0 到 Android 11 这个区间，系统把蓝牙扫描结果绑定到了定位服务上，你必须同时满足三个条件才能拿到扫描结果：

• 已经授予ACCESS_FINE_LOCATION权限
• 系统定位服务处于开启状态
• 蓝牙本身已开启

国产 ROM 上更狠，部分机型即使定位服务开着，还需要在应用权限设置里额外给“位置信息”的“始终允许”而非“仅使用期间允许”。所以代码里判断到扫描失败时，最好提示用户去检查系统定位开关，不要只傻傻地请求蓝牙权限。我在onScanFailed回调里通常会给一个 Dialog，用 intents 引导用户直接跳转到系统定位设置页：

val intent = Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS) startActivity(intent)

这个细节在 Android 12 上有所缓解，因为扫描权限已经独立出来，但很多老设备用户依然存在，做兼容的时候保留这个逻辑没坏处。

2. 经典蓝牙BR/EDR：配对、Socket与数据传输源码拆解

2.1 蓝牙的开启、扫描与主动配对

经典蓝牙和 BLE 在系统 API 层面是完全两套东西。BR/EDR 走的是BluetoothAdapter+BluetoothSocket这条线，主要用于传输速率要求高、数据量大的场景，比如蓝牙串口透传、蓝牙打印机、蓝牙手柄等。

开启蓝牙时有一个小坑：BluetoothAdapter.enable()是异步操作，直接调用后立刻去扫描会发现蓝牙没准备好。正确做法是注册ACTION_STATE_CHANGED广播，监听状态切换到STATE_ON再执行后续动作：

val filter = IntentFilter(BluetoothAdapter.ACTION_STATE_CHANGED) registerReceiver(stateReceiver, filter) private val stateReceiver = object : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { when (intent.getIntExtra(BluetoothAdapter.EXTRA_STATE, -1)) { BluetoothAdapter.STATE_ON -> startDiscovery() } } }

扫描经典蓝牙设备用的是startDiscovery()，它会同时扫描 BR/EDR 和 BLE 设备，结果都通过ACTION_FOUND广播返回。设备对象可以通过device.bondState判断是否已配对，通过device.type判断设备类型（DEVICE_TYPE_CLASSIC/DEVICE_TYPE_LE/DEVICE_TYPE_DUAL）。

真正容易让人翻车的是主动配对。在一个物联网项目里，你需要让手机自动去连接某个已经配对过的蓝牙设备，但系统只会弹出系统级配对对话框，无法在应用内直接控制。很多业务场景里用户已经配对过了，这个对话框会一闪而过；但如果设备之前没有配对，你就得提前触发createBond()：

val method: Method = device.javaClass.getMethod("createBond") method.invoke(device)

这个createBond()是隐藏 API，通过反射调用，在 Android 8.0 等版本上会有非 SDK 接口限制警告，但实测下来目前仍然可用。如果你发现设备没有弹窗也没绑定成功，大概率是因为设备已经存在旧的配对信息或者设备端不支持某种配对方式，需要先调用removeBond()删除旧绑定再重新createBond()。

2.2 RFCOMM Socket通信封装

配对完成后的数据通道就是BluetoothSocket。经典蓝牙最常用的 UUID 是 SPP（串口)的固定值：

00001101-0000-1000-8000-00805F9B34FB

这个 UUID 代表 SerialPortProfile，几乎所有蓝牙串口透传模块、蓝牙打印机都支持。连接方式有两种：一种是createRfcommSocketToServiceRecord(uuid)，另一种是createInsecureRfcommSocketToServiceRecord(uuid)。前者需要对方设备做配对认证，后者不需要，很多时候为了省事直接走 insecure 反而更快更稳。

下面是完整的客户端连接模板：

class ClassicBluetoothClient(private val device: BluetoothDevice) { private var socket: BluetoothSocket? = null private var inputStream: InputStream? = null private var outputStream: OutputStream? = null fun connect() { // 连接前先取消扫描，否则会明显降低连接速度 BluetoothAdapter.getDefaultAdapter()?.cancelDiscovery() socket = try { device.createInsecureRfcommSocketToServiceRecord(SPP_UUID) } catch (e: IOException) { // 部分设备需要走反射方法才能建立连接 val method = device.javaClass.getMethod( "createRfcommSocket", Int::class.javaPrimitiveType ) socket = method.invoke(device, 1) as BluetoothSocket socket!! } socket?.connect() inputStream = socket?.inputStream outputStream = socket?.outputStream } fun send(data: ByteArray) { outputStream?.write(data) outputStream?.flush() } fun close() { inputStream?.close() outputStream?.close() socket?.close() } }

这里有个业务上经常忽略的点：cancelDiscovery()很关键。如果你正在扫描的同时去 connect，系统会因射频资源竞争导致连接超时或失败，实测概率非常高。所以连接动作前先取消扫描是必须的。

2.3 实际开发中要规避的Socket坑

第一，connect()是阻塞调用，绝对不能放到主线程。Android 系统会直接抛NetworkOnMainThreadException，这不是网络请求专属，任何 Socket 连接都会被拦截。我惯用的做法是丢到一个单线程的ExecutorService里，回调通过 Handler 切回 UI 线程更新状态。

第二，读数据的循环别用while (inputStream.read() != -1)，蓝牙 Socket 在正常断开时不一定返回 -1，反而可能一直阻塞。正确做法是定义超时时间，socket.soTimeout = 5000，再按业务帧格式解析。或者用available()先探测可读字节数，避免 read 阻塞。

第三，设备端如果强制断开，客户端可能不会立刻感知，需要有心跳包机制。比如每 2 秒发一个空帧或者特定心跳字节，连续 N 次无响应就判定链路断开并主动清理资源。这个不是蓝牙规范强制要求的，但实际项目中不做心跳，全靠异常捕获，链路稳定性会差一大截。

3. BLE低功耗蓝牙：扫描、连接与GATT通信完整源码

3.1 为什么要用GATT这套抽象模型

BLE 和经典蓝牙最大的区别是它不支持 Socket 流式传输，所有数据交互都建立在 GATT(Generic Attribute Profile) 分层模型上。你可以把 GATT 理解成一套树状文件系统：

• Profile 是根节点，代表一个应用场景
• Service 是目录，用 UUID 标识
• Characteristic 是文件，里面有 Value 和 Descriptor
• Descriptor 是文件的属性描述，比如通知开关

实际开发中我们就是去找 Service 下的 Characteristic，然后对它执行读取（Read）、写入（Write）和订阅通知（Notify）。很多初学者不理解为什么 BLE 这么绕，不直接给一个收发数据的接口，这是因为 BLE 本身就是为低功耗、小数据量设计的，它把所有能力都抽象成属性，设备生产商也可以自定义私有 UUID 来做差异化功能，所以先理解这个树状模型对排查问题特别有帮助。

3.2 一次标准BLE连接流程的源码骨架

BLE 的连接流程分为三步：扫描 -> 连接 -> 发现服务。下面的代码片段可以直接复用。

扫描部分用BluetoothLeScanner：

val scanner = bluetoothAdapter.bluetoothLeScanner val scanCallback = object : ScanCallback() { override fun onScanResult(callbackType: Int, result: ScanResult) { val device = result.device val rssi = result.rssi val scanRecord = result.scanRecord // 这里可以依据设备名、广播包里的Service UUID做过滤 if (device.name?.contains("ESP32") == true) { connectToDevice(device) } } override fun onScanFailed(errorCode: Int) { // 常见错误码：1 表示BLE扫描已被关闭，2 表示内部错误 } } // 使用ScanFilter预过滤，能有效降低功耗 val filters = listOf( ScanFilter.Builder() .setServiceUuid(ParcelUuid.fromString("0000ffe0-0000-1000-8000-00805f9b34fb")) .build() ) val settings = ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) .build() scanner.startScan(filters, settings, scanCallback)

注意一个 Android 7.0 之后引入的限流机制：官方建议扫描周期不超过 30 秒，且不要在前台一直扫。如果你的 App 需要长时间扫描，应该采用“扫 10 秒停 5 秒”的间歇扫描策略，或者引导用户点击“扫描”按钮后再启动。

连接部分用connectGatt，这里有个大坑：系统对同一台设备的 Gatt 连接是共享的，如果你上一次连接没正确关闭，下一次connectGatt可能返回一个已经断开的旧实例，回调也不再触发。所以每次连接前先尝试gatt?.disconnect()、gatt?.close()清干净。

private var gatt: BluetoothGatt? = null fun connectToDevice(device: BluetoothDevice) { gatt?.disconnect() gatt?.close() // autoConnect=false 表示主动连接，速度更快且失败会立刻回调 gatt = device.connectGatt(context, false, gattCallback) } private val gattCallback = object : BluetoothGattCallback() { override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) { if (newState == BluetoothProfile.STATE_CONNECTED) { // 连接成功之后必须主动发现服务，才能拿到可操作的Characteristic gatt.discoverServices() } else if (newState == BluetoothProfile.STATE_DISCONNECTED) { // 业务层在这里处理重连逻辑 } } override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) { if (status != BluetoothGatt.GATT_SUCCESS) return // 这里遍历服务和特征值，找到目标Characteristic val service = gatt.getService(UUID.fromString("0000ffe0-0000-1000-8000-00805f9b34fb")) val characteristic = service?.getCharacteristic(UUID.fromString("0000ffe1-0000-1000-8000-00805f9b34fb")) // 保存实例，之后所有读写都基于它 writeCharacteristic = characteristic readCharacteristic = characteristic // 如果是通知型特征值，需要先开启通知 enableNotification(characteristic) } }

3.3 数据分包、MTU和通知订阅

BLE 每次传输的数据量很小，默认 MTU（最大传输单元）只有 23 字节，其中包含 3 字节的 ATT 头，所以应用层每次最多只能发 20 字节。你如果想一次发一张 4KB 的图片，就必须在业务层分包。

一个比较土但稳定的做法是在数据帧前面加一个序号头，接收方按序号拼接：

fun sendLargeData(data: ByteArray) { val chunkSize = 20 var offset = 0 var seq = 0 while (offset < data.size) { val length = minOf(chunkSize, data.size - offset) val frame = ByteArray(length + 1) frame[0] = seq.toByte() System.arraycopy(data, offset, frame, 1, length) writeCharacteristic?.value = frame gatt?.writeCharacteristic(writeCharacteristic) offset += length seq++ } }

如果要提升单包大小，可以在连接成功后协商 MTU：gatt.requestMtu(247)。大部分设备支持 247 字节，这样应用层单包能到 244 字节，传输效率提升一个量级。不过协商是异步的，要在onMtuChanged回调里确认最终值，而且部分老旧外设不支持大 MTU，代码要做好降级处理。

通知订阅是 BLE 里数据上行（外设到手机）的主要方式，必须设置 Characteristic 的NOTIFY属性才能收到数据：

fun enableNotification(characteristic: BluetoothGattCharacteristic) { gatt?.setCharacteristicNotification(characteristic, true) val descriptor = characteristic.getDescriptor( UUID.fromString("00002902-0000-1000-8000-00805f9b34fb") ) ?: return descriptor.value = BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt?.writeDescriptor(descriptor) }

之后外设主动推送的数据会进入onCharacteristicChanged回调。这里尤其要注意，所有回调都跑在 Binder 线程，不是主线程，如果你在里面操作 UI 或更新数据库，必须切线程，否则会出现各种莫名其妙的崩溃。

4. 从热词看真实业务：BLE测距、蓝牙打印与ESP32控制

4.1 RSSI测距的工程化做法

网络热词里“蓝牙测距”出现的频率一直不低。BLE 测距本质上不是蓝牙协议的功能，而是通过 RSSI（接收信号强度指示）反推距离。原理是信号在传播过程中会衰减，距离越远信号越弱，经典的对数衰减模型是：

d = 10 ^ ((A - RSSI) / (10 * n))

其中 A 是距离设备 1 米时测得的 RSSI 绝对值，n 是环境衰减因子（通常 2 到 4 之间）。比如你测到设备 1 米处的 RSSI 是 -59，当前是 -73，n 取 2.5，那么估算距离就是：

d = 10 ^ ((-59 - (-73)) / (10 * 2.5)) ≈ 10 ^ (14 / 25) ≈ 3.65 米

实际工程里千万别直接拿单次 RSSI 计算，因为信号受人体遮挡、墙壁反射、多径效应影响极大，波动能到 ±10dB。稳定做法是采集一段时间内的多个 RSSI 值做滑动平均或卡尔曼滤波，同时丢弃掉异常突变值。我自己习惯用滑动窗口加中值滤波，窗口取 5，效果已经足够。

更要明确的是，蓝牙测距只能做到“近距离判断”和“区域判定”，比如“靠近展台 3 米范围内触发签到”“离开车位 10 米后自动锁车”，很难做到厘米级或者亚米级定位。如果需要更精确的定位，建议融合惯导或者 UWB，这个在立项阶段就要跟客户讲清楚。

4.2 蓝牙打印的SPP连接与ESC/POS指令

蓝牙打印机是目前很成熟的应用场景，Android 端绝大多数打印机走的是 SPP 协议，也就是我前面讲到的经典蓝牙 Socket。拿到 Socket 之后，往输出流里写入 ESC/POS 指令即可控制打印。

比如打印一行文字并换行：

val bytes = byteArrayOf( 0x1B, 0x40, // ESC @ 初始化打印机 0x1B, 0x61, 0x01, // ESC a 1 居中对齐 0x31, 0x32, 0x33, // 数据 "123" 0x0A, // LF 换行 ) outputStream?.write(bytes)

真正要注意的是不同牌子打印机的指令集存在差异，比如部分热敏打印机默认不支持 GBK 中文编码，你需要发送ESC 0x26切换字符集，或者在写入前把字符串转成 GBK 编码：

val gbkBytes = "测试文字".toByteArray(Charset.forName("GBK"))

我在接一个小票打印机时就被坑过：打印中文全是乱码，后来用 Wireshark 抓了厂商 Windows 驱动的数据对比，才发现缺了字符集切换指令。这种问题光看文档很难发现，最好是先拿官方工具打印一张自检页，再看它初始化的字节序列。

4.3 手机通过蓝牙控制ESP32的应用示例

ESP32 是低成本物联网开发板，支持 BLE 和经典蓝牙，热词里“蓝牙app控制esp32”也是高频搜索。这类应用典型架构是：ESP32 作为 GATT Server，手机 App 作为 GATT Client，通过写一个控制特征值来下发 GPIO 控制指令。

ESP32 端通常用 Arduino 或 ESP-IDF 实现一个 BLE Server，定义两个 Service：

• 一个设备信息 Service（必选）
• 一个自定义数据 Service，包含读写两个 Characteristic

手机端连接后，向目标特征值写入指令即可。这里有一个在实际项目里发现的问题：部分 ESP32 示例默认只支持单连接，如果手机调试时反复扫描、连接、断开，板子上的 BLE 协议栈可能卡死，出现“能扫描到但连不上”的情况。遇到这种情况先给板子断电上电，或者按板子上的 EN 键复位，一般都能恢复。

另外，ESP32 的 BLE 广播名默认是ESP32，但实际项目里建议改成带设备编号的名称，比如ESP32-GATE-01，这样手机端 ScanFilter 可以直接按名字前缀过滤，也方便后期管理多台设备。

5. 源码调试利器与高频踩坑记录

5.1 btsnoop抓包与Wireshark分析

蓝牙开发中最痛苦的场景是：连接都正常，但数据就是不对，不知道是手机端发错指令，还是设备端回包异常。这时候靠日志打印效率太低，正确手段是抓蓝牙 HCI 层数据包。

Android 系统内置了蓝牙 HCI Snoop Log 功能，打开方式每个厂商略有差异，但大体路径一致：

• 进入开发者选项
• 找到“蓝牙 HCI 信息收集日志”（Bluetooth HCI Snoop Log），打开
• 重启蓝牙，复现问题后关闭开关
• 日志文件会生成在/sdcard/MIUI/log或/sdcard/log或/storage/emulated/0/下，文件名通常是btsnoop_hci.log

把这个文件拷出来，用 Wireshark 打开，然后配置空口解码。之后你能看到 HCI 层所有蓝牙交互过程，包括 ATT 读写请求、错误码、断连原因。比如设备端“连接后异常断开”，日志里会明确告诉你远程设备发的断开原因码是 0x08（Connection Timeout）还是 0x13（Remote User Terminated Connection），这两个的处理思路完全不一样。

抓包真的比加日志高效太多，我在处理几个打印机兼容性问题时，就是靠对比正常设备和异常设备的 HCI 日志定位到是初始化序列不同，而不是打印机坏了。

5.2 几个我几乎每个项目都遇到过的坑

做蓝牙开发久了，会发现很多问题和业务无关，纯粹是系统兼容或代码时序问题。我总结几个高频的，大家可以对照自查。

第一个是** ScanFilter 和实际广播数据不匹配导致扫描不到设备**。很多设备广播包里的 Service UUID 与连接后 GATT 层暴露的 Service UUID 不是同一个。扫描时用的是广播包里的 UUID，连接后则是通过discoverServices获取连接态 UUID。有些新手把这两个混为一谈，ScanFilter 填了一个，发现服务时又用另一个去找，结果怎么都连不上。

第二个是连接状态回调里的重连风暴。很多设备离开范围会触发onConnectionStateChange断开回调，代码里如果直接在回调里重连，信号弱时会出现“断开-重连-再断开”的死循环，把手机电量耗光。我的写法是每次重连都做指数退避，第一次 1 秒、第二次 2 秒、第三次 4 秒，最多重试 5 次，然后停下来等用户手动触发。

第三个是多个 Gatt 回调竞争。如果一个页面里同时对两台设备做连接，或者连接流程和接收通知在同一个 GattCallback 实例里串用，很容易出现回调数据错乱。最好的做法是每个设备单独建一个 Gatt 实例和回调对象，连接状态机独立维护，我见过太多项目为了省事共用回调，结果查了两三天才发现是串对象了。

第四个坑在Activity 销毁时没有及时关闭 Gatt。如果不关闭，系统会一直持有连接，后续再次打开页面就会建立第二个连接，造成设备端无法再接入新连接。所以onDestroy里必须：

override fun onDestroy() { super.onDestroy() gatt?.disconnect() gatt?.close() gatt = null }

5.3 一个可直接参照的Demo工程结构

看完上面的内容，如果你准备从零搭一个可运行的蓝牙工程，我建议 Demo 的包结构按下面这样组织，后面加功能模块也方便：

app/src/main/java/com/example/ble/ ├── BluetoothManager.kt // 统一入口，封装扫描、连接、数据收发 ├── scan/ │ ├── ScanFilterFactory.kt // 构建不同业务的扫描过滤器 │ └── BleScanController.kt // 扫描状态机，处理开启/停止/超时 ├── connect/ │ ├── GattClient.kt // 单个设备的Gatt连接管理 │ └── GattCallbackImpl.kt // 连接状态、服务发现、数据回调 ├── protocol/ │ ├── DataPackager.kt // 业务数据分包、粘包处理 │ └── CommandBuilder.kt // 各设备指令构建 └── ui/ ├── DeviceListActivity.kt // 设备扫描列表页 └── ChatActivity.kt // 收发数据测试页

这套结构比较清晰，把设备无关的扫描逻辑和单设备 Gatt 管理拆开，后面接入打印机、ESP32、手环等不同外设，只需要扩展 CommandBuilder 和 Protocol 层即可，不需要改动核心连接代码。

最后再分享一个小技巧：Android Studio 设置里把 logcat 按进程过滤后，再用蓝牙关键词过滤，能省不少时间。如果你是用 Android Studio 的新手，界面默认是英文，菜单栏“File -> Settings -> Plugins”里搜 Chinese Language 插件，装完重启就是中文界面，比下载汉化版安全得多。开发调试阶段，把手机的“蓝牙日志”开关打开，配合 logcat 崩溃栈，90% 的蓝牙问题都能在十分钟内定位到原因。

本文还有配套的精品资源，点击获取