Android source code avoiding pit guide 2—The ID number of the Bluetooth phone on the HF side is always -1

Android source code avoiding pit guide 2—The ID number for dialing a Bluetooth phone is always -1

It’s another interesting link-Android source code avoidance guide. My colleague compiled a system mirror using the android-9 source code. After the installation was completed, I dialed a Bluetooth phone on the HF side and found that the ID number of the phone was always -1, AT command The idx parameter protocol in "+CLCC" clearly stipulates that the counting starts from 1, which means that the current Bluetooth phone is the number one phone. Now the application layer has received a first -1 Bluetooth phone, which is very inexplicable. Let's take a look at this issue in this article.

Environment : Android-P system

Operation :

1. Car Bluetooth connected to mobile phone Bluetooth successfully
2. Actively make calls through the Bluetooth phone application on the car side (take 10086 as an example)
3. The Bluetooth phone application layer monitors the phone change broadcast in the screenshot below to switch the phone status display:
   

Phenomenon : After the Bluetooth phone application receives the broadcast, it parses out the BluetoothHeadsetClientCall in the broadcast. The ID number of the current phone obtained through the interface getId() is -1. The log print is shown in the figure below:

Since the broadcast of the Bluetooth phone change is broadcast by the Bluetooth service, the assignment of the ID number of the Bluetooth phone to -1 should be performed at the Bluetooth service layer. Not much to say, let’s first understand the timing diagram of this piece of logic:

Through the sequence diagram, we can see that most of the processing of the Bluetooth phone is in the HFP-Client state machine. The two variables marked in red in the above figure are the root causes of this problem.

• mCalls : All Bluetooth phones currently existing

• mCallsUpdate : Bluetooth phones whose information needs to be updated after this AT+CLCC command

Tracing back to the Android source code, I found that the first occurrence of the ID of -1 was in the HeadsetClientService.dial() method. This method constructed a new value BluetoothHeadsetClientCall, which represents the Bluetooth phone currently dialed. The ID number used is the constant in HeadsetClientStateMachine The value HF_ORIGINATED_CALL_ID = -1, and the call will be sent to the state machine along with the DIAL_NUMBER message. The call id saved in mCalls is -1 after the call is issued.

The mCallsUpdate saves all the phone information reported from the Bluetooth protocol stack. It can be clearly found from the HCI that the ID numbers of the reported phones are all 1 (currently only this one 10086 is
in a call)

So the problem should be in queryCallsDone(), the Android source code developers did not consider this situation when updating the phone status?

Continue to check the source code of this part, my god, this situation has been considered in the source code comments, so how to broadcast it is the ID number of -1, and I am confused...

Continue to analyze the steps of the source code update, and finally I can see the trickyness of it by my eyes, haha

At this point, I smiled shamelessly. I finally found the root cause. The ID value in the call has not changed from the beginning to the end, so that no matter how the status of the subsequent phone changes, the ID number is -1.

If the reason is found, let's think about the solution. I provide a solution here as the screenshot below, hehe

Re-program the Bluetooth service module Bluetooth.apk or the full system.img, and the problem is solved after verification. Interested friends are welcome to privately message other good solutions, we will discuss together.

For more interconnection technologies, please pay attention to the WeChat public account: Connectivity