Recovery学习笔记

来源：互联网发布：js window.url 编辑：程序博客网时间：2024/05/22 02:12

1.Main System与Recovery模式联系

http://blog.csdn.net/mu0206mu/article/details/7464987。

1.1 MIS分区

MISC分区，占用三个page，其本身就是一个结构体，具体成员以及各成员含义如下：

struct bootloader_message{

char command[32];

char status[32];

char recovery[1024];

};

①command成员：其可能的取值我们在上文已经分析过了，即当我们想要在重启进入Recovery模式时，会更新这个成员的值。另外在成功更新后结束Recovery时，会清除这个成员的值，防止重启时再次进入Recovery模式。

A.command=="boot-recovery"时，系统会进入Recovery模式。Recovery服务会具体根据/cache/recovery/command中的命令执行相应的操作（例如，升级 update.zip或擦除cache，data等）。
B.command=="update-radia"或"update-hboot"时，系统会进入更新firmware（更新bootloader），具体由bootloader完成。
C.command为空时，即没有任何命令，系统会进入正常的启动，最后进入主系统（main system）。这种是最通常的启动流程。

②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模式。

1.2 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的信息。作用不详。

2.启动

Android手机启动的模式：充电模式，正常模式，recovery模式，recvoery模式，工厂模式等，关于recovery启动部分，不同的平台启动的方式不太一样，一般放在\bootable\bootloader目录下。不同的平台，拥有不同的BootLoader的启动方式。http://blog.csdn.net/kylin_fire_zeng/article/details/42082391解析其中一种正常启动的流程。

下面介绍其中一种BootLoader启动LK (http://blog.csdn.net/jmq_0000/article/details/7378348,http://www.cnblogs.com/xiaolei-kaiyuan/p/5458145.html),在./lk/app/aboot.c中，aboot_init()函数检查和启动recovery( ptn = ptable_find(ptable, "recovery");)。

1)按键启动。

2)检查地址的数值启动。

3)读取misc分区的数值。

2.Recovey流程

2.1 ramdisk介绍

这里的内容来源于http://www.cnblogs.com/xiaolei-kaiyuan/p/5454074.html。

　　ramdisk通过直面意思就大概能理解意思，ram disk虚拟内存盘，将ram模拟成硬盘来使用的文件系统。对于传统的磁盘文件系统来说，这样做的好处是可以极大提高文件访问速度；但由于是ram，所以在掉电后，这部分内容不能保存。ramdisk文件系统是在系统上电后直接从磁盘一次性加载到内存，在整个运行期间都不会有写回操作，所以，任何修改都掉电后丢失。

2.1.1 ramdisk.img介绍

　　ramdisk.img是android打包生成的，解压ramdisk.img后对比root根目录很相似，所以ramdisk是虚拟文件系统。这里主要讲解如何解压ramdisk.img。

file ramdisk.img--ramdisk.gz: gzip compressed data, from Unix   -----可知ramdisk.img是gz的文件mv ramdisk.img ramdisk.gz-----更改后缀名gunzip ramdisk.gz-----解压，会生成ramdisk文件file ramdisk--ramdisk: ASCII cpio archive (SVR4 with no CRC)cpio -i -F ramdisk

2.1.2、ramdisk、boot.img、recovery.img之间的关系

　　ramdisk.img会被打包到boot.img和recovery.img中（不是同一个ramdisk.img）.

　　ramdisk.img中比较重要的文件是"init","init.rc"，其中init是system/core/init/init.c编译而来，boot.img中ramdisk里的init.rc位于system/core/init/init.rc,而recovery.img中ramdisk里的init.rc位于bootable/recovery/etc/init.rc。

　　kernel加载结束以后第一个进程是执行init，init会解析init.rc文件，并起相应的服务。由此可以知道正常开机和进入recovery模式起的进程是不同的。

　　下面的代码位于bootable/recovery/etc/init.rc，由此可知，进入recovery模式后会执行sbin/recovery，此文件是bootable/recovery/recovery.cpp生成（可查看对应目录的Android.mk查看）。

service recovery /sbin/recovery    seclabel u:r:recovery:s0

2.2 Rcovery流程

下面正式进入 recovery service 进行升级或者恢复工程初始化的工作了。来源于http://blog.csdn.net/mu0206mu/article/details/7465514下面是关于

1.recovery的流程图

2.升级的过程的流程。

这里里面还有很多可以写的点。有机会再补充吧

阅读全文

0 0