Android中BLE连接出现“BluetoothGatt status 133”的解决方法
http://www.loverobots.cn/android-ble-connection-solution-bluetoothgatt-status-133.html
前 言
最近的工作方向一直在低功耗蓝牙方面，也就是BLE（Bluetoooth Low Energy）。要说起蓝牙，之前能够想到的应用也就是蓝牙耳机、蓝牙手柄之类的。本以为蓝牙这个技术会慢慢没落下去，不过，现在随着智能设备的流行，出现了智能手环这样的可穿戴设备，而其实现通信的方式就是蓝牙。
起初，JACK的机器人怀着做整套APP的心态，觉得蓝牙模块无非是了解一下协议，模仿一下类似实现方式就可以了。直到折腾了一个月后才发现，BLE真TM是个大坑（额，爆粗口了，大家请见谅...），不仅涉及到应用层，还涉及到底层协议栈，需要设置从设备（Peripheral）的话还得会单片机、C语言的混合编程。而最坑的一点是，它还不稳定——不稳定还开发个毛线啊！！！所以，开发的重点之一也包括，解决稳定性问题......
这篇文章先重点记录一下遇到的这个“BluetoothGatt status 133”问题，后续会把相关经验慢慢整理出来分享给大家，也为自己将来再次遇到蓝牙开发时做个知识储备。
BluetoothGatt status 133
首先简单给大家解释下什么是BLE中的“BluetoothGatt status 133”。
在BLE通信中，或者说整个蓝牙通信中，都会经过以下基本步骤：
- 发现设备->配对/绑定设备->建立连接->数据通信
status 133这个错误状态就出现在BLE通信步骤中的“建立连接”过程中，而这个错误也是网络上进行BLE开发基本都会遇到的一个错误。但是，因为BLE开发还属于比较前沿的技术（公司大牛说的，感觉也还算吧），可供查阅参考的资料大部分还是来自国外的英文资料，国内可供参考的实在是少之又少。
如果有小伙伴在百度上搜索一下BLE相关问题，经常会看到有一些人在提问，然后下面一大片全都是统一回复——“我也遇到了这个问题，楼主解决了请分享一下......”。
而JACK的机器人遇到此问题的情况是，在与一台从设备建立连接后，退出测试DEMO，同时调用了各种释放资源的方法后，再次进入DEMO，与从设备建立连接会出现无法成功建立连接的问题，只要重复多次进入就又可以成功。
而根据stackoverflow上的相关提问：
可以发现解决此错误的重点是“在再次和从设备建立连接时，需要首先调用BluetoothGatt的close()释放掉之前的连接资源”，而原因是对于主设备来说，与从设备的连接数量是有限制的，比如其中提到的针对Galaxy s4手机的6个连接数量限制。
那么，重点还是回到连接资源的释放问题。下面看看JACK的机器人的解决方法，代码片段如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 |
|
注意看重写的BluetoothGattCallback中onConnectionStateChange()方法中的两个close()方法，此方法调用了mBluetoothGatt.close()用来释放当前的Gatt连接资源，同时在判断为status 133状态时，也就是“status != BluetoothGatt.GATT_SUCCESS”时，在close()方法后会再次调用connect(reConnectAddress)方法，尝试与从设备再次建立连接，直到连接上为止（这里可以做个尝试次数限制）。
其中的reConnectAddress为本次想要连接到的目标从设备蓝牙MAC地址。可以在外部的连接方法中调用setReConnectAddress(String address)方法进行设置。
好了，知道了问题的原因，解决方法其实也就不难了，那么这篇就到这里了。
关于蓝牙方面的内容，希望有相关经验的小伙伴能够在下方留言处多多交流，JACK的机器人在之后的时间也会分享更多相关的经验技巧，感谢大家的支持，谢谢。