Androidble（蓝牙低功耗）中的坑和技巧

一、如何定义ble中service uuid&＃xff1f;

• 蓝牙标准规范里面定义了很多已经定义过的service uuid&＃xff0c;如果冲突了会造成很多意外的问题。
• 蓝牙的service uuid的格式如下
  UUID.fromString("00001234-0000-1000-8000-00805f9b34fb")
• 在Android可以简单的采用这个原则&＃xff1a;1、利用这个字符串【00002903-0000-1000-8000-00805f9b34fb】用第5-8位的数字做变化&＃xff0c;其他数字保持不变。比如
  UUID.fromString("00007777-0000-1000-8000-00805f9b34fb")
UUID.fromString("00009999-0000-1000-8000-00805f9b34fb")

二、ble中心设备开启扫描&＃xff0c;设置所关心的serviceuuid。

bluetoothLeScanner &＃61; mBluetoothAdapter.getBluetoothLeScanner();List filters &＃61; new ArrayList<>();ScanFilter filter &＃61; new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");).build();filters.add(filter);ScanSettings scanSettings &＃61; new ScanSettings.Builder().setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY).build();bluetoothLeScanner.startScan(filters, scanSettings, scanCallback);


new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");

三、ble外围设备可以在广播的时候设定AdvertiseData的magic number【manufacturerId 和 manufacturerSpecificData】。这样即使定义service uuid跟别人的有冲突&＃xff0c;也可以在中心过滤该magic number来找到符合自己需求的外围设备

• 外围构建AdvertiseData

AdvertiseData.Builder().setIncludeDeviceName(true).addServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb")).addManufacturerData(0x7777, new byte[]{0x07, 0x07}).build();


• 中心处理AdvertiseData中的

final ScanCallback scanCallback &＃61; new ScanCallback() {&＃64;Overridepublic void onScanResult(int callbackType, ScanResult result) {super.onScanResult(callbackType, result);ScanRecord scanRecord &＃61; result.getScanRecord();SparseArray mandufacturerData &＃61; scanRecord.getManufacturerSpecificData();


此时可以根据mandufacturerData来匹配自己设定的外围设备

四、什么时候ble的中心和外围才算真正的连接上&＃xff1f;&＃xff08;可以开始传输数据了&＃xff09;

在BluetoothGattCallback中的关于此问题有三步回调
1、public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState)

• 这是ble中心和外围连接后&＃xff0c;最先触发的回调。newstate等于BluetoothProfile.STATE_CONNECTED仅仅表示中心设备连接上了&＃xff0c;这个时候需要去调用BluetoothGatt去发现服务。

• 注意case1&＃xff0c;在new state为BluetoothProfile.STATE_DISCONNECTED时&＃xff0c;务必关掉BluetoothGatt&＃xff0c;因为每次调用mBluetoothGatt &＃61; device.connectGatt(SpeakerApp.appContext, false, mGattCallBack);都会生成新的对象&＃xff0c;而不会去主动关闭老的对象

• 注意case2&＃xff0c;133问题&＃xff0c;iPhone 和 某些Android手机作为旁支会出现蓝牙初始连接就是133&＃xff0c;此情况下应该立刻重新扫描连接。133问题链接

//iPhone 和 某些Android手机作为旁支会出现蓝牙初始连接就是133&＃xff0c;此情况下立刻重试 if (status &＃61;&＃61; 133) {RLog.d(TAG, "发生设备初始连接133情况&＃xff0c;需要重新扫描连接设备");mBluetoothGatt.close();//&＃xff01;&＃xff01;&＃xff01;需要去增加代码进行重新扫描重连return;}if (newState &＃61;&＃61; BluetoothProfile.STATE_CONNECTED) {mBluetoothGatt &＃61; gatt;mBluetoothGatt.discoverServices();} else if (newState &＃61;&＃61; BluetoothProfile.STATE_DISCONNECTED) {mBluetoothGatt.close();mBluetoothGatt &＃61; null;}


2、 public void onServicesDiscovered(BluetoothGatt gatt, int status)
mBluetoothGatt.discoverServices()执行后得到的callback&＃xff0c;如果状态为GATT_SUCCESS&＃xff0c;则可以获取ble旁支发起广播的service和descriptor&＃xff0c;把广播设为enable

mCharacteristic &＃61; service.getCharacteristic(UUID.fromString("00007770-0000-1000-8000-00805f9b34fb"));if (mCharacteristic &＃61;&＃61; null) {RLog.e(TAG, "Can&＃39;t find target characteristic.");return;}gatt.setCharacteristicNotification(mCharacteristic, true);BluetoothGattDescriptor descriptor &＃61; mCharacteristic.getDescriptor(UUID.fromString("00007777-0000-1000-8000-00805f9b34fb"));descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);gatt.writeDescriptor(descriptor);


3、public void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status)
只有这一步status &＃61;&＃61; BluetoothGatt.GATT_SUCCESS&＃xff0c;才可以真正的传输数据&＃xff0c;如果在第一步或者第二步就开始传输数据&＃xff0c;会在某些特定的case下导致未知的bug或者空指针错误

所以&＃xff0c;在中心设备跟外围开始连接后&＃xff0c;你可以设定一个超时时间&＃xff0c;在超时时间过后&＃xff0c;依然没能回调onDescriptorWrite并获得BluetoothGatt.GATT_SUCCESS&＃xff0c;则此次过程失败&＃xff0c;你可以根据实际情况进行重连或者提示错误

五、mtu-20字节问题

mtu20的来源&＃xff1a;GATT是基于ATT Protocol的&＃xff0c;而它的 core spec里面定义了ATT的默认MTU为23个bytes&＃xff0c;除去ATT的opcode一个字节以及ATT的handle2个字节之后&＃xff0c;剩下的20个字节便是留给GATT的了

如果要传输大于20字节的数据怎么办&＃xff1f;

1、 系统mtu可以支持修改到512字节&＃xff0c;完成大数据量的传输。但是由于涉及到中心和旁支都需要修改&＃xff0c;会造成很大的局限性和底层修改量&＃xff0c;而且会触发比如某些设备第一次修改不生效&＃xff0c;另一个设备一次连接中只能修改一次等bug&＃xff0c;非常不可取&＃xff0c;十分不建议。

2、分包传输&＃xff0c;自己设计协议分包传输是最可取的方案&＃xff0c;需要注意的是在分包后&＃xff0c;每一个包之间写入数据需要设置间隔&＃xff0c;比如100ms。

六、写数据之前做校验,判断获取的characteristic是否满足可读&＃xff0c;可广播&＃xff0c;或者需要回复等约定。

return ((characteristic.getProperties() & BluetoothGattCharacteristic.PROPERTY_WRITE) > 0 ||(characteristic.getProperties() & BluetoothGattCharacteristic.PROPERTY_WRITE_NO_RESPONSE) > 0);


七、丢数据包问题

在做好5和6的基础上&＃xff0c;依然会在一些设备上出现&＃xff0c;由于系统原因&＃xff0c;ble刚开始的发送第一个数据出现丢包&＃xff0c;请对此做出特殊处理。

八、解析数据

• 中心端mtu分包发给外围后&＃xff0c;外围可以在
  public void onCharacteristicWriteRequest(BluetoothDevice device, int requestId, BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded, int offset, byte[] value) 接收到数据并还原成原始数据

• 外围端mtu分包发给中心端后&＃xff0c;中心端可以在 public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) 接收到数据并还原成原始数据

• 注意&＃xff0c;对于一些蓝牙设备&＃xff0c;总有一些特殊的状态&＃xff0c;对于接受到的数据一定要进行正确性校验

九、other坑

• ble中的PROPERTY_WRITE_NO_RESPONSE不可信任&＃xff0c;google的有些版本并没有去读取这个属性值&＃xff0c;而是直接设置为需要résponse&＃xff0c;稳妥的方式最好设置为必须回复

• 在项目中如果有多个ble或 ble &＃43; 经典蓝牙连接&＃xff0c;在一些临界情况&＃xff08;比如设备重启&＃xff0c;crash闪退重启&＃xff09;&＃xff0c;a ble连接可能需要移除b ble&＃xff08;或 b经典蓝牙&＃xff09;连接产生的设备&＃xff0c;否则会导致a ble一直连接不上。

BluetoothDevice remoteDevice &＃61; mBluetoothAdapter.getRemoteDevice("另一个ble 或者 蓝牙设备mac值");if (remoteDevice.getBondState() &＃61;&＃61; BluetoothDevice.BOND_BONDED) {try {Method removeBond &＃61; remoteDevice.getClass().getDeclaredMethod("removeBond");removeBond.invoke(remoteDevice);RLog.d(TAG , "成功移除系统bug");} catch (Exception e) {RLog.e(TAG , "反射异常");}}

作者&＃xff1a;RDuwan
链接&＃xff1a;https://www.jianshu.com/p/2fd90849d8e0
来源&＃xff1a;简书
简书著作权归作者所有&＃xff0c;任何形式的转载都请联系作者获得授权并注明出处。