Android Bluetooth Framework源码剖析（一）初见轮廓

框架

蓝牙如今许多人生活中不可或缺的一项技术，耳机、音箱、遥控器、手表、手环、电灯泡、手机、电脑、电视机，而Android也很常见，小到三岁孩童，老至八十老人都可能使用着它， 本系列文章将从源码角度详细剖析Android蓝牙框架，从现象看本质，看看点击一下蓝牙开关、点击一下连接就可以听到音乐背后的神秘面纱，看看app开发时调用enable、connect都是如何实现的。
本系列文章主要以Android14的源码为蓝本，Android13及以上版本将蓝牙相关的内容集中到packages/modules/Bluetooth目录下，而Android12及以下版本分散在各个目录，但总体的框架没有太大差异，代码获取方式：git clone https://android.googlesource.com/platform/packages/modules/Bluetooth -b android14-s2-release，也可以从国内的一些源获取。整体框架如下图：

整体分三层，分别是apps、framework、native，向下还有bt driver等不再本系列问题讨论范围内，这里就不具体展示出来了，除了这三层还有一些中间件，如JNI、Binder。

• apps
  这一层是整个框架的最上层，都是用户可以直接可以看到的APP，例如设置中的蓝牙页面、开发的蓝牙应用等等，这些app通过bluetooth api与framework通信，操作底层的蓝牙协议栈或者获取信息等等。
• api / binder
  api（android.bluetooth, 在framework/java/android/bluetooth路径下）实际上是运行在apps层的，app和蓝牙服务是跨进程的，不能直接使用协议栈的能力，因此通过binder机制实现apps和蓝牙服务跨进程通信，通信的接口采用AIDL（Android Interface Definition Language）描述，api在framework/java/android/bluetooth路径下实现，binder的接口定义在system/binder/android/bluetooth路径下。
• framework
  这一层中包含了蓝牙管理服务、蓝牙Adatper服务、Profile服务，蓝牙管理服务是一个系统服务，负责蓝牙总体的管理，Adapter服务实现对本机蓝牙的控制和管理，Profile服务主要是实现两个蓝牙设备通信时的控制和管理，因此系统管理服务需要依赖Adapter服务和Profile服务，同样的系统管理服务和其他服务通信时也是跨进程，需要使用binder机制，这些服务都是通过Jave实现，在android/app/src/com/android/bluetooth路径下。
• JNI
  framework层中的服务不包括蓝牙协议栈，且都是使用jave实现，因此和协议栈通信时需要使用JNI机制实现java和c++的相互转换，在android/app/jni路径下。
• native
  蓝牙协议栈的底层实现，实现蓝牙通信协议和本地蓝牙设备的控制管理，它采用C++编写，在system路径下。协议栈不会运行在一个单独的进程，它会生成一个动态链接库，运行在蓝牙服务的APP中，关于蓝牙协议栈的详解可参考另外一个专栏 android蓝牙协议栈 fluoride

调用流程

下图是以打开蓝牙和连接蓝牙两个动作为例，展示了各层以及各个模块间的调用流程。这里简单预览一下其调用流程，在后续的文章中将详细的讲述，可以看到打开蓝牙和连接设备最大的区别是打开蓝牙会先通过BluetoothManagerService再到AdapterService，而连接蓝牙直接调用ProfileService的提供的能力；