Androidsystemrecoverywork use update.zipupgrade Process Analysis (52.16-update.zip package how to enter the recovery service from the upper layer

Androidsystemrecoverywork use update.zipupgrade Process Analysis (wuyun---update.zip package to enter the recovery service from the upper layer

In this document, we will refer to the update.zip package from two sources: OTA online download (generally downloaded to the/cache partition) and manual copy to the SD card. This document does not describe the official update.zip package. This zip package is not processed before it enters the recovery mode. You only need to inform the recovery service of the zip package path before restarting (by calling -- update_package = cache: some_filename.zip or -- update_package = sdcard: the update.zip command is written to/Cache/recovery/command ). Now we have created and copied the update.zip package to the SD card, and run settings --> about
Phone --> system update --> installed from sdcard mode upgrade.

Our test board is tcc8800, And the android source code is gingerbread0919, the source code for the upgrade is located in gingerbread/device/telechips/common/apps/telechipssystemupdater/src/COM/telechips/Android/systemupdater. Next, let's take a look at how update.zip enters the recovery mode step by step from the upper layer.

1. Update from system to reboot

When we choose Settings> about phone> system update> installed from sdcard, a dialog box is displayed, prompting whether the update.zip package has been updated. We will track it from this place. The source code of this dialog box is systemupdateinstalldialog. java.

① In the listening event of the mnowbutton button, mservice. rebootandupdate (new file (mfile) is called )). This mservice is the instance of systemupdateservice. The source code file of this class is systemupdateservice. java. The parameter of this function is a file. We are willing to upload our update.zip package. We can confirm this conjecture.

② Mfile value: In serviceconnection in systemupdateinstalldialog. Java, we can see that the mfile value has two sources.

Source 1:

One source of mfile is whether to immediately update the value received from the previous activity in the prompt box marked with "File. This activity is systemupdate. java. It is a preferenceactivity type. The onpreferencechange function defines the value transmitted to the next activity, which depends on our selection. If we have selected to install the SDK from the SD card before, the uploaded "file" value is "/sdcard/update.zip ". If you select to install from NAND, the corresponding value is "/NAND/update.zip ".

Source 2:

Another source is obtained from mservice. getinstallfile. After further tracking, we can find that the value obtained by the above function is "/cache" + mupdatefileurl. GetFile (). This is the file path corresponding to the OTA online download. The token package is passed to rebootandupdate () as a parameter.

③ Rebootandupdate: in this function, the main system is prepared before the restart. The license package is also passed in.

④ Recoverysystem class: the file path of the source code of the recoverysystem class is: gingerbread0919/frameworks/base/CORE/Java/Android/OS/recoverysystem. java. We are concerned with the installpackage (context, filepackagefile) function. This function first obtains the absolute path filename of the package file based on the package file we passed in. Then, combine them into Arg = "-- update_package =" + filename. It will eventually be written to BCB. This is the operation to be performed by the recovery service after the restart enters the recovery mode. It is passed to the function bootcommand (context, ARG ).

⑤ Bootcommand (): This function is used to prepare the main system before it is restarted. First, create the/Cache/recovery/directory and delete the backup of the command and log (which may not exist) files in the SQLite database. Then, write the ARG command in Step 4 to the/Cache/recovery/command file. The next step is to restart the instance. Next, let's take a look at what we did in the restart function reboot.

6 pm. Reboot (): Before the restart, the powermanager (Power Management) is obtained and the system service is further obtained. Then, the PM. Reboot ("recovery") function is called. This is the reboot function in/gingerbread0919/bionic/libc/unistd/reboot. C. This function is actually a system call, namely _ reboot (linux_reboot_magic1, linux_reboot_magic2, mode, null). From this function, we can see that the first two parameters represent our key combination, mode is the "recovery" we passed in ". Then we further tracked the assembly code, and we were unable to directly view its implementation details. But it is certain that
This function only passes the "recovery" parameter, and then writes "boot-recovery" to the command domain of the BCB data block in the MISC partition. In this way, the bootloader will know that it needs to enter the recovery mode after restart.

Here we cannot be sure whether the recovery domain of BCB has been operated before the main system restarts. In fact, it is not important to update the BCB recovery domain before restarting, because after entering the recovery service, recovery automatically reads the operation to be performed from/Cache/recovery/command and writes it to the recovery domain of BCB.

So far, the main system starts to restart and enters the recovery mode. Before that, the main system did two things: one was to write "boot-recovery" into the BCB command domain, the second is to write -- update_package =/Cache/update.zip "or" -- update_package =/sdcard/update.zip "to the/Cache/recovery/command file. The following sections start to restart and enter the recovery service.

II,From reboot to recovery service

We have already discussed this process above (as shown in the first figure. If no key combination is pressed from the bootloader, the command domain of the BCB block will be read from the MISC partition ("boot-recovery" has been written to the main system ). Start in recovery mode. Different from normal startup, the image loaded in rediscovery mode is rediscovery. IMG. Similar to boot. IMG, this image also contains the standard kernel and root file system. After that, it is similar to a normal startup system. It is also used to start the kernel and then start the file system. After entering the file system, the system will execute/init. The init configuration file is/init. RC. This configuration file is from bootable/recovery/etc/init. RC. View this file and we can see that it is easy to do:

① Set environment variables.

② Establish the ETC connection.

③ Create a directory for backup.

④ Mount/tmp as the memory file system tmpfs

⑤ Start the recovery (/sbin/recovery) service.

6. Start the adbd service (for debugging ).

The most important thing here is of course the recovery service. Our upgrade will be completed in the recovery service.

In the next article, we will analyze the recovery service process details in detail.