Android 系统Recovery工作原理

Android 系统Recovery工作原理

 

Android系统Recovery模式的工作原理

 

在使用update.zip包升级时怎样从主系统（main system）重启进入Recovery模式，进入Recovery模式后怎样判断做何种操作，以及怎样获得主系统发送给Recovery服务的命令，这一系列问题的解决是通过整个软件平台的不同部分之间的密切通信配合来完成的。为此，我们必须要了解Recovery模式的工作原理，这样才能知道我们的update.zip包是怎样一步步进入Recovery中升级并最后到达主系统的。

 

一、   Recovery模式中的三个部分

 

Recovery的工作需要整个软件平台的配合，从通信架构上来看，主要有三个部分。

   ①MainSystem：即上面提到的正常启动模式（BCB中无命令），是用boot.img启动的系统，Android的正常工作模式。更新时，在这种模式中我们的上层操作就是使用OTA或者从SD卡中升级update.zip包。在重启进入Recovery模式之前，会向BCB中写入命令，以便在重启后告诉bootloader进入Recovery模式。

   ②Recovery：系统进入Recovery模式后会装载Recovery分区，该分区包含recovery.img（同boot.img相同，包含了标准的内核和根文件系统）。进入该模式后主要是运行Recovery服务（/sbin/recovery）来做相应的操作（重启、升级update.zip、擦除cache分区等）。

③Bootloader：除了正常的加载启动系统之外，还会通过读取MISC分区（BCB）获得来至Mainsystem和Recovery的消息。

 

二、   Recovery模式中的两个通信接口

 

在Recovery服务中上述的三个实体之间的通信是必不可少的，他们相互之间又有以下两个通信接口。

   (一)通过CACHE分区中的三个文件：

       Recovery通过/cache/recovery/目录下的三个文件与mian system通信。具体如下             

      ①/cache/recovery/command：这个文件保存着Main system传给Recovery的命令行，每一行就是一条命令，支持以下几种的组合。

         --send_intent=anystring  

//write the text out to recovery/intent    

在Recovery结束时在finish_recovery函数中将定义的intent字符串作为参数传进来，并写入到/cache/recovery/intent中

        --update_package=root:path 

//verify install an OTA package file     

Main system将这条命令写入时,代表系统需要升级，在进入Recovery模式后，将该文件中的命令读取并写入BCB中，然后进行相应的更新update.zip包的操作。

        --wipe_data   

//erase user data(and cache),then reboot。

擦除用户数据。擦除data分区时必须要擦除cache分区。

        --wipe_cache 

//wipe cache(but not user data),then reboot。

擦除cache分区。

 

②/cache/recovery/log：Recovery模式在工作中的log打印。在recovery服务运行过程中，stdout以及stderr会重定位到/tmp/recovery.log在recovery退出之前会将其转存到/cache/recovery/log中，供查看。

③/cache/recovery/intent：Recovery传递给Main system的信息。作用不详。

 

(二)通过BCB（BootloaderControl Block）：

BCB是bootloader与Recovery的通信接口，也是Bootloader与Main system之间的通信接口。存储在flash中的MISC分区，占用三个page，其本身就是一个结构体，具体成员以及各成员含义如下：

structbootloader_message{

charcommand[32];

charstatus[32];

charrecovery[1024];

};

  ①command成员：当我们想要在重启进入Recovery模式时，会更新这个成员的值。另外在成功更新后结束Recovery时，会清除这个成员的值，防止重启时再次进入Recovery模式。

  ②status：在完成相应的更新后，Bootloader会将执行结果写入到这个字段。

  ③recovery：可被Main System写入，也可被Recovery服务程序写入。该文件的内容格式为：

“recovery\n

<recovery command>\n

<recovery command>”

该文件存储的就是一个字符串，必须以recovery\n开头，否则这个字段的所有内容域会被忽略。“recovery\n”之后的部分，是/cache/recovery/command支持的命令。可以将其理解为Recovery操作过程中对命令操作的备份。Recovery对其操作的过程为：先读取BCB然后读取/cache/recovery/command，然后将二者重新写回BCB，这样在进入Main system之前，确保操作被执行。在操作之后进入Main system之前，Recovery又会清空BCB的command域和recovery域，这样确保重启后不再进入Recovery模式。

 

三、   如何从MainSystem重启并进入Recovery模式

 

我们先看一下以上三个部分是怎样进行通信的，先看下图：

                      

我们只看从Main System如何进入Recovery模式，其他的通信在后文中详述。先从Main System开始看，当我们在Main System使用update.zip包进行升级时，系统会重启并进入Recovery模式。在系统重启之前，我们可以看到，Main System定会向BCB中的command域写入boot-recovery(粉红色线)，用来告知Bootloader重启后进入recovery模式。这一步是必须的。至于Main System是否向recovery域写入值我们在源码中不能肯定这一点。即便如此，重启进入Recovery模式后Bootloader会从/cache/recovery/command中读取值并放入到BCB的recovery域。而Main System在重启之前肯定会向/cache/recovery/command中写入Recovery将要进行的操作命令。

至此，我们就大概知道了，在上层使用update.zip升级时，主系统是怎样告知重启后的系统进入Recovery模式的，以及在Recovery模式中完成什么样的操作。

 

Recovery服务流程细节

 

Recovery服务毫无疑问是Recovery启动模式中最核心的部分。它完成Recovery模式所有的工作。Recovery程序对应的源码文件位于：

/bootable/recovery/recovery.cpp。

 

一、 Recovery的三类服务：

先看一下在这个源码文件中开始部分的一大段注释，这将对我们理解Recovery服务的主要功能有很大帮助。

从注释中我们可以看到Recovery的服务内容主要有三类：

    ①FACTORY RESET，恢复出厂设置。

    ②OTA INSTALL，即我们的update.zip包升级。

③ENCRYPTED FILE SYSTEM ENABLE/DISABLE，使能/关闭加密文件系统。

具体的每一类服务的大概工作流程，注释中都有，我们在下文中会详细讲解OTA INSTALL的工作流程。这三类服务的大概的流程都是通用的，只是不同操作体现与不同的操作细节。下面我们看Recovery服务的通用流程。

 

二．   Recovery服务的通用流程：

 

    在这里我们以OTA INSTALL的流程为例具体分析。并从相关函数的调用过程图开始，如下图:

          

我们顺着流程图分析，从recovery.c的main函数开始：

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.parserargc/argv：解析我们获得参数。注册所解析的命令（register_update_command），在下面的操作中会根据这一步解析的值进行一步步的判断，然后进行相应的操作。

4.if(update_package)：判断update_package是否有值，若有就表示需要升级更新包，此时就会调用install_package()（即图中红色的第二个阶段）。在这一步中将要完成安装实际的升级包。这是最为复杂，也是升级update.zip包最为核心的部分。我们在下一节详细分析这一过程。为从宏观上理解Recovery服务的框架，我们将这一步先略过，假设已经安装完成了。我们接着往下走，看安装完成后Recovery怎样一步步结束服务，并重启到新的主系统的。

5.if(wipe_data/wipe_cache)：这一步判断实际是两步，在源码中是先判断是否擦除data分区（用户数据部分）的，然后再判断是否擦除cache分区。值得注意的是在擦除data分区的时候必须连带擦除cache分区。在只擦除cache分区的情形下可以不擦除data分区。

6.maybe_install_firmware_update()：如果升级包中包含/radio/hboot firmware的更新，则会调用这个函数。查看源码发现，在注释中（OTA INSTALL）有这一个流程。但是main函数中并没有显示调用这个函数。目前尚未发现到底是在什么地方处理。但是其流程还是向上面的图示一样。即，① 先向BCB中写入“boot-recovery”和“—wipe_cache”之后将cache分区格式化，然后将firmware image 写入原始的cache分区中。②将命令“update-radio/hboot”和“—wipe_cache”写入BCB中，然后开始重新安装firmware并刷新firmware。③之后又会进入图示中的末尾，即finish_recovery()。

7.prompt_and_wait()：这个函数是在一个判断中被调用的。其意义是如果安装失败（update.zip包错误或验证签名失败），则等待用户的输入处理（如通过组合键reboot等）。

8.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模式。原理在上面已经讲的很清楚了。

 

9.reboot()：这是一个系统调用。在这一步Recovery完成其服务重启并进入Main System。这次重启和在主系统中重启进入Recovery模式调用的函数是一样的，但是其方向是不一样的。所以参数也就不一样。查看源码发现，其重启模式是RB_AUTOBOOT。这是一个系统的宏。

 

至此，我们对Recovery服务的整个流程框架已有了大概的认识。下面就是升级update.zip包时特有的也是Recovery服务中关于安装升级包最核心的第二个阶段。即我们图例中的红色2的那个分支。