标签：develop 生成 nal dia too 连接 mac detail 版本
本文转载自：http://blog.csdn.net/u012719256/article/details/52304273
BOOT： boot.img，Linux kernel (within normal ramdisk)
MISC： bootloader message struct
RECOVERY： recovery.img，Linux kernel (within recovery ramdisk)
SYSTEM： system.img
DATA： userdata.img
CACHE： some cache files
Recovery的工作需要整个软件平台的配合，从架构角度看，有三个部分：
1) Main system：用boot.img启动的Linux系统，Android的正常工作模式。
2) Recovery：用recovery.img启动的Linux系统，主要是运行Recovery程序。
3) Bootloader：除了加载、启动系统，还会通过读取flash的MISC分区获得来自Main system和Recovery的消息，并以此决定做何种操作。
在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的信息
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，要修改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
根据Recovery的initrc，kernel启动完成后，启动recovery服务，这是一个C程序，入口在/bootable/recovery/recovery.c中，main函数结构清晰，主要流程如图：
首先调用get_args获取参数，主要流程如下：
get_args不仅传回获取到的参数，还会将其写入misc分区中的BCB，这样，一旦升级或擦除数据的过程中出现错误，重启之后依然进入Recovery并做相同操作。
或install_rkimage
或wipe_data
或wipe_cache
离开Recovery进入Main system的必经之路，流程如下：
• intent内容作为参数传进来，如果有intent需要告知Main system，将其写入/cache/recovery/intent；
• 将所有log信息转储到/cache/recovery/log文件，以供Main system读取；
• 清除BCB，也就是告知Bootloader启动进入Main system；
• 删除/cache/recovery/command；
以上是整体流程中的几个函数，关于安装升级包、升级firmware等操作将在具体流程中介绍。
如果系统不稳定，可以尝试恢复出厂设置，该操作会擦除DATA分区及CACHE分区，有两种恢复方式，下面分别介绍：
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
过程比较简单，而且与上一种方式类似，结合总体流程，步骤如下：
1) 捕获按键Alt + W。
2) 擦除DATA分区、擦除CACHE分区。
3a) 若激活了log显示（ALT+L：toggle log text display），调用finish_recovery函数重启，回到Main system。
3b) 若没有激活log显示，继续接收按键，可用HOME+BACK重启回到Main system。
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/，这里就不再详细介绍。
通过Android系统下载升级包并启动升级操作，需要上层应用Updater的支持，它是Java程序，代码位置android/packages/apps/Updater。大致流程：
• 系统启动后，如果存在网络连接，则检查是否存在升级包；
• 如果存在升级包，则下载至/cache目录；
• 调用Updater程序来提示是否升级；
• 如果Updater程序进程不存在,则自动启动此程序；
• 没有在代码中找到开始升级后执行哪些操作。不过由recovery.c的注释部分可以肯定一定需要重启进入Recovery，重启前要更新/cache/recovery/command，以告知Recovery进行升级：
–update_package=root:path
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脚本并执行脚本中的命令)开始升级：
每次启动，Bootloader都会读取位于misc分区的bootloader_message，并检查command区域以\0结尾，还要考虑flash存在坏块的情况。然后根据读取的命令，启动系统或者更新firmware。工作流程如下：
升级之后，无论升级成功是否，Bootloader都会进入recovery完成最后的收尾工作，并带着status以告知是否成功。如果更新hboot（尚不知道为什么叫这个名字，不过可以确定它就是bootloader firmware），一旦失败，若原有的bootloader遭到破坏，那么系统将不能boot。
转自：http://www.codingguy.net/?p=49
Bootloader - main system - Recovery的三角关系【转】
标签：develop 生成 nal dia too 连接 mac detail 版本
原文地址：http://www.cnblogs.com/zzb-Dream-90Time/p/7668291.html
