Android 8.1 bluetooth system architecture

• 官方网站：

https://source.android.com/devices/bluetooth/

• 学习网站收集：

1.Android笔记之蓝牙enble过程源码追踪：

    https://www.jianshu.com/p/3344f8d6d079                                                                                                                          介绍bt 系统框架，enablue 过程所涉及的源码.

2.

• 关键技术介绍

     1）JNI：Java native language                                                                                                                                                     对于蓝牙APK，包括 ： JNI（libbluetooth_jni.so） 和com.android.bluetooth。                                                                    libbluetooth_jni.so又会调用 libhardware.so  其所提供的

   2) HAL:  Hardware Abstraction Layer             

            在声明结构体bluetooth_module_t时，其名字统一定义为了HMI  ，而这么做的目的就是为了通过dlsym来查找Bluetooth HAL Stub源码生成的so库                               里的”HMI”符号，define HAL_MODULE_INFO_SYM         HMI

1.     /*模块实例变量*/  
2. struct xxx_module_t HAL_MODULE_INFO_SYM = {    //变量名必须为HAL_MODULE_INFO_SYM,这是强制要求的，你要写Android的HAL就得遵循这个游戏规则,  
3.                                                //见hardware.h中的hw_module_t的类型信息说明.  它是一个宏定义：#define HAL_MODULE_INFO_SYM         HMI
4.         common: {  
5.         tag: HARDWARE_MODULE_TAG,  
6.         version_major: 1,  
7.         version_minor: 0,  
8.         id: XXX_HARDWARE_MODULE_ID,    //头文件中有定义  
9.         name: MODULE_NAME,  
10.         author: MODULE_AUTHOR,  
11.         methods: &xxx_module_methods,  //模块方法列表，在本地定义  
12.     }  
13. };                                                                                                                        

          技术参考：

          https://blog.csdn.net/loongembedded/article/details/44993525  

         https://blog.csdn.net/myarrow/article/details/7175204

        https://www.cnblogs.com/langlang/archive/2012/04/17/2454217.html

         Hal Stub的框架比较简单，三个结构体、两个常量、一个函数，简称321架构：

        typedef struct hw_module_t {struct hw_module_methods_t* methods;} hw_module_t；

        typedef struct hw_device_t {struct hw_module_t* module；}hw_device_t；

    typedef struct hw_module_methods_t {

        int (*open)(const struct hw_module_t* module, const char* id，struct hw_device_t** device);
    }hw_module_methods_t；

        《1》 介绍了 HAL因为Android开源            与厂商闭源以及GPL的 原因 ，让 上层应用 不必关心底层的实现 。

       《2》Android 旧的架构module 与 新的架构module stub 比较 

       上层应用层或者框架层代码加载so库代码，so库代码我们称之为module，在Hal层注册了每个硬件对象的存根stub，当上层需要访问硬件的时候，就从当前                        注册的硬件对象stub里查找，找到之后stub会向上层module提供该硬件对象的operations interface（操作接口），该操作接口就保存在module中，上层应用                  或框架层再通过这个module操作接口来访问硬件

       "HMI"引入 ：

          在Module架构中，本地代码由so库实现，上层直接将so库映射到进程空间，会有代码重入及设备多次打开的问题。新的Stub框架虽然也要加载module库，                     但是这个module已经不包含操作底层硬件驱动的功能了，它里面保存的只是底层stub提供的操作接口，底层stub扮演了“接口提供者”的角色，                                        当stub第一次被使用时加载到内存，后续再使用时仅返回硬件对象操作接口，不会存在设备多次打开的问题，并且由于多进程访问时返回的只是函数指针，                        代码并没有重入