分类： Android平台
2014-04-02 15:06:35
原文地址：Android系统Recovery流程 作者：DennisBjut
二、 三个部分、两个接口
Recovery的工作需要整个软件平台的配合，从架构角度看，有三个部分：
1) Main system：用boot.img启动的Linux系统，Android的正常工作模式。
2) Recovery：用recovery.img启动的Linux系统，主要是运行Recovery程序。
3) Bootloader：除了加载、启动系统，还会通过读取flash的MISC分区获得来自Main system和Recovery的消息，并以此决定做何种操作。
在Recovery的工作流程中，上述三个实体的通信必不可少。通信的接口有以下两个：
1. 接口1: CACHE分区中的三个文件：/cache/recovery/…
Recovery通过/cache/recovery里的文件与main system通信，有三个文件：
1) /cache/recovery/command (Main System-->Recovery)
Main system传给Recovery的命令行，每一行有一个命令，支持以下几种：
--send_intent=anystring - write the text out to recovery.intent
--update_package=path - verify install an OTA package file
--wipe_data - erase user data (and cache), then reboot
--wipe_cache - wipe cache (but not user data), then reboot
--set_encrypted_filesystem=on|off - enables / diasables encrypted fs
2) /cache/recovery/log(Recovery写的log文件)
Recovery的log输出，在recovery运行过程中，stdout及stderr会重定位到/tmp/recovery.log文件，Recovery退出之前会将其转储到/cache/recovery/log中，也就是cache分区的recovery/log。
3) /cache/recovery/intent(Recovery-->Main system)
Recovery传给Main system的信息
2. 接口2: BCB (bootloader control block)即bootloader_message
BCB是Bootloader与Recovery的通信接口，也是Bootloader与Main system的通信接口，存储在flash中的MISC分区，占用三个page，各成员意义如下：
? command：
当Main system(Linux)想要重启进入recovery模式，或升级radio/bootloader firmware时，会更新这个域。当firmware更新完毕，为了启动后进入recovery做最终的清除，bootloader还会修改它。
?status：
update-radio或update-hboot完成后，bootloader会写入相应的信息，一般是一些状态或执行结果。
? recovery：
仅被Main system(Linux)写入，用于向Recovery发送消息，必须以“recovery\n”开头，否则这个域的所有内容会被忽略。这一项的内容中“recovery/\n”以后的部分，是/cache/recovery/command支持的命令，可以认为这是在Recovery操作过程中，对命令操作的备份。Recovery也会更新这个域的信息，执行某操作前把该操作命令写到recovery域，并更新command域，操作完成后再清空recovery域及command域，这样在进入Main system之前，就能确保操作被执行。
如下图所示，Main system、Recovery与Bootloader通过上述接口通信，通信逻辑依不同的目的而不同，在后面介绍具体工作流程中还会详细介绍。
三、从Main system进入Recovery的方法
从Main system进入到Recovery，要修改misc分区的数据并重启，从而告诉Bootloader是用boot.img还是用recovery.img启动。
/system/core/init/signal_handler.c里的wait_for_one_process函数中有如下代码：
android_reboot(ANDROID_RB_RESTART2, 0, "recovery")->
__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, “recovery”);
一些关键的进程运行异常，会重启进入recovery模式，这里用__reboot函数进入recovery。跟踪这个函数，由系统调用处理函数，到kernel_restart(char *cmd)，最终调用machine_restart使用体系结构相关的代码完成重启。
Android中没有给出如何处理“recovery”重启。不过可以断定，在重启之前会向BCB中写入信息，以告知bootloader如何启动，具体操作是这样的：
? 向command域中写入“boot-recovery” // 此操作必做
? 向recovery域写入“recovery\n” // 此操作也可不做
这些操作很可能在kernel_restart(char *cmd)中完成，因为这一部分与体系结构无关，如果要实现完整的Recovery，这部分工作是必须做的。
Bootloader得到进入Recovery模式的指示，用recovery.img启动，进入Recovery模式，init.rc (bootable/recovery/etc/init.rc)的内容比Main system的要短的多，最重要的是把recovery程序作为服务启动：
service recovery /sbin/recovery
四、Android Recovery: 总体流程
根据Recovery的initrc，kernel启动完成后，启动recovery服务，这是一个C程序，入口在/bootable/recovery/recovery.c中，main函数结构清晰，主要流程如图：
1. get_args
首先调用get_args获取参数，主要流程如下：
get_args不仅传回获取到的参数，还会将其写入misc分区中的BCB，这样，一旦升级或擦除数据的过程中出现错误，重启之后依然进入Recovery并做相同操作。
2. install_package
或install_rkimage
或wipe_data
或wipe_cache
3. finish_recovery
离开Recovery进入Main system的必经之路，流程如下：
? intent内容作为参数传进来，如果有intent需要告知Main system，将其写入/cache/recovery/intent；
? 将所有log信息转储到/cache/recovery/log文件，以供Main system读取；
? 清除BCB，也就是告知Bootloader启动进入Main system；
? 删除/cache/recovery/command；
以上是整体流程中的几个函数，关于安装升级包、升级firmware等操作将在具体流程中介绍。
五、Android Recovery: Factory data reset流程
如果系统不稳定，可以尝试恢复出厂设置，该操作会擦除DATA分区及CACHE分区，有两种恢复方式，下面分别介绍：
1. 通过Setting程序发起Facory data reset
1) 在应用程序Setting中选择factory data reset
2) Main system向/cache/recovery/command写入”–wipe_data”
3) Main system重启进入recovery模式（方法：修改BCB）
4) Recovery向BCB写入”boot-recevory”和”recovery\n–wipe_data\n”
5) 擦除DATA分区，里面是用户数据，擦除CACHE分区
6) finish_recovery函数
7) 重启，回到Main system
第4) 步骤，Recovery向BCB写入boot-recovery和–wipe_data，这是为了保证后面几个步骤的完整执行。如，在擦除DATA分区或CACHE分区过程中，如果发生了重启、关机等操作，导致没有擦除成功，那么再次用常规方式开机后，Bootloader会依据misc分区中BCB的指示，引导进入Recovery，并重新擦除这两个分区。擦完DATA分区与CACHE分区后，调用finish_recovery，做返回Main system前最后的工作，最终要的是擦除BCB，即MISC分区。此后，用常规方式重新开机，系统会进入Main system。
阅读Android的代码，发现Setting通过RPC调用Checkin Service的masterClear()启动这个过程，然而在Android中并没有找到masterClear()的实现，相关代码需要在产品化的过程中加入。从ICheckinService.aidl的注释可以了解到这个函数的作用：
/** Reboot into the recovery system and wipe all user data. */
代码位置：
/packages/apps/Settings/src/com/android/settings/MasterClear.java
/frameworks/base/core/java/android/os/ICheckinService.aidl
2. 通过HOME+POWER组合键进入Recovery，再按ALT+W启动Factory data reset
过程比较简单，而且与上一种方式类似，结合总体流程，步骤如下：
1) 捕获按键Alt + W。
2) 擦除DATA分区、擦除CACHE分区。
3a) 若激活了log显示（ALT+L：toggle log text display），调用finish_recovery函数重启，回到Main system。
3b) 若没有激活log显示，继续接收按键，可用HOME+BACK重启回到Main system。
六、Android Recovery: Update流程
1. update.zip
update操作需要升级包，该升级包是文件名是*.zip，但观察包内结构会发现其实就是JAR包，JAR包是具有特定目录和文件结构的ZIP压缩包，因此可以作为ZIP包解开。
? MANIFEST.MF：这个manifest文件定义了与包相关数据。
? XXX.SF：这是JAR文件的签名文件，占位符xxx标识签名者，如CERT。
? XXX.DSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。
? 在META-INF/com/google/android目录下有updater-script文件，内容就是update要做的操作，也就是前面提到过的command序列。
出于安全性及版本控制的考虑，JAR包要求必须有完整性以及合法性签名。可以看出这是Android确保安全的策略。JAR相关内容参见http://www.ibm.com/developerworks/cn/java/j-jar/，这里就不再详细介绍。
2. Main system部分
通过Android系统下载升级包并启动升级操作，需要上层应用Updater的支持，它是Java程序，代码位置android/packages/apps/Updater。大致流程：
? 系统启动后，如果存在网络连接，则检查是否存在升级包；
? 如果存在升级包，则下载至/cache目录；
? 调用Updater程序来提示是否升级；
? 如果Updater程序进程不存在,则自动启动此程序；
? 没有在代码中找到开始升级后执行哪些操作。不过由recovery.c的注释部分可以肯定一定需要重启进入Recovery，重启前要更新/cache/recovery/command，以告知Recovery进行升级：
–update_package=root:path
3. update流程
update有两种方式，第一种是上面提到的由Android启动的自动update过程，升级包在cache/下，升级包的名字在/cache/recovery/command文件中指定。第二种是手动进入Recovery模式，然后输入Alt + S，安装/sdcard/update.zip升级包。两种方式不同的只是安装包的位置以及传递参数给Recovery的方法，update过程都是一样的，工作流程如下图所示：
1) install_package @ android/bootable/recovery/install.c
得到安装包信息，如“–update_package=CACHE:update.zip”，进入install_package函数，流程如下左图。mount安装包所在的分区，然后打开zip压缩包，进入handle_update_package(Android4.0: try_update_binary，它从zip包中提取并运行update-binary程序，update-binary由/bootable/recovery/updater/updater.c编译生成，update-binary负责解释updater-script脚本并执行脚本中的命令)开始升级：
4. Bootloader
每次启动，Bootloader都会读取位于misc分区的bootloader_message，并检查command区域以\0结尾，还要考虑flash存在坏块的情况。然后根据读取的命令，启动系统或者更新firmware。工作流程如下：
升级之后，无论升级成功是否，Bootloader都会进入recovery完成最后的收尾工作，并带着status以告知是否成功。如果更新hboot（尚不知道为什么叫这个名字，不过可以确定它就是bootloader firmware），一旦失败，若原有的bootloader遭到破坏，那么系统将不能boot
参考资料：
http://blog.csdn.net/mu0206mu/article/details/7465352
frameworks/base/services/java/com/android/server/MasterClearReceiver.java
frameworks/base/core/java/android/os/RecoverySystem.java
bootable/recovery/*
