Android 8.1 bluetooth system architecture

• Official website:

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

• Learning Website Collection:

1. Source tracking of the Bluetooth enable process of Android Notes:

    https://www.jianshu.com/p/3344f8d6d079 introduces the bt system framework and the source code involved in the enablue process.

2.

• Introduction of key technologies

     1) JNI: Java native language For Bluetooth APK, including: JNI (libbluetooth_jni.so) and com.android.bluetooth. libbluetooth_jni.so will call libhardware.so which provides

   2) HAL:  Hardware Abstraction Layer             

            When declaring the structure bluetooth_module_t, its name is uniformly defined as HMI   , and the purpose of this is to find the "HMI" symbol in the so library generated by the Bluetooth HAL Stub source code through dlsym, define HAL_MODULE_INFO_SYM HMI

1.     /*Module instance variables*/  
2. struct  xxx_module_t HAL_MODULE_INFO_SYM = {     //The variable name must be HAL_MODULE_INFO_SYM, this is mandatory, if you want to write Android HAL, you have to follow the rules of the game,  
3.                                                //See the type information description of hw_module_t in hardware.h.   It is a macro definition: #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,     //Defined in the header file  
9.         name: MODULE_NAME,  
10.         author: MODULE_AUTHOR,  
11.         methods: &xxx_module_methods,   //List of module methods, defined locally  
12.     }  
13. };                                                                                                                        

          Technical reference:

          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

         The framework of Hal Stub is relatively simple, with three structures, two constants, and one function, referred to as the 321 architecture:

        typedefstruct hw_module_t {struct hw_module_methods_t* methods;} hw_module_t； 

        typedefstruct hw_device_t {struct hw_module_t* module；}hw_device_t； 

    typedefstruct hw_module_methods_t { 

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

        "1" introduces HAL because Android is open source, manufacturer closed source, and GPL, so that upper-layer applications do not have to care about the underlying implementation.

       《2》Comparison of Android  's old architecture module and  new architecture module stub 

       The upper-layer application layer or framework layer code loads the so library code. We call the so library code a module. The stub of each hardware object is registered in the Hal layer. When the upper layer needs to access the hardware, it will be from the currently registered hardware object stub After finding it, the stub will provide the operations interface (operation interface) of the hardware object to the upper-level module, and the operation interface is stored in the module. The upper-level application or framework layer then accesses the hardware through the module operation interface.

       "HMI" introduces:

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