安卓系统蓝牙服务com.android.bluetooth的使能

蓝牙系统服务层的使能流程分析

在这里插入图片描述

蓝牙服务层的使能基础是其初始化完成，也就是AdapterService通过onBind()将AdapterServiceBinder上报给bind该服务的调用者。我们现在应该都知道在安卓系统中bind该服务的为BluetoothManagerService。本篇我们就从蓝牙服务管理收到bind的回调开启蓝牙使能流程的分析。

熟悉安卓系统中bind服务机制的小伙伴应该都知道，该bind调用会连同回调函数ServiceConnection一起下发给系统，这样服务bind成功后通过该回调上报到对应的调用层，在蓝牙系统里就是蓝牙服务管理。通过如下转换蓝牙服务管理就获取到蓝牙服务层AdapterService的函数接口：

IBinder service = (IBinder) msg.obj；
mBluetooth = IBluetooth.Stub.asInterface(Binder.allowBlocking(service))；

随着蓝牙服务层接口的取得，就会接着执行蓝牙使能的操作
在这里插入图片描述

服务层使能的具体流程可以参照如下时序图：
在这里插入图片描述

从以上时序图大概能总结出蓝牙服务层使能基本上分为三个步骤：

使能低功耗蓝牙，也就是GattService
使能蓝牙协议栈
使能配置文件中支持的各项其他协议的服务

蓝牙状态涉及到如下状态值及含义：

public static final int STATE_OFF = 10，蓝牙关闭
public static final int STATE_TURNING_ON = 11，蓝牙正在打开
public static final int STATE_ON = 12，蓝牙打开
public static final int STATE_TURNING_OFF = 13，蓝牙正在关闭
public static final int STATE_BLE_TURNING_ON = 14，蓝牙BLE正在打开
public static final int STATE_BLE_ON = 15，蓝牙BLE打开
public static final int STATE_BLE_TURNING_OFF = 16，蓝牙BLE正在关闭

集合整个蓝牙打开基本上先打开低功耗蓝牙BLE，再打开传统蓝牙BT，所以蓝牙的状态变化为：
10 -> 14 -> 15 -> 11 ->12

反之，蓝牙关闭的状态变化为：
12 -> 13 -> 15 -> 16 -> 10

因此蓝牙整个的状态机就会根据不同场景和消息来及时切换到正确的状态机下执行相应的处理流程。

蓝牙服务层中定时器的设定有两个，分别对应低功耗BLE使能和传统蓝牙BT使能，超时时间都是4s，所以蓝牙底层在使能过程中耗费太长时间会同样会导致蓝牙打开失败（即使4s超时后底层蓝牙使能成功，也算失败）。
在这里插入图片描述

扫描二维码关注公众号，回复： 11720337 查看本文章

从时序图上可以看到BluetoothManagerService收到4次蓝牙状态的变化回调，但是一般应用在监听蓝牙状态变化的广播时，只能收到两次广播，分别为10 -> 11和11 -> 12 这2次蓝牙状态变化的广播。但这明明和时序图上的4次状态回调不一致啊？

其实是BluetoothManagerService自己做了处理，如果第三方应用是监听如下BLE状态改变的广播，则能完全一致的收到这4次广播。
在这里插入图片描述

但如果监听的是传统蓝牙状态改变的广播，则只能收到上述的10 -> 11和11 -> 12这2次广播。
在这里插入图片描述

BluetoothManagerService实例对象中对蓝牙状态广播的处理逻辑可以参考该方法bluetoothStateChangeHandler()，安卓系统里蓝牙状态改变的广播都是在这里广播出去的。

经过以上的分析，蓝牙服务层的使能我们已经有了一定的了解。流程是这么设计的，但有时还是会遇到些使能相关的莫名其妙的问题，根据过往的工作经验，我主要总结了如下几种问题：

蓝牙服务层使能BLE就超时失败，大概率当前系统有点卡，线程间消息传递太费时间，最终触发4s定时器。
使能蓝牙协议栈迟迟没有完成的回调上报。由于协议栈是蓝牙系统中最复杂的模块，在使能过程中还会依赖串口的打开与操作，从而使能芯片Controller模块，串口打开卡死也会导致蓝牙打开超时。
使能传统BT触发4s定时器，由于使能传统BT需要依次初始化协议配置文件中支持的各个协议，所以如果有哪个协议服务的ProfileService.doStart()慢一步，没有及时告知AdapterService协议服务已初始化完成，也可能导致蓝牙打开失败。

所以蓝牙开发过程中遇到类似问题，还需一步步分析流程，确定问题根因发生在哪个环节并给出解决方案。

上述的蓝牙服务使能时序图只是简单梳理了下大概流程，其中的知识点甚多，比如各个支持的蓝牙协议服务的初始化我就一笔带过了，感兴趣的小伙伴不妨自己动起手来，一览安卓源码的设计之美，也欢迎私信留言一起讨论。

更多互联互通技术，欢迎关注微信公众号：Connectivity
在这里插入图片描述

安卓系统蓝牙服务com.android.bluetooth的使能

蓝牙系统服务层的使能流程分析

猜你喜欢