The realization principle of the Bluetooth automatic reconnection mechanism
In the daily use of Bluetooth, everyone must have discovered such a phenomenon: the mobile phone connected to the Bluetooth device will automatically connect to the previously connected device after turning off and then turning on the Bluetooth device. The same scenario has an effect on the Android car system. It is also consistent. So how is this achieved? In this article, we will talk about the automatic reconnection mechanism of Bluetooth in the Android system.
Since Bluetooth is divided into two types of specific carriers: Server and Client, that is, mobile phones and Bluetooth devices (car system), the Bluetooth reconnection mechanism will be different, but the overall process is basically the same:
monitoring the status of Bluetooth Change -> Get device information connected before turning off Bluetooth -> Automatically connect .
1. The Bluetooth automatic reconnection mechanism of mobile phones is mainly implemented in the process com.android.bluetooth, the path:
packages\apps\Bluetooth\src\com\android\bluetooth\btservice\PhonePolicy.java In the
For loop, one of the devices is judged The priority of the protocol determines whether to initiate the connection of the protocol. Only the devices with Priority = BluetoothProfile.PRIORITY_AUTO_CONNECT (1000) will automatically connect.
2. The Bluetooth automatic reconnection mechanism of the car and machine is mainly implemented in the process com.android.car, path:
packages\services\Car\service\src\com\android\car\BluetoothDeviceConnectionPolicy.java
Since the process is almost the same, this article analyzes the realization principle of the automatic reconnection mechanism from the perspective of the car's Bluetooth system. The Bluetooth automatic reconnection mechanism on the mobile phone has a chance to let everyone know (first dig a hole, wait slowly fill…).
The automatic reconnection of the car's Bluetooth is mainly realized in the service process of com.android.car. Let's first understand this process as a whole. From the manifest file of the process, you can know that it started with CarService.java:
Read the connected device information from the system's global variable Settings, and then wait to monitor that the Bluetooth status is turned on, and then reconnect each protocol corresponding to these devices.
The global variable storage path: /data/system/users/0/settings_secure.xml
There are several types of Bluetooth broadcasts registered to monitor:
- BluetoothDevice.ACTION_BOND_STATE_CHANGED—device pairing status
- BluetoothA2dpSink.ACTION_CONNECTION_STATE_CHANGED—media audio protocol connection status
- BluetoothHeadsetClient.ACTION_CONNECTION_STATE_CHANGED-mobile phone audio protocol connection status
- BluetoothPan.ACTION_CONNECTION_STATE_CHANGED—Shared network protocol connection status
- BluetoothPbapClient.ACTION_CONNECTION_STATE_CHANGED—Phonebook protocol connection status
- BluetoothMapClient.ACTION_CONNECTION_STATE_CHANGED—SMS protocol connection status
- BluetoothAdapter.ACTION_STATE_CHANGED—Bluetooth switch state
- BluetoothDevice.ACTION_UUID—device UUID
CarBluetoothUserService is indirectly enabled through getBluetoothUserService() after the bind service PerUserCarService.
Finally, the protocol is reconnected in sequence according to the following protocol sequence:
- BluetoothProfile.HEADSET_CLIENT
- BluetoothProfile.A2DP_SINK
- BluetoothProfile.PBAP_CLIENT
- BluetoothProfile.MAP_CLIENT
- BluetoothProfile.PAN
The most critical part from the analysis of the entire process is to read the data from the Setting, and save the information of the connected device to the Setting when the Bluetooth is turned off or the process exits.
In fact, the reconnection mechanism is not only suitable for the above-mentioned scenario after turning on Bluetooth. Sometimes the link between Bluetooth devices is disconnected due to various reasons. After a period of time, the Bluetooth device needs to be automatically reconnected. This scenario is described above. The reconnection mechanism is not applicable, so how to realize it?
There are also methods. I still remember that I wrote an article "Reason for Bluetooth Link Disconnection" which explained in detail several reasons for Bluetooth ACL link disconnection, but not every disconnection requires automatic reconnection . For example, if the user manually disconnects the Bluetooth and initiates an automatic reconnection, it is too speechless.
So we only need to automatically initiate a reconnection for the scenario where the ACL is disconnected due to link timeout. In this way, when the two Bluetooth devices get close again, they can automatically connect successfully.
The specific implementation scheme can be obtained by referring to the reason for the ACL link disconnection in the "Reason for Bluetooth Link Disconnection", and then it is judged that the reason is the link timeout, and the reconnection is initiated.
After the two Bluetooth devices are disconnected over time, the time to approach again is uncertain. If the automatic reconnection is initiated only once, the device may not be successfully connected. Therefore, the automatic reconnection mechanism here needs to add a loop to ensure a certain success connection.
The Bluetooth reconnection mechanism is simply analyzed here. Interested friends are welcome to leave a message and discuss together.
For more interconnection technologies, please pay attention to the WeChat public account: Connectivity
