Android background killing series 2: ActivityManagerService and App on-site recovery mechanism

This is the second in the Android background killing series, mainly explaining how ActivityMangerService restores processes killed in the background (based on 4.3). In the opening FragmentActivity and PhoneWindow background killing processing mechanism, some common problems caused by background killing are briefly described, as well as some compatibility of Android system controls with background killing, and the role of onSaveInstance and onRestoreInstance in execution timing. Finally, it talks about how to deal with background killing, but there is no explanation on how to restore processes killed in the background. This article does not involve background killing, such as the LowmemoryKiller mechanism, but only describes how to restore killed processes. Suppose an application is killed in the background, and when the App is called up again from the recent task list, how does the system handle it? There are several problems that may need to be solved:

• How does the Android framework layer (AMS) know that the App is killed?
• How is the scene before the App is killed saved?
• How to restore the killed App by the system (AMS)
• What is the difference between the startup process of an App killed by the background and the normal startup process?
• Why is the order of Activity restoration reversed?

How does the system (AMS) know that the App is killed?

First, let's look at the first question. How does the system know that the Application has been killed? Android uses the Linux oomKiller mechanism, but simply makes a variant of it, using a hierarchical LowmemoryKiller. But this is actually at the kernel level. After LowmemoryKiller kills the process, it will not send a notification to the user space, which means that the ActivityMangerService at the framework layer cannot know whether the App has been killed. However, only by knowing whether the App or Activity has been killed can AMS (ActivityMangerService) correctly follow the wake-up process. So when does AMS know that the App or Activity has been killed in the background? Let's first look at what happens when we wake up from the recent task list.

The process of calling up the App again from the recent task list or Icon

In the system source code systemUi package, there is a RecentActivity, which is actually the entrance to the recent task list, and its presentation interface is displayed through RecentsPanelView. Click the recent App and its execution code is as follows:

 public void handleOnClick( View   view ) {
    ViewHolder holder = (ViewHolder) view .getTag();
    TaskDescription ad = holder.taskDescription;
    final Context context = view .getContext();
    final ActivityManager am = (ActivityManager)
            context.getSystemService(Context.ACTIVITY_SERVICE);
    Bitmap bm = holder.thumbnailViewImageBitmap;
 ...
 // Key point 1 If TaskDescription is not closed actively, it is closed normally, ad.taskId is >= 0
 if (ad.taskId >= 0) {
        // This is an active task; it should just go to the foreground.
        am.moveTaskToFront(ad.taskId, ActivityManager.MOVE_TASK_WITH_HOME,
 opts);
 } else {
        Intent intent = ad.intent;
        intent.addFlags(Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY
                | Intent.FLAG_ACTIVITY_TASK_ON_HOME
                | Intent.FLAG_ACTIVITY_NEW_TASK);
 try {
            context.startActivityAsUser(intent, opts,
                    new UserHandle(UserHandle.USER_CURRENT));
 }...
 }

In the above code, there is a judgment ad.taskId >= 0. If this condition is met, the APP is called up through moveTaskToFront. So how is ad.taskId obtained? There are various RecentTasksLoader in the recent package. This class is a Loader used to load the recent task list. Take a look at its source code, mainly at loading:

 @Override
       protected Void doInBackground(Void... params) {
 // We load   in two stages: first , we update progress with just the first screenful
           // of items. Then , we update   with the rest of the items
           final int origPri = Process.getThreadPriority(Process.myTid());
           Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
           final PackageManager pm = mContext.getPackageManager();
           final ActivityManager am = (ActivityManager)
           mContext.getSystemService(Context.ACTIVITY_SERVICE); 
 
           final List<ActivityManager.RecentTaskInfo> recentTasks =
                   am.getRecentTasks(MAX_TASKS, ActivityManager.RECENT_IGNORE_UNAVAILABLE); 
             
 ....
               TaskDescription item = createTaskDescription(recentInfo.id,
                       recentInfo.persistentId, recentInfo.baseIntent,
                       recentInfo.origActivity, recentInfo.description);
 ....
 }

As you can see, it actually requests the recent task information from AMS through ActivityManger's getRecentTasks, and then creates TaskDescription through createTaskDescription. The recentInfo.id passed here is actually the taskId of TaskDescription. Let's take a look at its meaning:

 public List<ActivityManager.RecentTaskInfo> getRecentTasks( int maxNum,
 int flags, int userId) {
 ...
        IPackageManager pm = AppGlobals.getPackageManager(); 
 
        final int N = mRecentTasks. size ();
 ...
 for ( int i=0; i<N && maxNum > 0; i++) {
            TaskRecord tr = mRecentTasks.get(i);
 if (i == 0
                    || ((flags&ActivityManager.RECENT_WITH_EXCLUDED) != 0)
                    || (tr.intent == null )
                    || ((tr.intent.getFlags()
                            &Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS) == 0)) {
                ActivityManager.RecentTaskInfo rti
                        = new ActivityManager.RecentTaskInfo();
                rti.id = tr.numActivities > 0 ? tr.taskId : -1;
                rti.persistentId = tr.taskId;
                rti.baseIntent = new Intent(
                        tr.intent != null ? tr.intent : tr.affinityIntent);
                if (!detailed) {
                    rti.baseIntent.replaceExtras((Bundle) null );
 }

It can be seen that the id of RecentTaskInfo is determined by TaskRecord. If numActivities > 0 in TaskRecord, go to the Id of TaskRecord, otherwise take -1. The numActivities here is actually the number of ActivityRecords recorded in TaskRecode. For more specific details, you can check ActivityManagerService and ActivityStack by yourself. Then it is easy to explain here. As long as it is a surviving APP or an APP killed by LowmemoryKiller, its AMS ActivityRecord is completely saved. This is the basis for recovery. The data obtained by RecentActivity is actually a replica of the one in AMS. RecentActivity does not know whether the APP to be awakened is alive. As long as TaskRecord tells RecentActivity that it is in stock, it will directly go through the awakening process, that is, awaken the App through ActivityManager's moveTaskToFront. As for the subsequent work, it will be completely handled by AMS. Now take a look at the flowchart here:

When calling up the App, AMS detects whether the App or Activity is killed abnormally.

Next, look at moveTaskToFrontLocked. This function is in ActivityStack. ActivityStack is mainly used to manage ActivityRecord stack. All started Activities retain an ActivityRecord in ActivityStack, which is also a basis for AMS to manage Activity. ActivityStack finally movesTaskToFrontLocked and calls resumeTopActivityLocked to wake up Activity. AMS obtains the information of the Activity to be resumed mainly through ActivityRecord. It does not know whether the Activity itself is alive. After obtaining it, AMS knows the link of waking up the Activity before knowing that the App or Activity is killed. Take a look at the resumeTopActivityLocked source code:

 final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) { 
   
     // This activity is now becoming visible.
        mService.mWindowManager.setAppVisibility( next .appToken, true ); 
                
 .... Restore Logic
    if ( next .app != null && next .app.thread != null ) {
 // Normal recovery
 try {
            // Deliver all pending results.
            ArrayList a = next .results;
 if (a != null ) {
                final int N = a. size ();
                if (! next .finishing && N > 0) {
 next .app.thread.scheduleSendResult( next .appToken, a);
 }
 }
 ...
 next .app.thread.scheduleResumeActivity( next .appToken,
                    mService.isNextTransitionForward());
 ...
        } catch (Exception e) {
            // Whoops, need to restart this activity!
 // A restart is needed here. Is it killed by the background? Is it an abnormal branch? ? ? ? Killed by abnormality
            if (DEBUG_STATES) Slog.v(TAG, "Resume failed; resetting state to "  
                    + lastState + ": " + next );
 next .state = lastState;
            mResumedActivity = lastResumedActivity;
 <! --Indeed, this is because the process has hung up-->  
            Slog.i(TAG, "Restarting because process died: " + next );
 . . .
            startSpecificActivityLocked( next , true , false );
 return   true ;
 }
 ...
 }

Since finish is not actively called, AMS will not clean up ActivityRecord and TaskRecord. Therefore, when resuming, the above branch is taken. Next.app.thread.scheduleSendResult or next.app.thread.scheduleResumeActivity may be called here to call up the previous Activity. However, if the APP or Activity is killed by an exception, the call-up operation must fail and an exception will be thrown. First, assuming that the entire APP is killed, the Binder thread that communicates with AMS on the APP side no longer exists. At this time, RemoteException will be thrown when communicating through Binder. In this way, the catch part below will be taken, and the APP will be rebuilt again through startSpecificActivityLocked, and the last Activity will be rebuilt. In fact, you can use AIDL to write a C/S communication locally, close one end, and then access it with the other end, which will throw a RemoteException, as shown below:

There is another possibility, the APP is not killed, but the Activity is killed. What will happen at this time? First of all, the management of Activity must be through AMS, and the killing of Activity must be handled by AMS and recorded. Strictly speaking, this situation does not belong to background killing, because it belongs to the normal management of AMS and is within the controllable range. For example, if the "Do not retain activities" in the developer mode is turned on, at this time, although the Activity will be killed, the ActivitRecord is still retained, so there is still a trace to follow when waking up or rolling back. Take a look at the Destroy callback code of ActivityStack.

 final boolean destroyActivityLocked(ActivityRecord r,
            boolean removeFromApp, boolean oomAdj, String reason) {
 ...
 if (hadApp) {
 ...
           boolean skipDestroy = false ;
 try {
 Key code 1
                r.app.thread.scheduleDestroyActivity(r.appToken, r.finishing,
                        r.configChangeFlags);
 ...
            if (r.finishing && !skipDestroy) {
                if (DEBUG_STATES) Slog.v(TAG, "Moving to DESTROYING: " + r
                        + " (destroy requested)" );
                r.state = ActivityState.DESTROYING;
                Message msg = mHandler.obtainMessage(DESTROY_TIMEOUT_MSG);
 msg.obj = r;
                mHandler.sendMessageDelayed(msg, DESTROY_TIMEOUT);
 } else {
 Key code 2
                r.state = ActivityState.DESTROYED;
                if (DEBUG_APP) Slog.v(TAG, "Clearing app during destroy for activity " + r);
                r.app = null ;
 }
 }
 return removedFromHistory;
 }

There are two key points here: 1. Tell the client's AcvitityThread to clear the Activity; 2. If the AMS closes the Activity abnormally, set the state of the ActivityRecord to ActivityState.DESTROYED and clear its ProcessRecord reference: r.app = null. This is an important sign when waking up. Through this, AMS can know that the Activity was closed abnormally by itself. Setting ActivityState.DESTROYED is to avoid the subsequent clearing logic.

 final void activityDestroyed(IBinder token) {
 synchronized (mService) {
        final long origId = Binder.clearCallingIdentity();
 try {
            ActivityRecord r = ActivityRecord.forToken(token);
 if (r != null ) {
                mHandler.removeMessages(DESTROY_TIMEOUT_MSG, r);
 }
 int   index = indexOfActivityLocked(r);
            if ( index >= 0) {
 1 <! --Whether to remove ActivityRecord from the history list here -->  
                if (r.state == ActivityState.DESTROYING) {
                    cleanUpActivityLocked(r, true , false );
                    removeActivityFromHistoryLocked(r);
 }
 }
            resumeTopActivityLocked( null );
 finally
            Binder.restoreCallingIdentity(origId);
 }
 }
 }

Look at the key point 1 of the code. Only when r.state == ActivityState.DESTROYING will ActivityRecord be removed. However, for an Activity that is not finished abnormally, its state will not be set to ActivityState.DESTROYING. It will directly skip ActivityState.DESTROYING and be set to ActivityState.DESTROYED. Therefore, it will not removeActivityFromHistoryLocked, which means that the ActivityRecord scene is retained. It seems that it also relies on exceptions to distinguish whether the Activity is terminated normally. How to start the Activity in this case? Through the above two analysis, we know two key points.

1. ActivityRecord is not removed from HistoryRecord list
2. The ProcessRecord field of ActivityRecord is set to null, r.app = null

This ensures that when resumeTopActivityLocked, the startSpecificActivityLocked branch is taken

 final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
 ... 
              
        if ( next .app != null && next .app.thread != null ) {
 ... 
         
 } else {
            // Whoops, need to restart this activity!
 ...
            startSpecificActivityLocked( next , true , true );
 } 
 
 return   true ;
 }

At this point, AMS knows whether the app or activity has been killed abnormally, and thus decides whether to go through the resume process or the restore process.

How to save the scene before the App is killed: New Activity startup and old Activity preservation

The process of saving the App scene is relatively simple. The entry point is basically when starting Activity. As long as the interface jumps, it basically involves the switching of Activity and the saving of the current Activity scene: Let's draw a simple diagram first. When talking about FragmentActivity in the opening part, I briefly talked about the execution timing of onSaveInstance. Here we will take a closer look at how AMS manages these jumps and scene saving. Simulate the scenario: When Activity A starts Activity B, A is not visible at this time and may be destroyed. It is necessary to save the scene of A. What is this process like: It is briefly described as follows

• ActivityA startActivity ActivityB
• ActivityA pause
• ActivityB create
• ActivityB start
• Activity B resume
• ActivityA onSaveInstance
• ActivityA stop

The process is probably as follows:

Now let's follow the source code step by step to see what AMS does when the new Activity is started and the old Activity is saved: skip the simple startActivity and go directly to AMS to see

ActivityManagerService

 public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
        Intent intent, String resolvedType, IBinder resultTo,
        String resultWho, int requestCode, int startFlags,
        String profileFile, ParcelFileDescriptor profileFd, Bundle options, int userId) {
    enforceNotIsolatedCaller( "startActivity" );
 ...
 return mMainStack.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType,
            resultTo, resultWho, requestCode, startFlags, profileFile, profileFd,
 null , null , options, userId);
 }

ActivityStack

 final int startActivityMayWait(IApplicationThread caller, int callingUid, 
                   
 int res = startActivityLocked(caller, intent, resolvedType,
                aInfo, resultTo, resultWho, requestCode, callingPid, callingUid,
                callingPackage, startFlags, options, componentSpecified, null ); 
         
 . . .
 }

Here, startActivityMayWait is used to start a new APP or a new Activity. Here we only look at the simple ones. As for the process of starting the App from the desktop, you can refer to more detailed articles, such as Lao Luo's startActivity process, which is probably to create a new ActivityRecord, ProcessRecord, etc., and add the corresponding stack in AMS, etc., resumeTopActivityLocked is the unified entrance for interface switching. When you come in for the first time, since ActivityA is not paused yet, you need to pause ActivityA first. After these are completed,

ActivityStack

 final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
 ...
 <! --You must set the current Resume Activity to pause and then stop it before you can continue -->  
 // We need to start pausing the current activity so the top one
 // can be resumed...
  if (mResumedActivity != null ) {
      if ( next .app != null && next .app.thread != null ) { 
           
          mService.updateLruProcessLocked( next .app, false );
 }
      startPausingLocked(userLeaving, false );
 return   true ;
 }
 ....

In fact, here is to pause ActivityA. AMS tells ActivityThread that ActivityA needs to be paused through Binder. After ActivityThread is completed, it notifies AMS through Binder, and AMS will start to resume ActivityB.

 private final void startPausingLocked(boolean userLeaving, boolean uiSleeping) { 
 
    if (prev.app != null && prev.app.thread != null ) {
 ...
 try {
            prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
                    userLeaving, prev.configChangeFlags);

ActivityThread

 private void handlePauseActivity(IBinder token, boolean finished,
            boolean userLeaving, int configChanges) {
        ActivityClientRecord r = mActivities.get(token);
 if (r != null ) {
 ...
            performPauseActivity(token, finished, r.isPreHoneycomb());
 ...
            // Tell the activity manager we have paused.
 try {
                ActivityManagerNative.getDefault().activityPaused(token);
            } catch (RemoteException ex) {
 }
 }
 }

After receiving the pause message from ActivityA, AMS will wake up ActivityB, and the entry is still resumeTopActivityLocked, wake up B, and then stop A further. At this time, the scene preservation is involved.

ActivityStack

 private final void completePauseLocked() { 
   
   if (!mService.isSleeping()) {
       resumeTopActivityLocked(prev);
 } else { 
    
 ... 
    

This article does not care how ActivityB is started. We only care about how ActivityA saves the scene. After ActivityB starts, it stops ActivityA through stopActivityLocked of ActivityStack.

 private final void stopActivityLocked(ActivityRecord r) {
 ...
 if (mMainStack) { 
              
            r.app.thread.scheduleStopActivity(r.appToken, r.visible, r.configChangeFlags);
 ...
 }

Looking back at the APP side, let's look at the call in ActivityThread: First, callActivityOnSaveInstanceState to save the scene to the Bundle.

 private void performStopActivityInner(ActivityClientRecord r,
        StopInfo info, boolean keepShown, boolean saveState) {
 ...
        // Next have the activity save its current state and managed dialogs...
        if (!r.activity.mFinished && saveState) {
            if (r.state == null ) {
                state = new Bundle();
                state.setAllowFds( false );
                mInstrumentation.callActivityOnSaveInstanceState(r.activity, state);
                r.state = state;
 . . .
 }

Afterwards, ActivityManagerNative.getDefault().activityStopped is used to notify AMS that the Stop action is complete. When notifying, the saved on-site data will also be brought over.

 private static class StopInfo implements Runnable {
    ActivityClientRecord activity;
 Bundle state;
 Bitmap thumbnail;
 CharSequence description; 
 
    @Override public void run() {
        // Tell activity manager we have been stopped.
 try { 
 
            ActivityManagerNative.getDefault().activityStopped(
                activity.token, state, thumbnail, description);
        } catch (RemoteException ex) {
 }
 }
 }

Through the above process, AMS not only starts a new Activity, but also saves the scene of the previous Activity. Even if the previous Activity is killed for various reasons, AMS can still know how to wake up the Activity and restore it during the rollback or re-awakening process.

Now we need to solve two problems: 1. How to save the scene, 2. How does AMS determine whether the APP or Activity is killed abnormally? Then the last question is how does AMS restore the APP or Activity that was killed abnormally.

Recovery logic when the entire Application is killed in the background

In fact, when explaining how AMS determines whether the APP or Activity is killed by an exception, the logic of recovery has been involved. We also know that once AMS knows that the APP is killed by the background, it is not a normal resume process, but a relaucher. Let's first look at how the entire APP is handled when it is killed. Look at the resumeTopActivityLocked part. From the above analysis, it is known that in this scenario, the Binder communication will throw an exception and take the exception branch, as follows:

 final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
 ....
  if ( next .app != null && next .app.thread != null ) {
            if (DEBUG_SWITCH) Slog.v(TAG, "Resume running: " + next );
 ...
 try {
 ...
            } catch (Exception e) {
                // Whoops, need to restart this activity!
 Here is to know that the entire app is killed
                Slog.i(TAG, "Restarting because process died: " + next );
 next .state = lastState;
                mResumedActivity = lastResumedActivity;
                Slog.i(TAG, "Restarting because process died: " + next ); 
               
                startSpecificActivityLocked( next , true , false );
 return   true ;
 }

From the above code, we can know that it is actually startSpecificActivityLocked, which is not much different from the first time you call up the APP from the desktop. There is only one thing to note, that is, the Activity started at this time has the last scene data passed, because the last time when it retreated to the background, all the scenes of the Activity interface were saved and passed to AMS, then this time the recovery startup will return this data to ActivityThread, let's take a closer look at the special processing code for recovery in performLaunchActivity:

 private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
 ActivityInfo aInfo = r.activityInfo;
     Activity activity = null ;
 try {
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);
        StrictMode.incrementExpectedActivityCount(activity.getClass());
        r.intent.setExtrasClassLoader(cl);
        if (r.state != null ) {
            r.state.setClassLoader(cl);
 }
 } catch (Exception e) {
 ...
 }
 try {
        Application app = r.packageInfo.makeApplication( false , mInstrumentation);
 ...
 Key Point 1
            mInstrumentation.callActivityOnCreate(activity, r.state);
 ...
            r.activity = activity;
            r.stopped = true ;
            if (!r.activity.mFinished) {
                activity.performStart();
                r.stopped = false ;
 }
 Key Point 1
            if (!r.activity.mFinished) {
                if (r.state != null ) {
                    mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
 }
 }
            if (!r.activity.mFinished) {
                activity.mCalled = false ;
                mInstrumentation.callActivityOnPostCreate(activity, r.state);
 ... 
 
 }

Let's look at key points 1 and 2. First, let's look at key point 1. mInstrumentation.callActivityOnCreate will call back onCreate of Activity. This function actually mainly performs some Fragment recovery work for FragmentActivity. r.state in ActivityClientRecord is what AMS transmits to APP to restore the scene. When it starts normally, these are null. Let's look at key point 2. When r.state != null is not empty, mInstrumentation.callActivityOnRestoreInstanceState is executed. This function is mainly used to restore Window by default, such as restoring the previous display position of ViewPager, etc. It can also be used to restore user saved data.

The application is not killed by the background, and the activity is killed and restored

Turning on the developer mode "Do not retain activities" is such a scenario. In the above analysis, we know that when AMS actively kills the Activity abnormally, the app field of AcitivityRecord is set to empty. Therefore, resumeTopActivityLocked is different from the entire APP being killed, and the following branch will be taken

 final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
 ... 
         
    if ( next .app != null && next .app.thread != null ) {
 ... 
         
 } else {
 Key point 1 is just restarting the Activity, which shows that the process is not dead.
        // Whoops, need to restart this activity! 
         
        startSpecificActivityLocked( next , true , true );
 } 
 
 return   true ;
 }

Although they are slightly different, they still follow the startSpecificActivityLocked process, but they do not create a new APP process. The rest are the same and will not be explained here. At this point, we should understand.

• How does Android save the scene in case of prevention?
• How does AMS know if the app is killed in the background?
• How does AMS rebuild the scene when the app is killed based on ActivityStack?

At this point, the logic of ActivityManagerService restoring the APP scene should be explained. Let me mutter some more questions, which may be some interview points.

• The difference between actively clearing recent tasks and abnormal killing: Is ActivityStack cleared normally?
• Why is it restored in reverse order when restoring? Because this is the order of the stack in the HistoryRecord in the ActivityStack, strictly according to the AMS end
• In one sentence, the principle of Android background killing and recovery is summarized as follows: the application process is killed, but the scene is saved by AMS, and AMS can restore the application scene based on the saved scene.