Android Recovery系统分析5----Recovery升级流程

1. ui_init()：Recovery服务使用了一个基于framebuffer的简单ui（miniui）系统。这个函数对其进行了简单的初始化。在Recovery服务的过程中主要用于显示一个背景图片（正在安装或安装失败）和一个进度条（用于显示进度）。另外还启动了两个线程，一个用于处理进度条的显示（progress_thread），另一个用于响应用户的按键（input_thread）。

2. get_arg()：这个函数主要做了上图中get_arg()往右往下直到parse arg/v的工作。

• get_bootloader_message()：主要工作是根据分区的文件格式类型（mtd或emmc）从MISC分区中读取BCB数据块到一个临时的变量中。
• 然后开始判断Recovery服务是否有带命令行的参数（/sbin/recovery，根据现有的逻辑是没有的），若没有就从BCB中读取recovery域。如果读取失败则从/cache/recovery/command中读取然后。这样这个BCB的临时变量中的recovery域就被更新了。在将这个BCB的临时变量写回真实的BCB之前，又更新的这个BCB临时变量的command域为“boot-recovery”。这样做的目的是如果在升级失败（比如升级还未结束就断电了）时，系统在重启之后还会进入Recovery模式，直到升级完成。
• 在这个BCB临时变量的各个域都更新完成后使用set_bootloader_message()写回到真正的BCB块中。

3. 解析获得的参数，后面会根据解析的值进行响应的操作。

4. 判断是否擦除data、cache分区。

5. 判断是否需要更新升级包，如果需要就升级更新包，此时会调用install_package()。这一步中完成升级包的安装，是升级过程中最复杂，也是最核心的部分，在下一部分单独分析。

6. finish_recovery：这是Recovery关闭并进入Main System的必经之路。其大体流程如下：

• 将intent（字符串）的内容作为参数传进finish_recovery中。如果有intent需要告知Main System，则将其写入/cache/recovery/intent中。这个intent的作用尚不知有何用。
• 将内存文件系统中的Recovery服务的日志（/tmp/recovery.log）拷贝到cache（/cache/recovery/log）分区中，以便告知重启后的Main System发生过什么。
• 擦除MISC分区中的BCB数据块的内容，以便系统重启后不在进入Recovery模式而是进入更新后的主系统。
• 删除/cache/recovery/command文件。这一步也是很重要的，因为重启后Bootloader会自动检索这个文件，如果未删除的话又会进入Recovery模式。

7. Android_reboot：这一步完成服务重启并进入主系统。