Android Intent Resolution II

Service-side Intent execution Process:

Sticky: This type of broadcast means that some intent need to be retained, and when the new app comes up, you need to focus on the message, but you don't need to start the app to receive this message, such as a headset insertion.
The main role of this function is based on the characteristics of this intent, constructs Broadcastrecord joins to the different list, waits to be processed;
This sends it to the following function:

Control to the schedulebroadcastslocked here, its logic is simple:

Private final void schedulebroadcastslocked () {

if (mbroadcastsscheduled) {

Return

}

Mhandler.sendemptymessage (BROADCAST_INTENT_MSG);

Mbroadcastsscheduled = true;

}

First to determine whether mbroadcastsscheduled is true, if it is true, the direct return, the variable is mainly to implement the order between schedulebroadcastslocked and Processnextbroadcast execution, You will see that it is set to false in the Processnextbroadcast function, and the following is BROADCAST_INTENT_MSG message into the message queue, and finally passed to Mhandler. From this point of view, intent finally also through the thread itself message queue to achieve intent distribution;

Message Distribution process:

Mhandler received broadcast_intent_msg this message and then called Processnextbroadcast (Boolean frommsg) to distribute the message. Here's a look at the flow of this function:
1, first Judge Frommsg, if it is sent over the message is true, otherwise false; If True mbroadcastsscheduled = False, then in the function schedulebroadcastslocked it is possible to send the BROADCAST_INTENT_MSG message again to touch The outgoing processnextbroadcast function is called again;

2, the first to determine whether mparallelbroadcasts is empty, not NULL to start calling the list of receivers to receive messages, the process behind the serial intent will also encounter, we left to discuss later, It is only necessary to know that it sends the intent through a while loop to all receivers concerned with this intent;

3, and then determine whether Mpendingbroadcast is empty, if not empty, it means that the previously sent serial intent has not been processed, generally this may be because we want to send to the receiver has not started, so we need to start the activity, And then wait for this activity to handle, this time, this mpendingbroadcast is true; If you send this situation to determine whether the activity is dead, if dead, then set Mpendingbroadcast to False , or return directly, continue to wait;

4, the next step in order to remove the Broadcastrecord message from the morderedbroadcasts, and then the receiver of this message one by one call its receiving process, note that this In order to put this broadcast all the receivers serial send, all sent out, will enter into the next Broadcastrecord message, for the processing of this message, first determine whether its recipient is broadfilter, if so, It is called Delivertoregisteredreceiver to receive, and its processing flow is the same as the previous processing parallel broadcast.

5, if it is not broadcast Filter, you need to find out the process of this reiver, this is usually a intentfilter process, if the process is alive, then call processcurbroadcastlocked (R, APP) to handle. Otherwise you need to start this process, this is what startprocesslocked do, and then set mpendingbroadcast = R, so that the application will handle this message, there will be further explanation;

Here the function is over, more complex, there are some security checks and so on, the above three questions left:
A) delivertoregisteredreceiver process, B) processcurbroadcastlocked process, C) how to deal with the intent that awakens it after startprocesslocked process;

Delivertoregisteredreceiver
It is also divided into whether this receiver is started or not, and if it has been started, it has been called through binder to receive activity in the process.
The logic of processcurbroadcastlocked
The final difference between it and delivertoregisteredreceive is that only one call is Scheduleregisterdreceiver, one is Schedulereceiver, These two functions will eventually go to the target activity's thread;
Processcurbroadcastlocked

From here we can see that the process of Activitythread.java is initiated by Process.Start, and we look at the execution logic after this thread is started. The first is to call attachapplication through the binder call into the Activitymanagerservice.java process before entering the main loop; Server process is setting the Mpendingbroadcast we set earlier to NULL, indicating that the pending Broadcat has been processed and then called Processcurbroadcastlocked to handle this broadcast message, and finally through app.thread.scheduleReceiver into the target thread's receiving process;:

OK, here's all the sending and distributing process is over, and the rest is two receive function has not discussed one is Scheduleregisterdreceiver, one is schedulereceiver;