从demo.c看如何使用：

翻开代码，有个demo.c，操作很多，常用文件io都包括了。精简一下代码，得到一个minidemo.c:

int respipe [2];
void
want_poll (void)
{
char dummy;
printf ("want_poll ()\n");
write (respipe [1], &dummy, 1);
}

void
done_poll (void)
{
char dummy;
printf ("done_poll ()\n");
read (respipe [0], &dummy, 1);
}

int
res_cb (eio_req *req)
{
printf ("res_cb(%d|%s) = %d\n", req->type, req->data ? req->data : "?", EIO_RESULT (req));
if (req->result < 0)
abort ();
return 0;
}

void
event_loop (void)
{
// an event loop. yeah.
struct pollfd pfd;
pfd.fd     = respipe [0];
pfd.events = POLLIN;
printf ("\nentering event loop\n");
while (eio_nreqs ())
{
poll (&pfd, 1, -1);
printf ("eio_poll () = %d\n", eio_poll ());
}
printf ("leaving event loop\n");
}

int
main (void)
{
printf ("pipe ()\n");
if (pipe (respipe)) abort ();
printf ("eio_init ()\n");
if (eio_init (want_poll, done_poll)) abort ();
eio_mkdir ("eio-test-dir", 0777, 0, res_cb, "mkdir");
event_loop ();
}

这个demo很简单，大体流程如下：

• 创建pipe
• 初始化eio，注册want_poll与done_poll
• 发出异步操作：mkdir
• 启动event loop

第一次看到这段代码，往往被pipe搞迷糊，为什么创建pipe呢？先不管为什么，我们先看是怎么用的。

创建匿名管道后，fd放在respipe数组中，respipe[0]用于读pipe，respipe[1]用于写pipe。在want_poll和done_poll函数中，分别对pipe进行写和读。而want_poll与done_poll则通过eio_init注册，即，赋值到全局变量中。

接着发出异步操作，创建一个目录eio_mkdir(……)，这里的res_cb是操作完成之后的回调函数。

最后启动event loop。在这个函数中，有个大循环，eio_nreqs()表明尚未完成的请求数量，如果有未完成的请求，则poll respipe[0]，即等待可读，若可读则调用eio_poll取回结果。eio_poll的执行也会回调res_cb函数。

关于前面提到的pipe的作用，这与want_poll与done_poll机制有关。want_poll在响应队列第一次装入请求包的时候被调用；done_poll在响应队列为空的时候被调用。want_poll向pipe写入数据、done_poll从pipe读出数据，读之前通过poll来等待数据可读，若可读，就说明有want_poll调用，有异步请求被处理。接下来就可以调用eio_poll去接收结果并做回调了。这样，起到了类似锁的作用，同步了生产者消费者类型的资源访问，避免了无意义的循环空转，节约处理器cycle。

小窥源代码

看过demo，我们了解了hello world般的流程。但为了清楚eio接口函数的细节，以及异步io的实现方式，我们要继续读eio.[ch]的代码。话说eio的代码文件并不多，简单介绍一下名字：

1. ecb.h

这个头文件叫libecb（只有一个ecb.h的lib），全称为The e compiler builtins header/library。它把gcc相关的许多功能封装起来，并兼容不同的gcc版本。比如__attribute__(attrlist)这些编译器相关的属性，可以用ecb_attribute(attrlist)这个宏来写，且不用考虑编译器版本（3.1以上才支持这个玩意）。

1. eio.[ch]

就这么一对儿c文件和h文件，先不解释了

下面翻开源代码，从demo中出现的几个接口函数开始，分析一下eio的工作流程。

一切的开始：eio_init

使用eio，第一步就是调用eio_init做一堆初始化。初始化mutex、队列、各种计数器，还有注册want_poll与done_poll回调函数，这两个函数是由用户提供的。

X_MUTEX_CREATE (wrklock);
X_MUTEX_CREATE (reslock);
X_MUTEX_CREATE (reqlock);
X_COND_CREATE  (reqwait);
reqq_init (&req_queue);
reqq_init (&res_queue);
wrk_first.next =
wrk_first.prev = &wrk_first;
started  = 0;
idle     = 0;
nreqs    = 0;
nready   = 0;
npending = 0;
want_poll_cb = want_poll;
done_poll_cb = done_poll;

业务逻辑的入口：eio_xxx

初始化之后，即可调用eio的异步io函数了。我们以前面demo中创建目录为例，调用eio_mkdir(…)函数。如其他异步io函数，函数体非常简洁，但是逻辑并不简洁：

eio_req *eio_mkdir (const char *path, eio_mode_t mode, int pri, eio_cb cb, void *data)
{
REQ (EIO_MKDIR); PATH; req->int2 = (long)mode; SEND;
}

真是那各种宏啊，淡定一下，找找定义：

#define REQ(rtype)                                              \
eio_req *req;                                                 \
req = (eio_req *)calloc (1, sizeof *req);                     \
if (!req)                                                     \
return 0;                                                   \
req->type    = rtype;                                         \
req->pri     = pri;                                                    \
req->finish  = cb;                                                       \
req->data    = data;                                               \
req->destroy = eio_api_destroy;

这个宏创建了一个eio_req变量，注意是堆空间哦。然后根据rtype，也就是io操作的类型，对其赋值。那些cb等参数都不是宏里面的，从使用场景可以看出是eio _mkdir的参数。接下来是PATH，同样找到定义如下：

#define PATH                                                           \
req->flags |= EIO_FLAG_PTR1_FREE;                             \
req->ptr1 = strdup (path);                                        \
if (!req->ptr1)                                                      \
{                                                                         \
eio_api_destroy (req);                                               \
return 0;                                                               \
}

文件io操作嘛，自然要有path。接下来又填写了mode。以上这些操作都是为了构建一个eio_req变量。这个eio_req的结构定义如下：

struct eio_req
{
eio_req volatile *next; /* private ETP */
eio_ssize_t result;  /* result of syscall, e.g. result = read (... */
off_t offs;      /* read, write, truncate, readahead, sync_file_range, fallocate: file offset, mknod: dev_t */
size_t size;     /* read, write, readahead, sendfile, msync, mlock, sync_file_range, fallocate: length */
void *ptr1;      /* all applicable requests: pathname, old name; readdir: optional eio_dirents */
void *ptr2;      /* all applicable requests: new name or memory buffer; readdir: name strings */
eio_tstamp nv1;  /* utime, futime: atime; busy: sleep time */
eio_tstamp nv2;  /* utime, futime: mtime */
int type;        /* EIO_xxx constant ETP */
int int1;        /* all applicable requests: file descriptor; sendfile: output fd; open, msync, mlockall, readdir: flags */
long int2;       /* chown, fchown: uid; sendfile: input fd; open, chmod, mkdir, mknod: file mode, sync_file_range, fallocate: flags */
long int3;       /* chown, fchown: gid */
int errorno;     /* errno value on syscall return */
#if __i386 || __amd64
unsigned char cancelled;
#else
sig_atomic_t cancelled;
#endif
unsigned char flags; /* private */
signed char pri;     /* the priority */
void *data;
eio_cb finish;
void (*destroy)(eio_req *req); /* called when request no longer needed */
void (*feed)(eio_req *req);    /* only used for group requests */
EIO_REQ_MEMBERS
eio_req *grp, *grp_prev, *grp_next, *grp_first; /* private */
};

初始化了一个新的eio_req，接下只用了一个SEND完成其余工作，SEND定义很简单，只是调用了eio_submit函数：

#define SEND eio_submit (req); return req

异步IO的抽象：eio_submit

eio_submit只是etp_submit的一个封装：

void
eio_submit (eio_req *req)
{
etp_submit (req);
}

这个etp_submit几乎是所有io操作的入口，其中的关键代码如下：

X_LOCK (reqlock);
++nreqs;
++nready;
reqq_push (&req_queue, req);
X_COND_SIGNAL (reqwait);
X_UNLOCK (reqlock);
etp_maybe_start_thread ();

先做计数器累加，然后把刚刚初始化的eio_req放在req_queue，这是request队列，然后调动etp_maybe_start_thread()，在这个函数中会判断是否调用etp_start_thread()启动工作线程。判断逻辑如下：

if (ecb_expect_true (etp_nthreads () >= wanted))
return;
if (ecb_expect_true (0 <= (int)etp_nthreads () + (int)etp_npending () - (int)etp_nreqs ()))
return;

1．  先判断工作线程数量，如果已到达上限（wanted，默认是4），则直接返回，不做任何操作。

2．  如果当前的工作线程数量与已处理请求数量的和小于总的请求数量（包括完成与未完成的），则直接返回，不做任何操作

条件都满足了，接下来会调用etp_start_thread()函数，通过thread_create创建线程。

线程？！没错，就是线程：eio_proc

在etp_start_thread()中创建线程，线程函数etp_proc的代码大致如下：

for (;;)
{
for (;;)
{
self->req = req = reqq_shift (&req_queue);
if (req)
break;
}

ETP_EXECUTE (self, req);

if (!reqq_push (&res_queue, req) && want_poll_cb)
want_poll_cb ();
}

流程概括如下：

1. 从req_queue队列（即，待处理队列）中取出一个eio请求
2. 调用ETP_EXECUTE完成io的实质操作，这会是一个阻塞过程。
3. 将eio请求插入res_queue队列（即，已处理队列）
4. 调用want_poll_cb回调函数

这里要注意want_poll_cb的回调条件，当且仅当入队前res_queue为空，才会调用。

执行同步IO：eio_execute

线程函数中有ETP_EXECUTE出现，这个宏指代了eio_execute函数。在这个函数里面，根据eio_req的type域进行switch case，调用相应的io函数完成实质操作，并把结果写到eio_req中。简单代码如下：

// ...
switch (req->type)
{
// ...
case EIO_MKDIR:     req->result = mkdir     (req->ptr1, (eio_mode_t)req->int2); break;
// ...
}
// ...

单纯从异步IO操作的执行看，前面介绍的流程已经能完成了，但是我们不仅要执行IO，还要获取执行的结果，并触发想要的回调。这是通过eio_poll来实现的：

接收报告：eio_poll

如同很多函数一样，eio_poll只是套了个壳儿，进而调用etp_poll。删减了一些代码，挑出重要逻辑如下：

for (;;)
{
ETP_REQ *req;
etp_maybe_start_thread ();
req = reqq_shift (&res_queue);
if (req)
{
if (!res_queue.size && done_poll_cb)
done_poll_cb ();
}
--nreqs;
}

流程要点如下：

1. 调用etp_maybe_start_thread()，上面已经讲过，在满足条件的情况下会创建工作线程。
2. 从res_queue中取出一个eio_req
3. 如果res_queue为空，则触发done_poll_cb回调

总结

就这样吧，再给出一张图来整体贯穿一下：

Beside the v8 engine, the most important is libuv. libuv as a platform layer for Node, its purpose is to abstract IOCP on Windows and libev on Unix systems. Of course, we pay attention to Unix system (maybe call *nix is better ?). Related libraries in libuv is as follow:

• ares

This is c-ares, an asynchronous resolver library.

• libev

In a word: libev is an event loop

• libeio

In a word: libeio is an asynchronous I/O library

Init(), as the name, is responsible for following work:

• Parse command line arguments
• Prepare v8 runtime
• Set v8 flags (like stack size limit)
• Set fatal error handler
• Prepare signal handler
• uv init

And of course, the source under NODEJS_SOURCE/src is the core of Node.js project. So I start to read the source code at this point. No matter whether it is the correct entry point… may be I will clear about this in future

Files in NODEJS_SOURCE/src:
36 .cc files, totally 18009 lines
26 .h files, totally 5420 lines
2 .py files, we don’t care about these temporarily

The node_main.cc is the whole entry, you can find main function in this file. furthermore, there is only one function which has one line:

#include

int main(int argc, char *argv[]) {
  return node::Start(argc, argv);
}

The highlight function call node::Start defined in node.cc. Following is corresponding code:

int Start(int argc, char *argv[]) {
  // This needs to run *before* V8::Initialize()
  argv = Init(argc, argv);

  v8::V8::Initialize();
  v8::HandleScope handle_scope;

  // Create the one and only Context.
  Persistent<v8::Context> context = v8::Context::New();
  v8::Context::Scope context_scope(context);

  Handle<Object> process = SetupProcessObject(argc, argv);
  v8_typed_array::AttachBindings(context->Global());

  // Create all the objects, load modules, do everything.
  // so your next reading stop should be node::Load()!
  Load(process);

  // All our arguments are loaded. We've evaluated all of the scripts. We
  // might even have created TCP servers. Now we enter the main eventloop. If
  // there are no watchers on the loop (except for the ones that were
  // uv_unref'd) then this function exits. As long as there are active
  // watchers, it blocks.
  uv_run(uv_default_loop());

  EmitExit(process);

#ifndef NDEBUG
  // Clean up.
  context.Dispose();
  V8::Dispose();
#endif  // NDEBUG

  return 0;
}

We have to deep into each highlight function call.

/*
 * Binder test, try to get binder version via ioctl()
 *
 */

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>

#include "binder.h"

struct binder_state
{
    int fd;
    void *mapped;
    unsigned mapsize;
};

signed long get_version(struct binder_state *bs)
{
	struct binder_version ver;

	int ret = ioctl(bs->fd, BINDER_VERSION, (unsigned long)&ver);
	if (ret < 0) {
		perror("binder_write: ioctl failed !");
		return -1;
	}

	return ver.protocol_version;
}

int main(int argc, char *argv[])
{
	struct binder_state *bs;
	signed long ver;

	bs = binder_open(128*1024);
	if (!bs) {
		perror("could not open binder device !");
		return -1;
	}

	ver = get_version(bs);

	printf("\nbinder version = 0x%08x (%d)\n\n", ver, ver);

	binder_close(bs);
	return 0;
}

Do “ndk-build V=1″ and actual build commands will be displayed. This can be used to verify that things are compiled as you expect them to, and check for bugs in the NDK build system.

(The V=1 trick comes from the Linux kernel build system)

How to force a rebuild of all your sources:
——————————————-

Use GNU Make’s “-B” option, as in:

ndk-build -B

How to store your native sources in a location other than $PROJECT/jni:
———————————————————————–

First, you can simply tell your $PROJECT/jni/Android.mk to include another Android.mk that are located in different places. Alternatively, you can define APP_BUILD_SCRIPT in your Application.mk to point to an alternative Android.mk file.

How to build a project’s native files without cd-ing to it:
———————————————————–

Sometimes, you may need to rebuild a project’s native file without being able to cd to its top-level path from the command-line. This is do-able by using the GNU-Make ‘-C <path>’ option, as in:

ndk-build -C <project-path>

How to store your Application.mk in a location other than $PROJECT/jni:
———————————————————————–

Starting with NDK r4, you can simply place the file under $PROJECT/jni/ and launch the ‘ndk-build’ script from your project tree.

If you want to use ‘ndk-build’ but place the file to a different location, use a GNU Make variable override as:

ndk-build NDK_APPLICATION_MK=/path/to/your/Application.mk

If you’re using the legacy $NDK/apps/<name> build method, you can create a symbolic link to your final Application.mk there. For example, imagine that you wrote: $PROJECT/foo/Application.mk You can create a symlink like with a command like:

ln -s $PROJECT/foo $NDK/apps/<name>

This will make $NDK/apps/<name>/Application.mk point directly to $PROJECT/jni/Application.mk

Note that generated files will still go under $NDK/out/apps/<name> though.

Windows users: The NDK is only supported on Cygwin, which implements symbolic links through the “ln -s” command, as in:

ln -s <target> <link>

How to properly add include directories to your module declaration:
——————————————————————-

If you define several modules, it is common to need to include one module’s header while compiling another one. For example, consider the following example:

$PROJECT/jni/foo/
Android.mk
foo.h
foo.c

$PROJECT/jni/bar/
Android.mk
bar.c

Where the ‘bar.c’ uses ‘#include <foo.h>’. You will need to add the path to the ‘foo’ module in jni/bar/Android.mk to build it properly. One is tempted to use the following:

LOCAL_C_INCLUDES := ../foo

However this will not work because all compilation happens from the directory where ‘ndk-build’ is invoked, and include files must be relative to it.

The correct line is instead:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo

Which uses a path relative to $(LOCAL_PATH), in the case where you would need to move ‘foo’ and ‘bar’ to a deeper level in the ‘sources’ hierarchy.

In case you absolutely need it, you can also use NDK_APP_PROJECT_PATH to point to your project directory:

LOCAL_C_INCLUDES := $(NDK_APP_PROJECT_PATH)/jni/foo

However, we don’t recommend using this, paths relative to $(LOCAL_PATH) being better.

—————————————————————-

Android Recovery

Android Recovery: 功能简介

Android支持Recovery模式。在某些操作之后，系统会自动重启并进入到Recovery模式，用户按组合键开机（HOME+POWER），也可进入Recovery模式。该模式提供如下功能：

1、擦除用户数据

恢复系统到出厂模式，即擦除用户数据和缓存数据。

2、系统升级

系统升级的概念比较广，包括系统文件的升级、恢复损害的系统数据、firmware的升级，以及应用软件的维护，甚至影音文件的下载。系统升级需要使用特定的升级包，Android使用OTA[1]升级包，其初衷在于可以发挥广域无线通信链路的优势，如3G。

升级方式有两种：

1、在线升级

利用无线通信网络，系统自动连接更新源，查看有无升级包、下载OTA升级包，然后给出提示，发起升级过程，如下左图。感觉有点类似Windows XP的系统更新，只不过升级的时候，Android系统会重启系统进入Recovery模式。另外Android的升级内容很广泛，比如可以通过这种方式安装应用程序。T-Mobile已经提供了这种服务，如升级服务器以OTA无线方式向G1终端发送Android平台RC33升级包，传输媒介可以是3G网络、Wi-Fi或GPRS。

2、离线升级

可以将下载到的OTA包放在SD卡里，通过离线方式升级，如下右图所示。这种升级方式比较灵活，不用花费无线流量。这样一来，使用自己制作的OTA进行升级也成为可能。事实上，G1就是用这种方式进行刷机的，比如更新radio firmware以支持某个频段。

Android: 分区结构

在分析Recovery工作流程之前，我们先了解一下Android文件系统的分区结构。下表是android/bootable/recovery/root.c中提得到的结构：

Root file system layout

模拟器环境下adb shell里的mount输出：

# mount

……

/dev/block/mtdblock0     /system                       yaffs2      ro                                0     0

/dev/block/mtdblock1     /data                            yaffs2      rw,nosuid,nodev            0     0

/dev/block/mtdblock2     /cache                         yaffs2      rw,nosuid,nodev            0     0

综上，MTD中有如下分区：

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

有几点说明：

1、一般来讲，主板上还有用于存储bootloader的可擦写存储设备。若具备通信能力，还要存储radio firmware，这两部分的更新由Recovery协助Bootloader完成，没有代码证明一定存在NAND flash上。

2、RECOVERY分区无文件系统，存放二进制image。

3、SYSTEM中有recovery.img的备份：/system/recovery.img，initrc中有如下代码：

service flash_recovery /system/bin/flash_image recovery system/recovery.img

oneshot

每次启动，flash_image程序，会检查recovery分区中image的header，如果与备份的recovery.img不符，就会把备份写到RECOVERY分区。这样做是为了应对RECOVERY分区遭到破坏。当然，我们也可以更换这个备份，这样也会将其写到RECOVERY。事实上，处于安全及版权考虑，OTA是有签名的（其实就是JAR包），Recovery对签名有要求，所以只能进行被允许的升级，此时的破解思路就是更换一个不检查签名的Recovery程序，方法就是设法更换/system/recovery.img。

Android Recovery: 三个部分、两个接口

Recovery的工作需要整个软件平台的配合，从架构角度看，有三个部分：

1、Main system：用boot.img启动的Linux系统，Android的正常工作模式。

2、Recovery：用recovery.img启动的Linux系统，主要是运行Recovery程序。

3、Bootloader：除了加载、启动系统，还会通过读取flash的MISC分区获得来自Main system和Recovery的消息，并以此决定做何种操作。

在Recovery的工作流程中，上述三个实体的通信必不可少。通信的接口有以下两个：

l         CACHE分区中的三个文件：/cache/recovery/…

Recovery通过/cache/recovery里的文件与main system通信，有三个文件：

1. /cache/recovery/command

Main system传给Recovery的命令行，每一行有一个命令，支持以下几种：

–send_intent=anystring               write the text out to recovery/intent

–update_package=root: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

1. /cache/recovery/log

Recovery的log输出，在recovery运行过程中，stdout及stderr会重定位到/tmp/recovery.log文件，Recovery退出之前会将其转储到/cache/recovery/log中，也就是cache分区的recovery/log。

1. /cache/recovery/intent

Recovery传给Main system的信息

l         BCB (bootloader control block)

struct bootloader_message {

char  command[32];

char  status[32];

char  recovery[1024];

};

BCB是Bootloader与Recovery的通信接口，也是Bootloader与Main system的通信接口，存储在flash中的MISC分区，占用三个page，各成员意义如下：

command：

当想要重启进入recovery模式，或升级radio/bootloader firmware时，会更新这个域。当firmware更新完毕，为了启动后进入recovery做最终的清除，bootloader还会修改它。

status：

update-radio或update-hboot完成后，bootloader会写入相应的信息，一般是一些状态或执行结果。

recovery：

仅被Main system写入，用于向Recovery发送消息，必须以“recovery\n”开头，否则这个域的所有内容会被忽略。这一项的内容中“recovery/\n”以后的部分，是/cache/recovery/command支持的命令，可以认为这是在Recovery操作过程中，对命令操作的备份。Recovery也会更新这个域的信息，执行某操作前把该操作命令写到recovery域，并更新command域，操作完成后再清空recovery域及command域，这样在进入Main system之前，就能确保操作被执行。

如图所示，Main system、Recovery与Bootloader通过上述接口通信，通信逻辑依不同的目的而不同，在后面介绍具体工作流程中还会详细介绍。

从Main system进入Recovery的方法

我们提到，从Main system进入到Recovery，要修改MISC分区的数据并重启，从而告诉Bootloader是用boot.img还是用recovery.img启动。

init.c里的wait_for_one_process函数中有如下代码：

__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

Android Recovery: 总体流程

根据Recovery的initrc，kernel启动完成后，启动recovery服务，这是一个C程序，入口在/bootable/recovery/recovery.c中，main函数结构清晰，主要流程如图：

l         get_args：首先调用get_args获取参数，主要流程如下：

get_args不仅传回获取到的参数，还会将其写入BCB，这样，一旦升级或擦除数据的过程中出现错误，重启之后依然进入Recovery并做相同操作。

l         register_update_command，这是为update做准备工作，负责注册update用的command & function，正是这些command & function组成了update用到的update_script：

先用commandInit（android/bootable/recovery/amend/command.c）初始化command symbol table，然后多次调用registerCommand及registerFunction注册command及function。command相关的源代码都在amend目录中，语法的构建及解析使用Android已经包含的Bison（Yacc）。

这里的command有15个，见下表：

CMD_ARGS_BOOLEAN表示该command后面接的参数是boolean值，即true或false，解析脚本时计算参数的逻辑值，然后传给command handler，目前只有“assert”这个command用此类型的参数。

CMD_ARGS_WORDS表示该command后面接的参数是字符，形如C程序启动时加的参数，解析脚本时把参数直接传递给command handler，比如“format BOOT:”，“BOOT:”会传给cmd_format。

function与command用同样的处理框架，只不过function会产生返回值，目前见到的用法一般都是与assert一起使用，例如下面脚本：

assert  getprop(“ro.bootloader”) == “0.95.0000″

先用getprop从properties中取得bootloader版本，然后再将比较后的boolean值传给assert。

l         prompt_and_wait：等待用户输入

首先打印文本信息。然后执行finish_recovery(NULL)，这个函数后面介绍。然后进入ui_wait_key等待用户输入，按下不同的组合键会有不同的动作。对于键盘输入，先到达input_thread函数(android/bootable/recovery/ui.c)，在那里处理两种组合键，其余才交给ui_wait_key处理：

Home + Back：退出prompt_and_wait。

Alt + W或Alt + S，执行完install_package或erase_root后，若没有激活log text display，那么，就会退出prompt_and_wait，否则继续等待输入。

Green + Menu + Red：立刻重启，一般这样还会进入Recovery，因为BCB还没有来得及清空。

l         finish_recovery：离开Recovery进入Main system的必经之路，流程如下：

intent内容作为参数传进来，如果有intent需要告知Main system，将其写入/cache/recovery/intent；

将所有log信息转储到/cache/recovery/log文件，以供Main system读取；

清除BCB，也就是告知Bootloader启动进入Main system；

删除/cache/recovery/command；

以上是整体流程中的几个函数，关于安装升级包、升级firmware等操作将在具体流程中介绍。

Android Recovery: Factory data reset流程

如果系统不稳定，可以尝试恢复出厂设置，该操作会擦除DATA分区及CACHE分区，有两种恢复方式，下面分别介绍：

l         通过Setting程序发起Facory data reset：

屏幕显示如上图，结合着下面的通信图，列出工作流程：

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

第四个步骤，Recovery向BCB写入boot-recovery和–wipe_data，这是为了保证后面几个步骤的完整执行。如，在擦除DATA分区或CACHE分区过程中，如果发生了重启、关机等操作，导致没有擦除成功，那么再次用常规方式开机后，Bootloader会依据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

l         通过HOME+POWER组合键进入Recovery，再按ALT+W启动Factory data reset

过程比较简单，而且与上一种方式类似，结合总体流程，步骤如下：

1、捕获按键Alt + W。

2、擦除DATA分区、擦除CACHE分区。

3a、若激活了log显示（ALT+L：toggle log text display），调用finish_recovery函数重启，回到Main system。

3b、若没有激活log显示，继续接收按键，可用HOME+BACK重启回到Main system。

Android Recovery Update: 流程

l         update.zip

update操作需要升级包，该升级包是文件名是*.zip，但观察包内结构会发现其实就是JAR包，JAR包是具有特定目录和文件结构的ZIP压缩包，因此可以作为ZIP包解开：

MANIFEST.MF：这个manifest文件定义了与包相关数据。

XXX.SF：这是JAR文件的签名文件，占位符xxx标识签名者，如CERT。

XXX.DSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。

在META-INF/com/google/android目录下有update_script文件，内容就是update要做的操作，也就是前面提到过的command序列。

出于安全性及版本控制的考虑，JAR包要求必须有完整性以及合法性签名。可以看出这是Android确保安全的策略。JAR相关内容参见http://www.ibm.com/developerworks/cn/java/j-jar/，这里就不再详细介绍。

l         Main system部分

通过Android系统下载升级包并启动升级操作，需要上层应用Updater的支持，它是Java程序，代码位置android/packages/apps/Updater。大致流程：

系统启动后，如果存在网络连接，则检查是否存在升级包；

如果存在升级包，则下载至/cache目录；

调用Updater程序来提示是否升级；

如果Updater程序进程不存在,则自动启动此程序；

没有在代码中找到开始升级后执行哪些操作。不过由recovery.c的注释部分可以肯定一定需要重启进入Recovery，重启前要更新/cache/recovery/command，以告知Recovery进行升级：

–update_package=root:path

l         update流程

update有两种方式，第一种是上面提到的由Android启动的自动update过程，升级包在cache/下，升级包的名字在/cache/recovery/command文件中指定。第二种是手动进入Recovery模式，然后输入Alt + S，安装/sdcard/update.zip升级包。两种方式不同的只是安装包的位置以及传递参数给Recovery的方法，update过程都是一样的，工作流程如下图所示：

• install_package @ android/bootable/recovery/install.c

得到安装包信息，如“–update_package=CACHE:update.zip”，进入install_package函数，流程如下左图。mount安装包所在的分区，然后打开zip压缩包，进入handle_update_package开始升级：

handle_update_package中，先对包进行校验，校验过程分三步：

verifySignature：    检验SF文件与RSA文件的匹配

verifyManifest：      检验/META-INF/MANIFEST.MF与签名文件中的digest是否一致

verifyArchive：       检验包中的文件与MANIFEST是否一致

接着find_update_script从MANIFEST.MF找到update_script的位置，然后handle_update_script，如下图，把内容读到buffer后，对其进行解析，分解成各个command（包括function）放在一个list中依次执行。

• maybe_install_firmware_update @ android/bootable/recovery/firmware.c

install_package成功后，调用maybe_install_firmware_update，这个函数处理firmware的更新。update firmware脚本是这样的：

write_radio_image PACKAGE:radio.img

cmd_write_firmware_image处理write_radio_image这个命令，将image从压缩包加载到RAM中，并调用remember_firmware_update更新update_type、update_data及update_length。这三个变量对于maybe_install_firmware_update是可见的，并由它们来判断是否要安装firmware。下面是主要流程：

如果升级涉及radio / hboot firmware （radio：基带处理相关，hboot：bootloader）

1、向BCB写入”boot-recovery”和”–wipe_cache”

……此后重启系统，将进入recovery并擦除CACHE分区

2、write_update_for_bootloader向raw CACHE分区写入image，CACHE分区的内容将被破坏。

3、向BCB写入”update-radio/hboot”和”–wipe_cache”

4、重启，由Bootloader更新firmware

5、Bootloader向BCB写入”boot-recovery”，并保留BCB中recovery里的”–wipe_cache”

6、重启，再次进入Recovery，调用erase_root()擦除CACHE分区

7、finish_recovery()清除BCB

8、重启，进入main system

l         Bootloader

每次启动，Bootloader都会读取位于MISC分区的bootloader_message，并检查command区域以\0结尾，还要考虑flash存在坏块的情况。然后根据读取的命令，启动系统或者更新firmware。工作流程如下：

升级之后，无论升级成功是否，Bootloader都会进入recovery完成最后的收尾工作，并带着status以告知是否成功。如果更新hboot（尚不知道为什么叫这个名字，不过可以确定它就是bootloader firmware），一旦失败，若原有的bootloader遭到破坏，那么系统将不能boot。

为实现Android Recovery，还需要做什么？

实现Setting中Factory data reset

查看Updater工作流程，找到发起update的方法

实现__reboot(…..”recovery”)函数，连接Main system与Recovery

升级包的打包方法，以及JAR包签名机制

实现Bootloader与Recovery及Main System的通信；

实现Bootloader的启动逻辑、firmware升级；

They’ve a temper, some of them—particularly verbs: they’re the proudest—adjectives you can do anything with, but not verbs—however, I can manage the whole lot of them! Impenetrability! That’s what I say!
— Humpty Dumpty

Hello, world! Today we’re going to hear the story of Evil King Java and his quest for worldwide verb stamp-outage.¹

The Garbage Overfloweth

  get the garbage bag from under the sink
  carry it out to the garage
  dump it in the garbage can
  walk back inside
  wash your hands
  plop back down on the couch
  resume playing your video game (or whatever you were doing)

For the lack of a nail,
    throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe,
    EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

For the lack of a horse,
    RidersGuild.getRiderNotificationSubscriberList().getBroadcaster().run(
      new BroadcastMessage(StableFactory.getNullHorseInstance()));

For the lack of a rider,
    MessageDeliverySubsystem.getLogger().logDeliveryFailure(
      MessageFactory.getAbstractMessageInstance(
        new MessageMedium(MessageType.VERBAL),
        new MessageTransport(MessageTransportType.MOUNTED_RIDER),
        new MessageSessionDestination(BattleManager.getRoutingInfo(
                                        BattleLocation.NEAREST))),
      MessageFailureReasonCode.UNKNOWN_RIDER_FAILURE);

For the lack of a message,
    ((BattleNotificationSender)
      BattleResourceMediator.getMediatorInstance().getResource(
        BattleParticipant.PROXY_PARTICIPANT,
        BattleResource.BATTLE_NOTIFICATION_SENDER)).sendNotification(
          ((BattleNotificationBuilder)
            (BattleResourceMediator.getMediatorInstance().getResource(
            BattleOrganizer.getBattleParticipant(Battle.Participant.GOOD_GUYS),
            BattleResource.BATTLE_NOTIFICATION_BUILDER))).buildNotification(
              BattleOrganizer.getBattleState(BattleResult.BATTLE_LOST),
              BattleManager.getChainOfCommand().getCommandChainNotifier()));

For the lack of a battle,
    try {
        synchronized(BattleInformationRouterLock.getLockInstance()) {
          BattleInformationRouterLock.getLockInstance().wait();
        }
    } catch (InterruptedException ix) {
      if (BattleSessionManager.getBattleStatus(
           BattleResource.getLocalizedBattleResource(Locale.getDefault()),
           BattleContext.createContext(
             Kingdom.getMasterBattleCoordinatorInstance(
               new TweedleBeetlePuddlePaddleBattle()).populate(
                 RegionManager.getArmpitProvince(Armpit.LEFTMOST)))) ==
          BattleStatus.LOST) {
        if (LOGGER.isLoggable(Level.TOTALLY_SCREWED)) {
          LOGGER.logScrewage(BattleLogger.createBattleLogMessage(
            BattleStatusFormatter.format(BattleStatus.LOST_WAR,
                                         Locale.getDefault())));
        }
      }
    }

For the lack of a war,
    new ServiceExecutionJoinPoint(
      DistributedQueryAnalyzer.forwardQueryResult(
        NotificationSchemaManager.getAbstractSchemaMapper(
          new PublishSubscribeNotificationSchema()).getSchemaProxy().
            executePublishSubscribeQueryPlan(
              NotificationSchema.ALERT,
              new NotificationSchemaPriority(SchemaPriority.MAX_PRIORITY),
              new PublisherMessage(MessageFactory.getAbstractMessage(
                MessageType.WRITTEN,
                new MessageTransport(MessageTransportType.WOUNDED_SURVIVOR),
                new MessageSessionDestination(
                  DestinationManager.getNullDestinationForQueryPlan()))),
              DistributedWarMachine.getPartyRoleManager().getRegisteredParties(
                PartyRoleManager.PARTY_KING ||
                PartyRoleManager.PARTY_GENERAL ||
                PartyRoleManager.PARTY_AMBASSADOR)).getQueryResult(),
        PriorityMessageDispatcher.getPriorityDispatchInstance())).
      waitForService();

All for the lack of a horseshoe nail.