\
* * * *
How to restart the main system and enter the Recovery mode when using the update.zip package, how to determine what to do after the Recovery mode, and how to obtain the commands sent by the main system to the Recovery service. This series of problems is solved through close communication between different parts of the entire software platform. To do this, we need to understand how the Recovery mode works, so that we can understand how our update.zip package steps into the Recovery upgrade and finally reaches the main system.
I. Three parts in Recovery mode
The work of ****Recovery requires the cooperation of the entire software platform, which consists of three parts in terms of communication architecture.
(1) MainSystem: the normal boot mode mentioned above (no command in BCB), is the system booted with boot.img, the normal operating mode of Android. When updating, the upper level action in this mode is to upgrade the update.zip package using OTAs or from an SD card. Before restarting and entering Recovery mode, commands are written to the BCB to tell the bootloader to enter Recovery mode after the restart. \
(2) Recovery: After the system enters Recovery mode, the Recovery partition will be loaded, which contains recovery.img (the same as boot.img, which contains the standard kernel and root file system). In this mode, you need to run the Recovery service (/sbin/ Recovery) to perform operations, such as restarting, upgrading update.zip, and erasing cache partitions.
③Bootloader: In addition to normal loading and booting of the system, it also obtains messages from Main System and Recovery by reading MISC partition (BCB).
Two communication interfaces in Recovery mode
**** Communication between the three entities mentioned above is essential in the Recovery service, and they have the following two communication interfaces with each other.
(1) Pass three files in the CACHE partition:
Recovery communicates with the mian system through three files in the /cache/ Recovery/directory. Specific as follows
1 /cache/recovery/command: this file stores command lines transmitted from Main system to recovery. Each line is a command.
–send_intent=anystring // Write the text out to recovery. Write to /cache/recovery/intent
–update_package=root:path //verify install an OTA package file Main system Read the commands from this file and write them to BCB, and then update the update.zip package accordingly.
–wipe_data //erase user data(and cache),then reboot Erase user data. To erase a data partition, you must erase a cache partition.
–wipe_cache //wipe cache(but not user data),then reboot. Deletes a cache partition.
②/cache/recovery/log: Logs are printed in recovery mode. When the recovery service is running, stdout and stderr are relocated to/TMP /recovery.log. Before recovery exits, stdout and stderr are saved to /cache/recovery/log for viewing.
③/cache/recovery/intent: indicates the information delivered to the Main system. Effect unknown.
(2) Through BCB (Bootloader Control Block) :
BCB is the communication interface between bootloader and Recovery as well as between bootloader and Main System. MISC partition stored in Flash, occupying three pages, itself is a structure, the specific members and the meanings of each member are as follows:
struct bootloader_message{
char command[32];
char status[32];
char recovery[1024];
};
① Command member: the possible value of this member has been analyzed in the previous section, that is, when we want to restart the Recovery mode, the value of this member will be updated. In addition, when Recovery is finished after a successful update, the value of this member is cleared to prevent the Recovery mode from entering again during restart.
② Status: After completing the corresponding update, the Bootloader will write the execution result to this field.
③ Recovery: can be written by the Main System or the recovery service program. The content of the file is in the following format:
“Recovery \ n
<recovery command>\n
The < recovery command >”
The file stores a string that must begin with recovery\n, otherwise all content fields for the field will be ignored. The part after “recovery\n” is the command supported by /cache/recovery/command. It can be thought of as a backup of command operations during the Recovery operation. Recovery reads the BCB, then reads /cache/ Recovery /command, and writes both back to BCB to ensure that the operation is performed before entering the Main system. After the operation, Recovery clears the COMMAND and Recovery domains of the BCB before entering the Main system to ensure that the BCB does not enter Recovery mode after the restart.
How do I restart the Main System and enter Recovery mode
Let’s take a look at how these three parts communicate, starting with the following image:
\
We will only look at how the Recovery mode is entered from the Main System; the rest of the communication is described later. If you upgrade the Main System using update.zip, the System will restart and enter Recovery mode. Before the System restarts, the Main System will write boot-Recovery (pink line) to the BCB command field to tell the Bootloader to enter recovery mode after the restart. This step is necessary. Whether the Main System writes to the recovery field is not certain in the source code. Even so, the Bootloader will read the value from /cache/ Recovery /command and put it into the Recovery domain of the BCB after restarting and entering Recovery mode. The Main System must write the recovery operation commands to /cache/recovery/command before restarting.
At this point, we have a general idea of how the master system tells the rebooted system to enter Recovery mode and what to do in Recovery mode when using update.zip.
The next article starts with the first phase, the details of how the Main System restarts and enters the Recovery service when we upgrade using update.zip at the top level.