Analysis of bluedroid enabling process of Android Bluetooth protocol stack
This article follows from the previous article "Analysis of the Enable Process of the Bluetooth System Service Layer in Android", and continues to analyze the enabling process related to the protocol stack layer, so the enabling of the Bluetooth protocol stack bluedroid starts from the call to the protocol stack interface in the JNI layer enableNative() enable() function.
Not much to say, but according to the old rules, we first have an overall impression of the protocol stack enabling, refer to the following sequence diagram.
Android's native Bluetooth protocol stack bluedroid is hierarchically divided into four layers: btif, bta, stack, and hci. Each layer has different functions, but the actual program runs in different threads. For the convenience of everyone There is a deeper understanding of the energy flow, so the above enable sequence diagram is based on threads. In the following, the instructions will be made according to the above sequence.
The Bluetooth service layer JNI enables the protocol stack bluedroid, and sends commands to the protocol stack entrance through the interface function interface.
stack_manager_get_interface()->start_up_stack_async(); sends the enable command to the protocol stack management module, and the module continues processing through the thread stack_manage.
Enable btif_config, btsnoop, hci and other modules in turn
btsnoop module:
Determine whether the snoop switch is turned on, so as to decide whether to create a snoop file to record the interaction information of hci.
The snoop switch position is in the developer options. If you turn on the switch, the persist.bluetooth.btsnoopenable global variable will be set to true; otherwise, the switch will be set to false.
The default storage location of snoop files: /data/misc/bluetooth/logs/
Because the steps to turn on the snoop switch are more complicated, the average user will not enter the developer options at all, and even where to open the developer options is a difficult problem, so you can modify the source code or reset persist.bluetooth.btsnoopenable during the Bluetooth development process. Value to achieve the purpose of creating a snoop file to record the interactive information of hci. Now provide the following two methods
- Modify the wrong value set when obtaining the value of persist.bluetooth.btsnoopenable in the source code.
This global variable is created when the snoop switch is turned on in the developer options for the first time, so the global variable is not defined if the snoop switch has never been operated. If you have operated the snoop switch in the developer options, the corresponding value can be obtained by obtaining the above-mentioned global variables, so that the error value no longer works. - Through the instruction:
adb shell setprop persist.bluetooth.btsnoopenable true, turn on the switch of Bluetooth hci-snoop.
The storage path of persist.bluetooth.btsnoopenable global variables is slightly different depending on the Android version:
Android 8 storage path : /data/property/persist.bluetooth.btsnoopenable/
Android 9 storage path : /data/property/persistent_properties/
HCI module:
Create hci_thread thread to handle hci-related processes and initialize the Bluetooth chip at the same time.
Obtain the external interfaces provided by the chip Controller module through HIDL technology:
btHci = IBluetoothHci::getService();
android::sp<IBluetoothHciCallbacks> callbacks = new BluetoothHciCallbacks();
btHci->initialize(callbacks);
HIDL : The full name is HAL interface definition language (hardware abstraction layer interface definition language). Before that, Android had AIDL, which was based on Android binder and used to define the interface between Android's Client and Service based on Binder communication. HIDL has a similar effect, except that it defines the interface between Android Framework and Android HAL implementation.
The implementation of Android HAL is different due to different chip manufacturers, and the implementation content is similar to the implementation in hardware\interfaces\bluetooth\1.0\ in the Android source code. Manufacturers then interact with their own chips in the implementation of HAL. In this way, software and hardware can be separated through a unified HAL interface, and the Android system can integrate Bluetooth chips from different manufacturers.
After the chip module is initialized, it will notify the android layer through a callback, so that the Bluetooth protocol stack will continue the subsequent enabling process.
After the HCI module is enabled, enter the BTU_StartUp() function to initialize the BTU control module, including key modules of the protocol stack such as BTU, BTM, L2CAP, and SDP
Enabling the controller module is actually to obtain the supported function parameters from the chip layer through a set of HCI commands
typedef struct {
BT_HDR* (*make_reset)(void);
BT_HDR* (*make_read_buffer_size)(void);
BT_HDR* (*make_host_buffer_size)(uint16_t acl_size, uint8_t sco_size, uint16_t acl_count, uint16_t sco_count);
BT_HDR* (*make_read_local_version_info)(void);
BT_HDR* (*make_read_bd_addr)(void);
BT_HDR* (*make_read_local_supported_commands)(void);
BT_HDR* (*make_read_local_extended_features)(uint8_t page_number);
BT_HDR* (*make_write_simple_pairing_mode)(uint8_t mode);
BT_HDR* (*make_write_secure_connections_host_support)(uint8_t mode);
BT_HDR* (*make_set_event_mask)(const bt_event_mask_t* event_mask);
BT_HDR* (*make_ble_write_host_support)(uint8_t supported_host, uint8_t simultaneous_host);
BT_HDR* (*make_ble_read_white_list_size)(void);
BT_HDR* (*make_ble_read_buffer_size)(void);
BT_HDR* (*make_ble_read_supported_states)(void);
BT_HDR* (*make_ble_read_local_supported_features)(void);
BT_HDR* (*make_ble_read_resolving_list_size)(void);
BT_HDR* (*make_ble_read_suggested_default_data_length)(void);
BT_HDR* (*make_ble_read_maximum_data_length)(void);
BT_HDR* (*make_ble_read_maximum_advertising_data_length)(void);
BT_HDR* (*make_ble_read_number_of_supported_advertising_sets)(void);
BT_HDR* (*make_ble_set_event_mask)(const bt_event_mask_t* event_mask);
BT_HDR* (*make_read_local_supported_codecs)(void);
}
The interaction of the HCI layer is as follows:
After the reset is completed, the protocol stack will actively issue an HCI command to read the Bluetooth name of the local end, and send the new name to the chip, and at the same time report the Bluetooth name and address of the local end to the service layer through the callback of the JNI layer. If there is a paired Bluetooth device, the device information will also be reported.
Then the socket module of the protocol stack will be initialized. This part is mainly for the establishment of OBEX connection and data interaction.
All enablement of the protocol stack is completed, and the message of successful Bluetooth enablement is reported to the JNI layer through the HAL bt_hal_cbacks->adapter_state_changed_cb callback. So far, the analysis of the entire process of the bluedroid enablement process of the Bluetooth protocol stack is complete.
This is the end of the analysis of protocol stack enablement. Interested friends are welcome to leave a message and discuss together.
For more interconnection technologies, please pay attention to the WeChat public account: Connectivity
