Android recovery流程解析

最新推荐文章于 2024-12-23 09:12:03 发布

conceptcon

最新推荐文章于 2024-12-23 09:12:03 发布

阅读量1.4k

点赞数

分类专栏： android

android 专栏收录该内容

76 篇文章

订阅专栏

Android recovery流程解析

From:http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=3609528

恢复出厂设置流程概括：

一. 设置模块中进行恢复出厂设置操作，系统一共做了两件事：

1. 往 /cache/recovery/command 文件中写入命令字段：

2. 重启系统

二. 重启系统会必须进入 recovery 模式

进入 recovery 模式的几种方式

1. 通过读取 /cache 分区中文件 /cache/recovery/command 内容进入

2. 通过按键操作进入（G1 通过同时按 HOME 和挂断键）

以上两种方式进入都需要 blob的支持

三. 所以恢复出厂设置，进入 recovery 模式，必须做以下几件事情：

1. blob 必须能从 recovery 分区中装载内核和文件系统

2. flash 必须有 cache 分区和 recovery 分区

3. 必须编译提供 recovery.img 烧录到 recovery 分区

recovery.img 解析：

1. 理解 recovery.img

在制作 recovery 镜像之前，我们必须理解什么是 recovery 以及它有哪些内容，这里省略，文章：

<<recovery.img与boot.img简单对比分析>> 对 recovery 做了很好的解释，地址：

http://www.hiapk.com/bbs/thread-6391-1-1.html

2. 制作 recovery.img

因为在文件： ./vendor/marvell/littleton/BoardConfig.mk 中有：

TARGET_NO_KERNEL := true

导致我们目前在编译 cupcake 的时候，默认没有生成 recovery.img，

要生成 recovery.img 必须屏蔽 TARGET_NO_KERNEL := true

创建目录： vendor/marvell/littleton/recovery/res

拷贝编译好的内核到目录：vendor/marvell/littleton

cp /tftpboot/zImage20100202 vendor/marvell/littleton/kernel

如果不创建res目录和拷贝内核将会出现以下错误：

No private recovery resources for TARGET_DEVICE littleton

make: *** 没有规则可以创建“out/target/product/littleton/kernel”需要的目标“vendor/marvell/littleton/kernel”

命令: make recoveryimage 单独生成 recovery.img

out/host/linux-x86/bin/mkbootimg --kernel out/target/product/littleton/kernel //
--ramdisk out/target/product/littleton/ramdisk-recovery.img //
--output out/target/product/littleton/recovery.img

复制代码

恢复出厂设置，内核相关部分：

2009年 12 月23 日falsh 分区情况

0x00000000-0x00100000 : /"Bootloader/"                --1M

0x00100000-0x00500000 : /"Kernel/"                   --4M  0x400000

0x00500000-0x06500000 : /"system/"                   --96M 0x6000000

0x06500000-0x09500000 : /"userdata/"                --48M 0x3000000

0x09500000-0x0f500000 : /"systembackup/"             --96M

0x0f500000-0x0fd00000 : /"massstorage/"             --8M

0x0fd00000-0x0ff00000 : /"massstorage2/"             --2M

0x0ff00000-0x10000000 : /"massstorage3/"             --1M

在目前的内核中我们还没有使用 cache 分区和 recovery 分区，所以修改内核配置文件：

arch/arm/mach-pxa/include/mach/part_table.h

把以下分区：

0x09500000-0x0f500000 : /"systembackup/"             --96M

0x0f500000-0x0fd00000 : /"massstorage/"             --8M

改为：

0x09500000-0x0f500000 : /"cache/"                   --96M

0x0f500000-0x0fd00000 : /"recovery/"                --8M

让 android 系统能正常挂载和使用 cache  recovery 分区。

烧写编译好的 recovery.img 到 recovery 分区；

烧写地址已经更新，具体参考文件：

http://192.168.2.148/smartphone/td0901/release/images/readme.txt

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

烧写 cache 分区

nanderase -z 0x09500000 0x6000000
tftp recovery.img
nandwrite -y 0x80800000 0x09500000 <cache.img actual length>

复制代码

烧写 recovery 分区

nanderase -z 0xf500000 0x800000
tftp recovery.img
nandwrite -y 0x80800000 0xf500000 <recovery.img actual length>

复制代码

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

恢复模式流程分析

完成了以上准备工作，当我们按特定的组合键或者恢复出厂设置，那么就会进入 recovery 模式：

从 recovery 模式的 init.rc 文件可以看出，它仅仅启动了几个服务

service recovery /sbin/recovery

service adbd /sbin/adbd recovery

以下是 recovery 流程分析，主函数在文件：

bootable/recovery/recovery.c

int main(int argc, char **argv)
...
ui_init(); //初始化ui
get_args(&argc, &argv);
...
void ui_init(void)[code]{
gr_init();
ev_init();
...
pthread_create(&t, NULL, progress_thread, NULL);
pthread_create(&t, NULL, input_thread, NULL);
}

复制代码

recovery 模式有简单的交互式界面，它是通过 ui_init(),ev_init()等一些列操作，

完成字符ui界面和按键事件等初始化。input_thread 线程里面处理按键事件。

函数 get_args 会读取 /cache/recovery/command 文件，并根据命令字段进行相应操作，

因为进行恢复出厂设置的时候 /cache/recovery/command 的内容为 --wipe-data

所以它会擦除 data 和 cache 分区：

erase_root(/"DATA:/"

erase_root(/"CACHE:/"

分区擦除后，系统重启，然后进入正常开机流程，重新使用 system 分区的内容完成开机初始化，此过程

跟我们第一次烧写软件过程一致。

如果是按 home 键和挂机键开机，那么进入字符选择界面，函数为：

static void prompt_and_wait()
{
char** headers = prepend_title(MENU_HEADERS);
for (;;) {
finish_recovery(NULL);
ui_reset_progress();
int chosen_item = get_menu_selection(headers, MENU_ITEMS, 0);
// device-specific code may take some action here. It may
// return one of the core actions handled in the switch
// statement below.
chosen_item = device_perform_action(chosen_item);
switch (chosen_item) {
case ITEM_REBOOT:
//系统重启
return;
case ITEM_WIPE_DATA:
//擦除数据分区
break;
case ITEM_WIPE_CACHE:
//擦除 cache 分区
break;
case ITEM_APPLY_SDCARD:
//通过防止 update.zip 包到 sdcard 根目录实现系统升级
break;
}
}
}

复制代码

[/code]

property_get/property_set

每个属性都有一个名称和值，他们都是字符串格式。属性被大量使用在Android系统中，用来记录系统设置或进程之间的信息交换。属性是在整个系统中全局可见的。每个进程可以get/set属性。

在系统初始化时，Android将分配一个共享内存区来存储的属性。这些是由“init”守护进程完成的，其源代码位于：device/system/init。“init”守护进程将启动一个属性服务。

属性服务在“init”守护进程中运行。每一个客户端想要设置属性时，必须连接属性服务，再向其发送信息。属性服务将会在共享内存区中修改和创建属性。任何客户端想获得属性信息，可以从共享内存直接读取。这提高了读取性能。客户端应用程序可以调用libcutils中的API函数以GET/SET属性信息。libcutils的源代码位于：device/libs/cutils。API函数是：

int property_get(const char *key, char *value, const char *default_value);

int property_set(const char *key, const char *value);

而libcutils又调用libc中的 __system_property_xxx 函数获得共享内存中的属性。libc的源代码位于：device/system/bionic。

属性服务调用libc中的__system_property_init函数来初始化属性系统的共享内存。当启动属性服务时，将从以下文件中加载默认属性：

/default.prop

/system/build.prop

/system/default.prop

/data/local.prop

属性将会以上述顺序加载。后加载的属性将覆盖原先的值。这些属性加载之后，最后加载的属性会被保持在/data/property中。

特别属性如果属性名称以“ro.”开头，那么这个属性被视为只读属性。一旦设置，属性值不能改变。

如果属性名称以“persist.”开头，当设置这个属性时，其值也将写入/data/property。

如果属性名称以“net.”开头，当设置这个属性时，“net.change”属性将会自动设置，以加入到最后修改的属性名。（这是很巧妙的。 netresolve模块的使用这个属性来追踪在net.*属性上的任何变化。）

属性“ ctrl.start ”和“ ctrl.stop ”是用来启动和停止服务。

每一项服务必须在/init.rc中定义.系统启动时，与init守护进程将解析init.rc和启动属性服务。一旦收到设置“ ctrl.start ”属性的请求，属性服务将使用该属性值作为服务名找到该服务，启动该服务。这项服务的启动结果将会放入“ init.svc.<服务名>“属性中。客户端应用程序可以轮询那个属性值，以确定结果