Android realizes the function of vibration prompt after the phone is connected

Some mobile phones will have vibration prompt after the phone is connected, which has the advantage that they can wait until they are connected and then put them in their ears to answer, so as to reduce radiation. This article will talk about how to realize the vibration prompt function after connecting the phone in Android mobile phone, mainly for outgoing calls.

Call status provided by Android SDK

Obviously, to generate vibration prompt when the phone is connected, you first need to know when the phone is connected. The Android SDK does not provide a method to directly read this state. The following are the three phone statuses provided by the telephonymanager of the phone service class of the Android SDK:

CALL_ STATE_ Idle state

CALL_ STATE_ Offhook off hook status

CALL_ STATE_ Ringing status

These states are easy to understand: the off hook state is the action of picking up the microphone (for landline phones), but this state may occur when the incoming call is connected or when the outgoing call is connected, but it does not mean that the outgoing call is connected. Through the above three states, we can only combine the two states of hang up and incoming call connection. What we want to achieve today cannot be achieved.

It seems that we need to find other ways to implement it. The SDK is unreliable

Android running log analysis

Fortunately, a large number of logs will be generated when Android is running. Let's see if we can find the surge port from this? We choose the log of Android radio module to analyze. First, we need to write a piece of code to read the radio related log. Logcat is necessary to read the log.

In addition, to enable the program to read the system log, you need to specify permissions in androidmanifest Add the following content to the XML file.

XML / HTML code

<uses-permission android:name="android.permission.READ_LOGS"></uses-permission>

Through the above code, we can output the radio logs to, so that we can view these logs in DDMS and analyze the call process. The specific caught logs will not be posted. You can write your own programs and capture and analyze them through the above code. I'll just talk about my analysis.

Some clues were found by analyzing the log. There are several useful logs:

GET_ CURRENT_ CALLS id=1,DIALING

GET_ CURRENT_ CALLS id=1,ALERTING

GET_ CURRENT_ CALLS id=1,ACTIVE

Because the log is long, I only took the first part of each log, which will have a lot more real content. When we dial out the phone, we will enter these logs.

Dialing - > reminder - > activity

It's roughly such a process. After several tests, it is found that when the phone is connected, it will enter the active state and output: get_ CURRENT_ Call id = 1, active log, so far we are close to success.

However, later, I found that during the period from the beginning of dialing to the connection of the phone, there will be many state changes such as "dialing - > reminder - > activity". Only when the beep in the microphone rings_ CURRENT_ The call log will be locked in alerting. Get does not appear until the phone is connected_ CURRENT_ Calls log.

Maybe the above statement is not very clear. In other words, there will be multiple get before the call is connected_ CURRENT_ Calls active logs are generated only once when the phone is connected. This caused us trouble. You can't just grab get_ CURRENT_ Call active.

We can only realize it through some logical judgment.

Explanation of example code

Here's my code:

My method is far fetched by judging the interval between the first dialing and each alerting. If the interval is greater than 1.5 seconds, it is considered that it is time to enter the "beep" prompt, and the next active will be phone connection. This 1.5 second is obtained by analyzing the log. But I still don't think this method is reliable. If you have a good way to communicate.

The rest is to let the thread trigger when the phone is dialed out and prepare when it is resident on the phone. It can be realized by using service and receiver. Service to achieve resident, and receiver to monitor outgoing calls. We can basically complete the functions we want.

I have tested all the above codes, 99% effective, ha ha. There are some basic contents of Android, such as logcat, service and receiver. If you don't understand them, you can find relevant articles and materials to learn.

Through this article, I hope to help Android developers. Thank you for your support for this site!