Android launches a third-party app that is older than the system app, and kills a third-party app that automatically restarts

1. Why can third-party apps start up earlier than the system app?

Android App Launch Order online there is a lot of information can be consulted, here is not detailed, here does not elaborate ROM start and bootloader, the general process of software startup should be

• Start kernel
  
• Run ServiceManager to start up some native services with commands (including WiFi, power, Rild, Surfaceflinger, mediaserver, etc.)
  
• Start the first process in Dalivk zygote, start the Java Layer System services System_server (including Powermanagerservice, Activitymanagerservice, Telephony.registry, Displaymanagerservice, etc.) these parts of the service are associated with the services of native
  
• Launches Luncher and persistent apps, which are system-level declared android:persistent= "true" in Androidmanifest.xml
  
• Issue action_boot_completed broadcasts to other applications.

It is important to note that the app that declares the Android:persistent property to True will automatically restart after the kill is killed. In the system we know that the Android:persistent attribute is true the app must have the phone app, that is, the third party app should be at least later than the phone app launch, how to judge? The simplest way to look at the size of its PID, the smaller the PID value starts first. A third-party app can be launched before the phone app. We explore its application of the Androidmanifest.xml (PS: How to look at the APK code, the online have you understand the apktool, etc.), found its androidmanifest defined in the static receiver of the Intent-filter properties as follows:

       <receiver android:name= "Com.anguanjia.safe.AAAReceiver" > <span style= "color: #FF0000;" ><intent-filter android:priority= "2147483647" ></span> <action android:name= "Android.bluet Ooth.adapter.action.STATE_CHANGED "/> <action android:name=" Android.net.wifi.WIFI_STATE_CHANGED "/&gt                ; <action android:name= "Android.net.conn.CONNECTIVITY_CHANGE"/> <action android:name= "Android.inten T.action.any_data_state "/> <action android:name=" Android.net.wifi.STATE_CHANGE "/> &lt ;/intent-filter> <intent-filter android:priority= "2147483647" > <action android:name=  "Android.intent.action.MEDIA_UNMOUNTED"/> <action android:name= "Android.intent.action.MEDIA_MOUNTED" /> <action android:name= "Android.intent.action.MEDIA_REMOVED"/> <action androi D:name= "android.iNtent.action.MEDIA_CHECKING "/> <action android:name=" Android.intent.action.MEDIA_EJECT "/> <data android:scheme= "file"/> </intent-filter>

2147483647 What is this value? Very big, oh, it is the largest value of int! Let's look at the Google Docs

Android:priority
The priority that should is given to the parent component with regard to handling intents of the type described by the FIL ter. This attribute have meaning for both activities and broadcast receivers:

It provides information about what able an activity was to respond to an intent that matches the filter, relative to other a Ctivities that could also respond to the intent. When an intent could is handled by multiple activities with different priorities, Android would consider only those with hi Gher priority values as potential targets for the intent.

It controls the order in which broadcast receivers is executed to receive broadcast messages. Those with higher priority values is called before those with lower values. (The order applies only to synchronous messages; it's ignored for asynchronous messages.)

Use this attribute only if you really need to impose a specific order in which the broadcasts is received, or want to for Ce Android to prefer one activity over others.

The value must is an integer, such as "100". Higher numbers has a higher priority. The default value is 0. The value must is greater than-1000 and less than 1000.

This value is the priority of receiver, and the higher the value, the greater the priority, which is performed in order of precedence, but the document describes the priority value size is -1000~1000. The maximum value of the int is applied, but the android:priority value is not checked by the Android platform. The intent-filter of the application receiver has the highest priority after booting, and the intent in the filter is sent by the system (Android.intent.action.MEDIA_MOUNTE, Android.net.wifi.WIFI_STATE_CHANGED and so on), this time the app will be launched according to this intent.

It is important to note that the receiver is static and must be registered in the Androidmanifest. When WiFi is successfully registered, a wifi_state_changed message is issued, or a similar message is sent after the other parts have completed some events, and these messages are issued earlier than the system-level app with the property persistent. This will result in a third-party application that is older than the system-level app startup.

2. On Android phone Why do I want to close the program completely shut down? There is a theory that Android phones in order to have a better user experience, will automatically start some programs in the background, so that our front desk in the operation will feel the phone smoother and smoother. But if the program runs too much, the CPU memory overhead, often causes the system to use the slower, even the phone hangs the problem, in memory management This fast Android has two mechanisms to solve this problem, one is in the framework layer in the Trimapplication method to achieve, The other one is the Lowmemorykiller in kernel, which is no longer detailed here.
But for the user, I just want to completely close the third-party program, so as not to use my traffic too much or secretly do some of the things I do not want. There seems to be no way to close, then why? Let me tell you one of the things here.
Service, as the name implies, is run in front of the background, that can run in the current process can also run in other processes, service can be used for multiple apps sharing, is implemented through the binder mechanism. When I kill a process with a service (without calling StopService ()), the app restarts automatically after a while. The following is the order in which the code is called, viewed from the bottom up.

Com.android.server.am.ActiveServices.scheduleServiceRestartLocked (Activeservices.java)

Com.android.server.am.ActiveServices.killServicesLocked (Activeservices.java)

Com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked (Activitymanagerservice.java)

Com.android.server.am.ActivityManagerService.handleAppDiedLocked (Activitymanagerservice.java)

Com.android.server.am.ActivityManagerService.appDiedLocked (Activitymanagerservice.java)

Com.android.server.am.activitymanagerservice$appdeathrecipient.binderdied (Activitymanagerservice.java)

From the code flow we can see that the service is restart, and the process starts with that service, and the service runs in the process of restarting.

In this case is not really a way, of course not, if we overwrite the service Onstartcommand this function and the return value is start_not_sticky, after we kill the process will not automatically restart, The app we want to close can also be completely shut down and no longer automatically restarted.

    public int <span style= "color: #FF0000;" ><strong>onStartCommand</strong></span> (Intent Intent, int flags, int startid) {        return < Span style= "color: #FF0000;" ><strong>START_NOT_STICKY</strong></span>;    }

Framwork Implementation Code

Frameworks/base/services/java/com/android/server/am/activeservices.java Case Service.start_not_sticky:                        {//We are do with the associated start arguments.                        R.finddeliveredstart (Startid, true);                            if (r.getlaststartid () = = Startid) {//There is no more work, and the This service                            doesn ' t want to hang around if killed. R.<span style= "color: #FF0000;"   >stopIfKilled</span> = true;                    The variable is set to True} break; } if (sr.startrequested && (Sr.<span style= "color: #FF0000;" >stopIfKilled</span> | | Canceled)) {//Enter into the condition if (sr.pendingStarts.size () = = 0) {sr.startrequested                        = false; if (sr.tracker! = null) {sr.tracker.setStarted (False,MAm.mProcessStats.getMemFactorLocked (), Systemclock.uptimemillis ()); } if (!sr.hasautocreateconnections ()) {//Whoops, no reason to re                            start!  Bringdownservicelocked (SR); Execute here, do not restart the app}}}

Override the Onstartcommand method and return the code invocation order with a value of Start_not_sticky, which is viewed from the bottom up.

Com.android.server.am.ActiveServices.bringDownServiceLocked (Activeservices.java)

Com.android.server.am.ActiveServices.killServicesLocked (Activeservices.java)

Com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked (Activitymanagerservice.java)

Com.android.server.am.ActivityManagerService.handleAppDiedLocked (Activitymanagerservice.java)

com.android.server.am.ActivityManagerService.appDiedLocked (Activi Tymanagerservice.java)

Com.android.server.am.activitymanagerservice$appdeathrecipient.binderdied (Activitymanagerservice.java)

A description of the Onstartcommand return value is attached to Google doc

For started services, there is, additional major modes of operation they can decide to run in, depending on the value They return from Onstartcommand (): START_STICKY was used for services, was explicitly started and stopped as needed, while START_NOT_STICKY Or is START_REDELIVER_INTENT used for services this should only remain running while processing any commands sent to them. See the linked documentation for more detail on the semantics.

Here is an explanation of this return value:

When the service process is killed for some reason (insufficient memory, forced shutdown, and so on), Start_sticky re-creates the service after the system has sufficient memory, and handle a null intent in Onstartcommand.

Start_not_sticky notifies the system that the service is not re-created. There is also a return value start_redeliver_intent re-create the service and accompany the original intent to process.