Preface

I don't know if you've ever met it. Sometimes the system starts abnormally, and it will directly enter the error interface of a robot. I have encountered that after OTA upgrade, it will restart automatically after startup and enter the robot error interface. It's found that there is a process that restarts continuously when the system is powered on, which triggers the resueparty mechanism. Today, I'm going to take you a little bit to understand this mechanism.

RescueParty

At present, the consumers in the market include Xiaobai users. When their mobile phone starts up in an infinite cycle, the users have no way to fix the abnormality and can only deal with it through the after-sales service of the equipment manufacturer.

Google added this new feature to Android 8.0, which is called the rescue party rescue program.

When the core program of the main monitoring system breaks down in cycles, the program will be started, and a series of operations will be made according to different rescue levels to see whether the device can be recovered. In the most serious case, it is solved by entering recovery and then providing the user to clear the user data and recover the factory settings.

Code path

frameworks\base\services\core\java\com\android\server\RescueParty.java

Rescue level

private static final int LEVEL_NONE = 0;

private static final intLEVEL_RESET_SETTINGS_UNTRUSTED_DEFAULTS = 1; //Mainly reset the property settings of non system processes

private static final intLEVEL_RESET_SETTINGS_UNTRUSTED_CHANGES = 2;//For non system process properties, the default properties from the system are reset and others are deleted

private static final intLEVEL_RESET_SETTINGS_TRUSTED_DEFAULTS = 3;//All process system default properties reset, others deleted

private static final intLEVEL_FACTORY_RESET = 4; //Attempt to restore factory settings

Trigger scenario

(1) System? Server is restarted more than 5 times in 5 minutes to adjust the level.

(2) The permanent system application crashes more than 5 times in 30 seconds and adjusts the level once.

Disable scenario of rescue program

(1) The value of the prop ﹣ enable ﹣ rescue property is false, and the prop ﹣ disable ﹣ rescue property is true

(2) eng version 2

(3) usb mode of mobile phone connection

External interface

In the crashapplicationiner method of apprrors.java, the resuepaarty monitoring is added. The specific code is as follows:

void crashApplicationInner(ProcessRecord r, ApplicationErrorReport.CrashInfo crashInfo,
int callingPid, int callingUid) {
    ...
	// If a persistent app is stuck in a crash loop, the device isn't very
	// usable, so we want to consider sending out a rescue party.
	if (r != null && r.persistent) {
		RescueParty.notePersistentAppCrash(mContext, r.uid);
	}
	
	AppErrorResult result = new AppErrorResult();
	TaskRecord task;
 	...
}

Here, the notePersistentAppCrash method of resultparty is called, and Context and process uid are passed in. Now let's go inside the method:

/**
* Take note of a persistent app crash. If we notice too many of these
* events happening in rapid succession, we'll send out a rescue party.
*/
public static void notePersistentAppCrash(Context context, int uid) {
	if (isDisabled()) return;
	Threshold t = sApps.get(uid);
	if (t == null) {
		t = new AppThreshold(uid);
		sApps.put(uid, t);
	}
	if (t.incrementAndTest()) {
		t.reset();
		incrementRescueLevel(t.uid);
		executeRescueLevel(context);
	}
}

Off the coast

When the device has a valid USB data connection, the system will stop all rescue events, because this is a strong signal that someone is debugging the device.

To stop such suppression, run:

adb shell setprop persist.sys.enable_rescue 1

Looking at the source code, it can be found that in the method to determine whether the mechanism is effective, the attribute is put at the top, that is, the attribute is judged first.

Here, you can trigger a system or interface crash cycle.

To trigger a low-level system server crash cycle, run:

adb shell setprop debug.crash_system 1

To trigger the intermediate SystemUI crash loop, run:

adb shell setprop debug.crash_sysui 1

Both crash cycles initiate the rescue logic. All rescue operations will also be recorded in the permanent PackageManager log stored in / data / system / uiderors.txt for future inspection and debugging. In addition, these persistent logs are included in each error report under the package warning messages section.