蓝牙 sig base uuid_蓝牙，从系统开机说起

完了，本号已经好久不更新了，怎么也木有人念叨，是被抛弃了吗..要哭了..童鞋，你还记得大明湖畔的程序媛儿饭饭么～

经常会有一些同行问我，怎么学习蓝牙？既然你这么认真的发问了，那我也认真的回答一下：我真的不知道…

只能给你分享一张美图了～

说实话我也是不知道如何回答一方面是我也是自学来的，学习的也不系统，

也一直在摸着石头过河，踩过的坑不见得少。

我也没办法说出多么博大精深的东西来

另一方面蓝牙涉及到的东西太多了，从最上层界面实现，功能实现，功能调用，协议规范等等。

我还真不知道你究竟要学习什么？

是让你看协议好，还是建议你研究下蓝牙都有哪些功能，又或者是该让你研究蓝牙的哪一段源码…

And，本公众号里的原创文章，一部分是根据源码自己总结出来的，一部分也有参考蓝牙技术联盟官网(SIG)对于蓝牙的一些理论介绍。

所以啊划重点，一定要抱着怀疑的心态来看如果能留言帮我指出一些错误，那就万分感谢了

我是一颗脂肪层比较厚的程序媛，墨丹心～

凡事都是需要一些恒心和毅力的，如果真心想学的话，那就从最基础的学起心急真真真的吃不了热豆腐啊童鞋

从最基本的用户角度来看看，蓝牙是什么东西，有哪些功能：

跟我一起学蓝牙基础篇(一)---何为蓝牙​mp.weixin.qq.com

跟我一起学蓝牙基础篇（二）---蓝牙组成​mp.weixin.qq.com

跟我一起学蓝牙基础篇（四）---Profile​mp.weixin.qq.com

戳"

跟我一起学蓝牙基础篇（五）---Profile​mp.weixin.qq.com

"查看更多代码本质上就是为功能服务的，

只要了解了蓝牙的基本功能，那你看代码也算是心里有个数儿了接下里来想一个稍微简单的问题，

蓝牙是如何启动的？操作上很简单，从设置或者状态栏开关随便怎么着，进入蓝牙界面，可以开启/关闭蓝牙

从操作上看，感觉像是设置在管理着蓝牙的一系列操作。难道settings应用掌握的Bluetooth的生杀大权？？别傻夫夫的啦

我Bluetooth怎可能是任人宰割的呢？设置只是一个入口而已

蓝牙有自己单独的应用，所有针对蓝牙的操作都必须经过Bluetooth这个开关干了什么？

开启了蓝牙进程中的一系列服务.在Android系统中，蓝牙有自己的应用，有自己的进程

在设置中开启蓝牙时调用流程其实是，setting应用通过系统API调用的方式，调用开启蓝牙的方法，系统API通过Binder的方式调用Bluetooth的方法，Bluetooth再通过JNI、binder来触发协议栈开启蓝牙

这才仅仅是贴出了上层代码的调用逻辑…

所以，在蓝牙开启之前，要把框架层也就是framework层的API以及相关服务准备好

等到需要开启蓝牙时再去enable开启Bluetooth相关的服务

系统的核心服务其实是在系统开机时就准备好了的

怎么准备的呢？要从SystemServer开始说起蓝牙相关的服务有很多，但是在未开启蓝牙时启动的服务只有一个，那就是BluetoothManagerService

但，我BluetoothManagerServie也是很傲娇的，不能随意加载，

条件太恶劣的话我就不参与了。啥叫条件太恶劣？总不能你设备不支持蓝牙我也给你加载？显然不可能那模拟器呢？也不给你加载如果是在low_level的工厂测试模式呢？我也不加载啊

ok，排除掉这些极端情况，可以保证我Bluetooth能够生存并且能够起作用服务加载的过程其实和其他系统级服务一个套路

mSystemServiceManager.startService(
 BluetoothService.class);

startService方法干什么呢？

代码也很简单

....
 service = constructor.newInstance(mContext);
....
mServices.add(service);
.....
service.onStart();

初始化蓝牙系统服务

1. 创建service的实例对象
2. service存入数据结构中进行统一管理
3. 触发onStart方法

进入BluetoothService查看，构造方法中构造了BluetoothManagerService对象onStart方法没做任何特殊处理，所以暂时不用考虑所以，

startService的目的就是创建BluetoothManagerService的对象，并且将service存入到数据结构中进行统一管理

虽然在systemserver中看到绑定的是BluetoothService,但其实具体干事儿的还是BluetoothManagerService。

BluetoothService有点儿类似一个BluetoothManagerService的一个管理类紧接着，触发onBootPhase方法在系统服务ready之后，就publishBinderService把BluetoothManagerService发布注册到系统的ServiceManager中，供应用程序进行binder调用

等到AMS等ready之后，就会执行handleOnBootPhase进行蓝牙相关的一些操作

所以，在系统重启之后，对于系统进程中的蓝牙服务的操作有三件事儿

1. 初始化BluetoothManagerService实例
2. 将service注册到ServiceManager中，供其他进程获取
3. 在系统完全ready并且核心服务也已经完全ready的情况下，管理是否需要去开启蓝牙

好了，三条路已经设计好了，接下来就应该铺路了，那就继续来看看铺路时都需要干啥呗

第一条路，初始化service的实例那就奔着BluetoothManagerService的构造方法里去看就行了蹭蹭蹭光一个构造方法代码就将近100行，代码也不贴了，贴个源码链接，感兴趣的看下http://androidxref.com/9.0.0_r3/xref/frameworks/base/services/core/java/com/android/server/BluetoothManagerService.java#loadStoredNameAndAddress

代码不贴，但大致的功能还是要给他提溜出来的

第一，给参数赋值

第二，注册ContentObserver,监听ble扫描模式的改变

第三，注册广播，监听蓝牙name和address的改变，以及蓝牙信息的重置

第四，加载name和address到数据库

第五，监听飞行模式的状态改变

ok了，接下来第二条路，发布自己的server给系统SM,供其他人使用

这个就要去SystemService中去看

这个就不扯了，哈哈，越说越多了又

第二条路就交给系统去修复去吧

我们的任务是接着修第三条路：处理系统各种服务ready之后对蓝牙的处理：handleOnBootPhase

这个方法干啥呢？

帮你开蓝牙呀，要不然你关机之前蓝牙是开的，重新开机之后蓝牙关了，岂不是让人生气？

我让你关了吗？你就给我关了？怎么这么自觉？哈哈

所以，这个第三步是干啥的呢？帮你把蓝牙恢复到关机之前的状态。

恩～还算有点儿自知之明的哈，能够记住我的选择

如果关机之前蓝牙是开启的，那么就要去开启蓝牙

ok到此为止，算是把蓝牙的系统服务给你准备好了。如果用户进入到设置，去开启蓝牙会怎么样呢？根据调用流程图，过程如下

1. 在setting中调用系统API方法，BluetoothAdapter的enable()方法
2. 紧接着跨进程调用BluetoothManagerService的enable(String packageName)

同样，enable方法中也是和系统开机时自动开启蓝牙的代码相似

但是有一点儿不一样，那就是开启蓝牙的原因不一样，如果是刚开机开启蓝牙，那么原因就是：

ENABLE_DISABLE_REASON_SYSTEM_BOOT

如果是调用enable方法开启蓝牙，那么原因就是：

ENABLE_DISABLE_REASON_APPLICATION_REQUEST

还有其他原因，比如关闭飞行模式时恢复蓝牙状态时会重新开启蓝牙。后续再介绍总之所有开启蓝牙的操作的入口就是sendEnableMsg

private void sendEnableMsg(boolean quietMode, int reason, String packageName) {
...
}

而这个方法接下来就会开启Bluetooth应用的一些服务了呀

也就是说在开机之后，会把活在系统进程的核心服务BluetoothManagerService给注册上，

但此时蓝牙的其他服务还没在当开启蓝牙时，就会从Bluetooth和ManagerServie中开启蓝牙的一个最最基础的服务AdapterService

,接下来就是接二连三的蓝牙的各种核心服务了

但关闭蓝牙时，这个服务就会被解绑，所以这些服务是和蓝牙的开启和关闭同步的所以，接下来的任务，就是研究BluetoothManagerService是如何enable这些蓝牙服务的了