Android System Recovery Working principle use Update.zip upgrade process analysis (vi)---Recovery service flow details "Go"

This article was reproduced from: http://blog.csdn.net/mu0206mu/article/details/7465439

Android System Recovery Working principle use Update.zip upgrade process analysis (vi)---recovery service process details

The recovery service is undoubtedly the most central part of the recovery startup model. It completes all the work in the recovery mode. Recovery program corresponding source files are located in:/gingerbread0919/bootable/recovery/recovery.c.

First, recovery three types of services:

Take a look at the first section of the comments in this source file, which will help us understand the main features of the recovery service. The code is as follows:

[CPP]View PlainCopy

2. /*
4. * The recovery tool communicates with the main system Through/cache files.
6. */cache/recovery/command-input-command line to tool, one arg per line
8. */cache/recovery/log-output-combined log file from recovery run (s)
10. */cache/recovery/intent-output-intent that is passed in
12. *
14. * The arguments which is supplied in the Recovery.command file:
16. *--send_intent=anystring-write the text out to Recovery.intent
18. *--update_package=path-verify Install an OTA package file
20. *--wipe_data-erase user data (and cache), then reboot
22. *--wipe_cache-wipe cache (but not user data) and then reboot
24. *--set_encrypted_filesystem=on|off-enables/diasables Encrypted FS
26. *
28. * After completing, we remove/cache/recovery/command and reboot.
30. * Arguments may also is supplied in the bootloader control block (BCB).
32. * These important scenarios must be safely restartable at any point:
34. *
36. * FACTORY RESET
38. * 1. User selects "Factory reset"
40. * 2. Main system writes "--wipe_data" To/cache/recovery/command
42. * 3. Main system reboots into recovery
44. * 4. Get_args () writes BCB with "Boot-recovery" and "--wipe_data"
46. *--after this, rebooting'll restart the erase--
48. * 5. Erase_volume () Reformats/data
50. * 6. Erase_volume () Reformats/cache
52. * 7. Finish_recovery () erases BCB
54. *--after this, rebooting'll restart the main system--
56. * 8. Main () calls reboot () to boot main system
58. *
60. * OTA INSTALL
62. * 1. Main System Downloads OTA package To/cache/some-filename.zip
64. * 2. Main system writes "--update_package=/cache/some-filename.zip"
66. * 3. Main system reboots into recovery
68. * 4. Get_args () writes BCB with "Boot-recovery" and "--update_package= ..."
70. *--after this, rebooting'll attempt to reinstall the update--
72. * 5. Install_package () attempts to install the update
74. * Note:the Package Install must itself is restartable from any point
76. * 6. Finish_recovery () erases BCB
78. *--after this, rebooting'll (try to) restart the main system--
80. * 7. * * If install failed * *
82. * 7a. Prompt_and_wait () shows an error icon and waits for the user
84. * 7b; The user reboots (pulling the battery, etc) into the main system
86. * 8. Main () calls Maybe_install_firmware_update ()
88. * * * * If the update contained radio/hboot firmware * *:
90. * 8a. M_i_f_u () writes BCB with "Boot-recovery" and "--wipe_cache"
92. *--after this, rebooting'll reformat cache & Restart main system--
94. * 8b. M_i_f_u () writes firmware image into raw cache partition
96. * 8c. M_i_f_u () writes BCB with "Update-radio/hboot" and "--wipe_cache"
98. *--after this, rebooting'll attempt to reinstall firmware--
100. * 8d. Bootloader tries to flash firmware
102. * 8e. Bootloader writes BCB with "Boot-recovery" (Keeping "--wipe_cache")
104. *--after this, rebooting'll reformat cache & Restart main system--
106. * 8f. Erase_volume () Reformats/cache
108. * 8g. Finish_recovery () erases BCB
110. *--after this, rebooting'll (try to) restart the main system--
112. * 9. Main () calls reboot () to boot main system
114. *
116. * SECURE FILE SYSTEMS enable/disable
118. * 1. User selects "Enable Encrypted file systems"
120. * 2. Main system writes "--set_encrypted_filesystems=on|off" to
122. */cache/recovery/command
124. * 3. Main system reboots into recovery
126. * 4. Get_args () writes BCB with "Boot-recovery" and
128. * "--set_encrypted_filesystems=on|off"
130. *--after this, rebooting'll restart the transition--
132. * 5. Read_encrypted_fs_info () Retrieves encrypted file systems settings From/data
134. * Settings Include:property to specify the Encrypted FS istatus and
136. * FS encryption key if enabled (not yet implemented)
138. * 6. Erase_volume () Reformats/data
140. * 7. Erase_volume () Reformats/cache
142. * 8. Restore_encrypted_fs_info () writes required encrypted file systems settings To/data
144. * Settings Include:property to specify the Encrypted FS status and
146. * FS encryption key if enabled (not yet implemented)
148. * 9. Finish_recovery () erases BCB
150. *--after this, rebooting'll restart the main system--
152. * 10. Main () calls reboot () to boot main system
154. */

From the comments we can see that recovery's service content has three main categories:

①factory Reset, restore factory settings.

②ota INSTALL, which is our Update.zip package upgrade.

③encrypted file system enable/disable to enable/disable encrypting the FileSystem. The approximate workflow for each type of service, as noted in the notes, will be explained in detail in the following section of the Ota install workflow. The general flow of these three types of services is common, but different operations are embodied with different operational details. Let's look at the general flow of recovery services.

Second, the general flow of recovery services:

Here we take the OTA install process as an example of specific analysis. And start with the call process diagram for the related function, such as:

We follow the flowchart analysis, starting with the main function of RECOVERY.C:

1. Ui_init (): The recovery service uses a simple framebuffer-based UI (MINIUI) system. This function simply initializes it. During the recovery service, it is used primarily to display a background picture (installation or installation failure) and a progress bar (to show progress). In addition, two threads are started, one for processing the display of the progress bar (Progress_thread), and the other for responding to the user's keystrokes (input_thread).

2. Get_arg (): This function mainly does the work of Get_arg () to the right down until the parse arg/v. We look at a process one by one.

①get_bootloader_message (): The main task is to read the BCB data block from the misc partition to a temporary variable based on the partition's file format type (MTD or EMMC).

② then begins to determine whether the recovery service has arguments with the command line (/sbin/recovery, which is not available according to the existing logic), and if not, reads the recovery domain from the BCB. If the read fails, it is read from/cache/recovery/command and then. The recovery field in this BCB temporary variable is updated. Before the temporary variable of this BCB is written back to the real BCB, the command field of this BCB temporary variable is "boot-recovery". The purpose of this is that if the upgrade fails (such as a power outage if the upgrade is not over), the system will enter recovery mode after the reboot until the upgrade is complete.

③ is written back to the true BCB block after all the fields of this BCB temporary variable have been updated with Set_bootloader_message ().

This process can be summed up in a simple diagram to make it clearer:

3. PARSERARGC/ARGV: Parse we get parameters. Register the resolved command (Register_update_command), in the following operation will be based on the value of this step resolved step by step judgment, and then do the appropriate action.

4. if (update_package): Determine if the update_package has a value, if there is a need to upgrade the update package, you will call Install_package () (the second phase of red in the figure). In this step you will complete the installation of the actual upgrade package. This is the most complex and the most important part of upgrading the Update.zip package. We'll analyze the process in more detail in the next section. To understand the framework of recovery services on a macro level, we will skip this step first, assuming the installation is complete. Let's go down and see how recovery ends the service and restarts to the new master System after the installation is complete.

5. if (Wipe_data/wipe_cache): This step to determine the actual two-step, in the source code is to determine whether to erase the data partition (user part), and then determine whether to erase the cache partition. It is important to note that the cache partition must be erased in addition to the data partition. The data partition can be erased without erasing the cache partition only.

6. Maybe_install_firmware_update (): This function is called if the upgrade package contains updates for/radio/hboot firmware. View source discovery, in the comments (OTA INSTALL) has this process. But the main function does not show the call to this function. It is not yet found where to deal with it. But the process is still the same as the diagram above. That is, ① first writes "Boot-recovery" and "-wipe_cache" to BCB and then formats the cache partition and writes firmware image to the original cache partition. ② writes the command "Update-radio/hboot" and "-wipe_cache" to BCB, and then begins reinstalling firmware and refreshing firmware. ③ will then enter the end of the diagram, i.e. finish_recovery ().

7. Prompt_and_wait (): This function is called in a judgment. The implication is that if the installation fails (Update.zip packet errors or verification signatures fail), the user's input processing is awaited (e.g., by combining key reboot, etc.).

8. Finish_recovery (): This is the only way for recovery to close and enter the main system. The general flow is as follows:

① the contents of the intent (string) as arguments into the finish_recovery. If a intent needs to tell the main System, it is written to/cache/recovery/intent. The role of this intent is not yet known.

② copies the log (/tmp/recovery.log) of the recovery service in the memory file system to the cache (/cache/recovery/log) partition to tell what happened to the main system after the restart.

③ erases the contents of the BCB data block in the misc partition so that the system does not enter recovery mode after a reboot, but instead enters the updated primary system.

④ Delete the/cache/recovery/command file. This step is also important, because bootloader will automatically retrieve this file after reboot, and will enter recovery mode if it is not deleted. The principle is very clear on the above.

9. Reboot (): This is a system call. In this step recovery completes its service reboot and enters main System. This restart is the same as the function that restarts into the recovery mode call in the main system, but the direction is not the same. So the parameters are not the same. View source discovery, its restart mode is rb_autoboot. This is a system macro.

At this point, we have a general understanding of the entire process framework for recovery services. The following is the second phase of the recovery service that is unique to upgrading the Update.zip package and the core of the installation upgrade package. That is the branch of the Red 2 in our legend.

We will explain this part in the next article, namely the core part of the recovery service install_package function

Android System Recovery Working principle use Update.zip upgrade process analysis (vi)---Recovery service flow details "Go"