近距离通信:收发数据,指令控制
蓝牙设备通常是穿戴式,便携式,室内或车内等,正是因为蓝牙适用于近距离通信的特点。如果要做远距离通信,则可借助于Wifi,用手机或网关做中转。
广播消息、通知
蓝牙可以以一定的周期发送广播,手机端接收到广播后,解析广播包,可做设备识别、配对,事件通知以及指令控制等。
低精度定位
根据设备的信号强度,可以估算出大概方位和距离。
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可以分享给他人。
Android中蓝牙BLE设备连接有不少坑要注意的,不然很多时候会出一些莫名其妙的问题。我大概总结了一下,大概有十来条。如果大家觉得自己一条条去解决太麻烦,可以参考这个开源框架:
https://github.com/dingjikerbo/BluetoothKit
一、对蓝牙设备的操作不能并行,只能串行,并且每次都要在收到上一个操作的回调后才能继续下一个操作。有时候蓝牙协议栈出现异常可能收不到回调,所以我们要对每个操作做超时检查,否则后面的所有操作都被阻塞了。对于这些超时的任务或者失败的任务,通常是连接出了问题,我的做法是直接给gatt关掉,下次重新连接的时候重开一个gatt。除超时处理之外,对每个任务最好支持失败重试机制,尤其是连接。
要注意,断开连接是不用放到队列中等待的,而是直接closeGatt,并给当前正在进行的任务直接退出回调Cancel。
二、同一个设备的所有操作最好都放在同一个线程串行执行,最好不要放在UI线程,虽然这些操作都是异步的,理论上来说不会耗时,但是由于涉及到跨进程,有可能出现ANR。另外不建议每个设备都开一个线程,设备多了会费内存也会降低性能。较好的做法是开一个线程,所有设备的操作都在该线程中发起,虽然占用同一个线程,但是每个设备各自维护自己的任务队列。
三、设备的gatt在不用时要及时关闭,不然会造成连接泄露,而系统支持的连接设备数是有限的,当达到上限后有可能其它设备连不了。
四、当设备断开连接时,最好closeGatt,而不是diconnect。不要下次复用之前的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,并马上刷新一下该设备的缓存。当然,重启蓝牙也会刷新缓存,不过会影响到所有设备。另外有时候discoverService服务发现的不全,或者根本发现不了服务,也可以考虑清除一下缓存。
关于蓝牙缓存的清除可以参考 http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android
九、尽量维护设备的连接,因为连接是有成本的,慢的时候可能要等几秒钟,对于操作频次较高的设备用户是无法忍受的。这种情况可以考虑在退出设备操作页面时,继续为该设备保持连接一段时间再断开,如果这段时间内用户又重新点进设备操作页就能很快。
十、固件升级通常是写设备,为加快写速度,可以在write character时指定no response标志,实践发现速度可以提升2~3倍。不过要注意的是即便带了no response标志,也不代表这种写操作是没有回调的,我们仍然要遵循收到上一次写回调后才能进行下一次写操作。
十一、打开/关闭character的notify,如下:
private boolean setCharacteristicNotification(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, boolean flag) {
boolean result = gatt.setCharacteristicNotification(characteristic, flag);
if (result) {
BluetoothGattDescriptor descriptor = characteristic
.getDescriptor(UUID.fromString(BluetoothConstants.CLIENT_CHARACTERISTIC_CONFIG));
if (descriptor != null) {
descriptor.setValue(flag ? BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE
: BluetoothGattDescriptor.DISABLE_NOTIFICATION_VALUE);
}
result = mBluetoothGatt.writeDescriptor(descriptor);
}
return result;
}
这里有两步操作,别漏掉设置descriptor,并且要注意必须等收到onDescriptorWrite回调之后再继续执行下一个任务。
最后可以参考这个链接,关于BLE各种不稳定的问题和兼容的办法的讨论:
http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable
(五)蓝牙安全
蓝牙最主要的两个安全问题就是:加密和防重放。加密的包括token,控制指令,数据等。 token相当于控制设备的钥匙,每当要操作设备时,都需要核实token,token在手机和设备之间传递时是通过秘钥加密过的,所以就算别人截获了,如果不知道秘钥和加密算法也无法破解。另一个是防重放,总体来说,都是数据中带有一个序号,这个序号有一个有效窗口,在这个有效窗口内的请求被认为是有效的,否则认为是无效的。序号通常有三种:
时间戳 ,下次请求的时间戳必须和上次请求有一个时间差,比如大于5s,否则认为是重放。这个窗口不能设置的太小了,太小了防重放就没有作用,太大了会导致正常的网络请求被屏蔽。
递增序列,每次操作都递增序列号,如果收到的序列号没有递增,则丢弃。比如手机遥控电视,手机每发出一次指令,序列号就加一,电视会保存这个序列号,但是遥控器不能每次发指令都保存序列号,因为要省电,并且flash的写次数是有限制的,所以要隔一个周期写入,比如满100写入一次。如果中途设备断电导致序列号丢失了,则下次上电时需要加上一个周期。
随机数,每次都生成一个随机数,服务端会将最近一段时间收到的序列号保存下来,如果发现收到的序列号已经存在了就认为是重放,因为是随机数,所以碰撞的概率极小。