智能家居Android技术系列之——蓝牙那些事

一、蓝牙能做些什么

1. 近距离通信：收发数据，指令控制

   蓝牙设备通常是穿戴式，便携式，室内或车内等，正是因为蓝牙适用于近距离通信的特点。如果要做远距离通信，则可借助于Wifi，用手机或网关做中转。

2. 广播消息、通知

   蓝牙可以以一定的周期发送广播，手机端接收到广播后，解析广播包，可做设备识别、配对，事件通知以及指令控制等。

3. 低精度定位

   根据设备的信号强度，可以估算出大概方位和距离。

二、Android平台的蓝牙

Android 4.3才开始支持低功耗蓝牙，提供的API很简陋，只有扫描和连接。

（一） 蓝牙扫描

 蓝牙扫描分为经典蓝牙扫描和低功耗蓝牙扫描，官方文档里提到这两种蓝牙不能同时扫描，如下
 [https://developer.android.com/intl/es/guide/topics/connectivity/bluetooth-le.html](https://developer.android.com/intl/es/guide/topics/connectivity/bluetooth-le.html)

然而实验发现 BluetoothAdapter.startDiscovery是可以同时发现经典蓝牙和ble的

在stackoverflow上查看解释：

http://stackoverflow.com/questions/25065810/android-bluetooth-scan-for-classic-and-btle-devices

http://stackoverflow.com/questions/27169468/android-bluetooth-device-scan-discovery-for-classic-and-low-energy-devices-seque

这个帖子说某些手机上startDiscovery不能扫ble
http://stackoverflow.com/questions/21809946/bluetoothadapter-startscan-vs-bluetoothadapter-startlescan/22524528#22524528

总结一下：

BluetoothAdapter.startDiscovery在大多数手机上是可以同时发现经典蓝牙和Ble的，但是startDiscovery的回调无法返回Ble的广播，所以无法通过广播识别设备，且startDiscovery扫描Ble的效率比StartLeScan低很多。所以在实际应用中，还是StartDiscovery和StartLeScan分开扫，前者扫传统蓝牙，后者扫低功耗蓝牙。考虑到BLE设备较多，所以先扫BLE 10s，再扫传统蓝牙10s。

另外需要提一下的是：
在 startLeScan() 的时候，在onLeScan() 中不能做太多事情，特别是周围的BLE设备多的时候，非常容易导致出现如下错误：
E/GKI LINUX(17741): ##### ERROR : GKI exception: GKI exception(): Task State Table E/GKI LINUX(17741): #####
E/GKI LINUX(17741): ##### ERROR : GKI exception: TASK ID [0] task name [BTU] state [1]
E/GKI
LINUX(17741): #####
LINUX(17741): ##### ERROR : GKI
exception: TASK ID [1] task name [BTIF] state [1]
LINUX(17741): #####
E/GKI LINUX(17741): ##### ERROR : GKI exception: TASK ID [2] task name [A2DP-MEDIA] state [1]
E/GKI
LINUX(17741): #####
LINUX(17741): ##### ERROR : GKI exception: GKI exception 65524 getbuf: out of buffers#####
E/GKI LINUX(17741): ##### ERROR : GKI exception:
E/GKI_LINUX(17741): * * * * * * * * * * * * * * * * * * * * * *
开发建议：在 onLeScan() 回调中只做尽量少的工作，可以把扫描到的设备，扔到另外一个线程中去处理，让 onLeScan() 尽快返回。 参考帖子

（二）设备识别

蓝牙设备识别方式多种多样，有通过mac地址特征识别的，有通过设备名称识别的，有通过广播识别的。通过mac地址识别最简单，不过不太靠谱，同一个厂家不同批次生产的产品可能mac特征都不一样，所以客户端需要不停地兼容。通过设备名称识别的也不靠谱，首先重复率太高，其次获取设备名称涉及到跨进程通信，如果在UI线程可能导致ANR，所以得放在子线程，增加了复杂度。最好的办法是通过广播，广播中可以约定一套协议，并将设备类型ID放入广播，当收到符合该协议的广播时，读取出设备类型ID，到后台一查，就能获取到该类型设备的所有参数，这样灵活性最高。不过有的设备识别比较坑，需要先建立连接，并查看是否存在某个Service，对于这种稍复杂的设备，可以建立mac地址到设备类型的缓存，就免去了每次都要连接的麻烦。

（三）设备配对
这里说的配对指的是BLE设备的配对。配对的作用在于和设备做相互确认，一方面是确定要操作的设备，另一方面是考虑到安全因素。假如家里买了两盏灯，蓝牙扫描时都扫出来了，但是怎么区分这两盏灯呢？比较好的办法是按一下某台灯的电源键，然后灯会发广播，手机就会收到了。如果隔壁有人也搜到这盏灯了，由于他无法配对，所以就无法操控这盏灯了。

配对的过程和扫描过程类似，都是打开蓝牙扫描，然而稍有区别，配对时只扫Ble，且扫描的策略不同，原因是实践中发现某些蓝牙芯片在一次扫描中只回一次response，假如这次手机没有收到，那就算扫一天也收不到。针对这种情况，解决的办法是多扫几次，每次时间可以短一点，这样扫到的概率就会大大提高。可参考如下帖子
http://stackoverflow.com/questions/19502853/android-4-3-ble-filtering-behaviour-of-startlescan
http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable

我们不用每次操作设备的时候都要配对，那样过于繁琐了。配对只在第一次使用设备时进行，或设备正在被他人占用，你要抢过来用时才需要配对。如果曾经使用过设备是不需要配对的，下次直接连接即可。

（四）设备连接
要操作设备通常要与设备建立连接，从设备读或向设备写数据，数据包括控制指令和一些参数等。连接建立成功后，还要进行授权，即从设备读出Service Token，和手机本地的Service Token对比，只有两个吻合才能操作设备，否则表示设备正被他人占用或本地Service Token已过期，需要重新配对以确认身份的合法性。如果是刚配对过，则手机端会生成Token并写入设备，以后操作设备都用这个token即可，并且该token可以分享给他人。

关于蓝牙设备连接，还有这么几个问题要注意：

一、同一个设备的所有操作最好都放在同一个线程串行执行，比较好的做法是用HandlerThread，所有的操作都post到Looper中，按队列顺序一个个执行，前一个操作结束收到回调了再进行下一个操作，当然也可以放到UI线程。不过要注意的是每个任务都要设置一个超时，有的任务可能永远也收不到回调，这样会阻塞队列中的其它任务。对于这些超时的任务或者失败的任务，通常是连接出了问题，我的做法是直接给gatt关掉，重开一个gatt。最好给每个设备都新建一个连接管理器，这样可以统一管理所有设备的gatt，当不用时可以释放，不然会造成连接泄露，而系统可用的client是有限的。

二、当设备断开连接时，最好closeGatt，不要下次复用之前的gatt来reconnect，因为有的手机上重连可能会存在问题，比如重连后死活发现不了service。这种情况下，最好只要断开连接就close gatt，下次连接时打开全新的gatt，这样就可以发现service了。

三、service不要缓存，虽然uuid什么的都没变，但是这些service都会和gatt关联的，如果gatt变了，那service就报废了，对这些service和character做任何读写操作都会出错。所以建议每次连接上时都去discover service，不要缓存。

四、有的手机discover service很慢，原因是connect interval太大了，有的手机会主动向设备发起更改connect interval，而有的手机却不会。这样的话connect interval相差就会很大，实践中发现有的手机是7ms，有的手机是默认的50ms，所以发现service都要8s，甚至20s的都很寻常，这对用户来说是无法忍受的。所以比较好的办法是设备主动发起更改connect interval，这个可以参考google搜索 ble spec update connection parameter，
https://devzone.nordicsemi.com/question/12545/update-connection-parameter-programmatically/

五、前面提到蓝牙的所有操作都要放到同一个线程里执行，但是回调通常都会在binder线程里执行，因为这是跨进程回调回来的。一定要注意到这一点，否则会出现一些奇怪的问题。比如writeCharacter在线程A中，但是onCharacterWrite是在binder线程中，回调里如果涉及到任务调度的逻辑一定要post回线程A中，不然任务调度会出问题。

六、当设备固件升级后，character可能发生了变化，而系统是不知道的，下次discover service的时候还是返回的旧的缓存，这样读写character可能会失败。解决办法是固件升级后，重开一个gatt，并马上刷新一下该设备的缓存。当然，重启蓝牙也会刷新缓存，不过会影响到所有设备。
关于蓝牙缓存的清除可以参考 http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android

最后可以参考这个链接，关于BLE各种不稳定的问题和兼容的办法的讨论：
http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable

（五）蓝牙安全
蓝牙最主要的两个安全问题就是：加密和防重放。加密的包括token，控制指令，数据等。 token相当于控制设备的钥匙，每当要操作设备时，都需要核实token，token在手机和设备之间传递时是通过秘钥加密过的，所以就算别人截获了，如果不知道秘钥和加密算法也无法破解。另一个是防重放，总体来说，都是数据中带有一个序号，这个序号有一个有效窗口，在这个有效窗口内的请求被认为是有效的，否则认为是无效的。序号通常有三种：

1. 时间戳 ，下次请求的时间戳必须和上次请求有一个时间差，比如大于5s，否则认为是重放。这个窗口不能设置的太小了，太小了防重放就没有作用，太大了会导致正常的网络请求被屏蔽。

2. 递增序列，每次操作都递增序列号，如果收到的序列号没有递增，则丢弃。比如手机遥控电视，手机每发出一次指令，序列号就加一，电视会保存这个序列号，但是遥控器不能每次发指令都保存序列号，因为要省电，并且flash的写次数是有限制的，所以要隔一个周期写入，比如满100写入一次。如果中途设备断电导致序列号丢失了，则下次上电时需要加上一个周期。

3. 随机数，每次都生成一个随机数，服务端会将最近一段时间收到的序列号保存下来，如果发现收到的序列号已经存在了就认为是重放，因为是随机数，所以碰撞的概率极小。