meisw's blog

adbd源码位于system/core/adb/目录下，可执行文件位于/sbin/adbd。通过adb执行ps命令，结果如下：

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME

root      1     0     296    212   c00b0124 0000d9ec S /init

... ...

shell     2183  1     3372   184   ffffffff 0000eca4 S /sbin/adbd

root      2204  1859  832    336   00000000 afe0c7dc R ps

看一下倒数第二行，adbd所在进程的父进程是root，本身的user是shell。对于一个发布状态的产品，这个是最正常不过了。但现在开发中遇到这样一个需求，产品已经处在发布状态（编译模式已经改成user）的情况下，因为BSP需要处理一些内核上的东西，需要在PC上执行adb shell后具有root权限。也就是这种效果：

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME

root      1     0     296    212   c00b0124 0000d9ec S /init

... ...

root      1911  1     3376   184   ffffffff 0000eca4 S /sbin/adbd

root      2198  2197  828    332   00000000 afe0c7dc R ps

要达到这个效果，就是要在启动adbd时，以root用户启动。那么，先看一下在Android中怎么启动adbd。

可以看一下Android系统根目录下的/init.rc的片段：

... ...

# adbd is controlled by the persist.service.adb.enable system property

service adbd /sbin/adbd

    disabled

# adbd on at boot in emulator

on property:ro.kernel.qemu=1

    start adbd

on property:persist.service.adb.enable=1

    start adbd

on property:persist.service.adb.enable=0

    stop adbd

... ...

这里定义了一个触发器，只要persist.service.adb.enable值被置为1，就会启动/sbin/adbd。

怎么样设置persist.service.adb.enable的值呢？这里涉及到一个属性服务/system/core/init/property_service.c。看下面的东西之前先看一下我之前翻译过来的这篇StevGuo的文档，他对属性服务描述得很仔细，也很有条理。

http://blog.csdn.net/a345017062/archive/2010/12/17/6083026.aspx

今天搜资料的时候才发现网上N多人翻译了这篇文章，有点儿晕晕的。。。

我们继续。。。

通过阅读上面的文档，我们知道了属性服务启动时加载了四个文件，这四个文件里面都可以设置系统属性，还可以通过APK设置系统属性。但我把这些方式都，结果都一样，adbd是启动起来了，用户都是shell，还是没有root权限的。看来差异应该在编译模式上，是改为user编译模式后，系统改变了adbd启动时的权限。在build目录下搜索一下，发现了main.mk中有这样的代码片段

## user/userdebug ##

user_variant := $(filter userdebug user,$(TARGET_BUILD_VARIANT))

enable_target_debugging := true

ifneq (,$(user_variant))

  # Target is secure in user builds.

  ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=1

  tags_to_install := user

  ifeq ($(user_variant),userdebug)

    # Pick up some extra useful tools

    tags_to_install += debug

  else

    # Disable debugging in plain user builds.

    enable_target_debugging :=

  endif

  # TODO: Always set WITH_DEXPREOPT (for user builds) once it works on OSX.

  # Also, remove the corresponding block in config/product_config.make.

  ifeq ($(HOST_OS)-$(WITH_DEXPREOPT_buildbot),linux-true)

    WITH_DEXPREOPT := true

  endif

  # Disallow mock locations by default for user builds

  ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=0

else # !user_variant

  # Turn on checkjni for non-user builds.

  ADDITIONAL_BUILD_PROPERTIES += ro.kernel.android.checkjni=1

  # Set device insecure for non-user builds.

  ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=0

  # Allow mock locations by default for non user builds

  ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=1

endif # !user_variant

ifeq (true,$(strip $(enable_target_debugging)))

  # Target is more debuggable and adbd is on by default

  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1 persist.service.adb.enable=1

  # Include the debugging/testing OTA keys in this build.

  INCLUDE_TEST_OTA_KEYS := true

else # !enable_target_debugging

  # Target is less debuggable and adbd is off by default

  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=0 persist.service.adb.enable=0

endif # !enable_target_debugging

这段代码我大致解释一下：

主要通过判断当前的编译模式来给几个属性赋予不同的值，然后把属性存储在ADDITIONAL_DEFAULT_PROPERTIES这个变量中，这个变量在后面是要写到根目录下的/default.prop中去，在系统启动时被属性服务加载的。也就是说我们在/default.prop中看到的几个属性的值是在这里设置的。

只看两个属性ro.secure，persist.service.adb.enable。当前是user模式的话，编译系统会把ro.secure置为1，把persist.service.adb.enable置为0.也就是说，用user模式编译出来的系统运行在安全模式下，adbd默认关闭。即使通过设置属性的方式打开，adbd进程的用户也是shell，不具有root权限。这样，普通用户或者开发者拿到一个机器后，通过PC运行adb shell时，是以shell用户登录机器的。

好了，现在把ro.secure置为0，再重新编译，只要设置属性persist.service.adb.enable的值为1，adbd进程就会以root用户的身份启动。

http://blog.csdn.net/a345017062/article/details/6254402

bionic，整个系统的基础类库，Android系统就是基于这个类库开发的，

system，Android系统类库，基于bionic类库开发，包含工具类库（libcutils），LOG类库（liblog），压缩类库（libzipfile）类。

主要功能有：

一、完成Android初始化（init）。

解析init.rc并开启系统初始化时需要加载的程序（parser.c），初始化设备（devices.c），开启属性服务（property_service.c）等。

二、开启Android系统的一些基础服务。

1、系统的设备服务（vold）。比如完成SD卡挂载、卸载管理，从内核处接收事件建立设备结点等。

三、SHELL程序及相应的toolbox。

四、ADB程序。

五、logcat系统。

可以说，bionic和system两个文件里的东西完成了Android对Linux的封装，在这两个文件夹的基础上构建起了Android系统的两大核心模块：Dalvik和Framework。Dalvik是一个基础纯C的VM，这个网上有比较详细的说明。重点一层层地分析一下Framework。

最底层就是几大模块:

1、utils工具库（frameworks/base/libs/utils/目录下）

这个类库基于bionic编译写，提供了一些对bionic里面的基础C/C++类库中的高层次封装。Framework中的C++程序大量使用这里的类库来封装更高层的系统功能。

2、binder库（framewoks/base/libs/binder/目录下）

这个与OpenBinder开源项目相似，提供了一种进程通信机制。C++和Java层都大量使用了这种机制。它把通信双方分为服务提供者和使用者两种角色。提供者内部有注册的服务接口，使用者去查找调用。

3、ui库（frameworks/base/libs/ui/目录下）

这个库主要提供了UI绘制和视频输出两类接口，整个系统的输出框架都是以这个库为基础，通过它与FrameBuffer通信。

4、surfaceflinger库（frameworks/base/libs/surfaceflinger/目录下）

对ui库的更高层次的封装，通过binder机制对Android系统中的上层模块提供输出服务。

5、audioflinger库（frameworks/base/libs/audioflinger/目录下）

音频输出基础类库，上层模块通过这个库与驱动还有打交导输出声音。

6、大量开源库（external/目录下）

这几大模块构成了整个Framework的基础。围绕这几大模块，就可以构建一个真正的操作系统的上层模块，创建应用程序运行环境了。比较典型的有：

多媒休服务，提供给音视频播放和录制服务。

服务管理，维护和管理系统中存在的大量服务提供程序，应用程序通过binder机制通过服务管理中心的servicemanager来访问和使用这些服务，比如电源、蓝牙、Wifi等模块都以服务的形式存在于系统中供应用程序调用。

运行时环境，初始化应用程序的运行环境，并加载第一个应用程序，Launcher。

应用程序运行时环境创建完成后，系统就算正式启动起来了。当一个应用程序被加载到系统中时，它和系统打交导最多的就是系统提供的开发API了。主要集中在frameworks/base/core/目录下。

转

折腾了几天，被Android那点儿少得可怜的shell命令折磨的死去活来，终于下定了革命的决心。看一下怎么把渺小的toolbox替换成伟大的busybox吧。先大致描述一下Android系统中的shell程序部分。

shell实现分为两部分：

一、shell解释器和内置命令

源码位于system/core/sh目录下，主要完成shell命令的解释查找，对于builtins.c中包含的内置命令，直接执行，对于toolbox的扩展命令，间接调用toolbox程序完成。

二、toolbox扩展命令

主要完成扩展命令的执行，每一个扩展命令对应一个name_main函数，如ls命令，对应ls_main函数。同时，每一个扩展命令都由一个system/core/toolbox/目录下面的.c文件实现。toolbox.c会根据这个目录下面的.c文件生成tools.h头文件，并在system/core/toolbox/Android.mk文件中为每个命令生成指向toolbox的连接。toolbox的实现结构使它扩展一个命令很容易。

假设现在我们自己想手工添加一个shell命令mycommand，只要在system/core/toolbox/目录下面新建一个mycommand.c文件，并在里面实现一个mycommand_main函数，然后在system/core/toolbox/Android.mk中添加mycommand.c即可。Android.mk会自动把它编译进toolbox程序，并在编译生成的Android系统/system/bin目录下为这个命令生成一个指向toolbox的连接。

接下来翻译一下网上的一篇文章，借助它，可以把Android自带的toolbox替换成busybox。

Installing Busybox command line tools

英文原文地址：

https://gforge.ti.com/gf/project/omapandroid/wiki/?pagename=Installing+Busybox+command+line+tools

在Android系统中安装busybox命令行工具

本文简单地介绍了怎么把busybox安装到Android的文件系统中去。如果你想直接安装，可以从下面的地址下载我已经预编译好并在Android2.1系统上试验成功的busybox，然后直接跳过下面的安装步骤。

http://download.csdn.net/source/3093680

一、编译busybox

1、下载busybox的最新版本，本文写作时最新版本是1.13.3。

下载地址：http://www.busybox.net/

2、解压源码：

tar jxf busybox-1.13.3.tar.bz2

3、运行menuconfig对busybox进行配置

cd busybox-1.13.3/

make menuconfig

4、在menuconfig中设置以下选项

Busybox Settings --> Build Options --> Build Busybox as a static binary (no shared libs)  -  Enable this option by pressing "Y"

Busybox Settings --> Build Options --> Cross compiler prefix  -  Set this option equal to "arm-none-linux-gnueabi-"

Busybox Settings --> Installation Options --> Don't use /usr  -  Enable this option by pressing "Y"

5、把交叉编译器的地址导入到环境变量：

export PATH=/opt/arm/arm-2007q3/bin:$PATH

6、编译busybox

make

二、安装busybox

把busybox安装到Android系统中去，做这几步：

1、在Android系统根目录下创建一个/bin目录。

mkdir /<path-to-android-fs>/bin

2、把编译出来的busybox复制到/bin目录下

cp busybox /<path-to-android-fs>/bin

3、把busybox安装到Android机器中

cd /bin

./busybox --install

三、把busybox作为默认shell

需要像下面这样编辑一下init.rc

1、编辑console服务，让它默认运行busybox

service console /system/bin/sh  ->  service console /bin/sh

2、把busybox路径加入到环境变量中

export PATH /sbin:/system/sbin:/system/bin:/system/xbin  -->  export PATH /bin:/sbin:/system/sbin:/system/bin:/system/xbin

注：

我使用busybox时，只是想简单地增加一些命令，把toolbox一些功能不是很全的命令替换掉，所以操作上没有上面说的那么复杂。下面是我的替代方案，可以试一下：

1、把busybox复制到/system/bin目录下。

adb push busybox /system/bin

2、把要添加的命令通过ln建立到busybox的连接。

比如，Android自带的toolbox是没有test这个命令的。我们要添加test命令就可以：

cd /system/bin

ln -s busybox test

这样，用户通过机器上的shell执行test命令时，就会调用busybox中实现test功能的applet。

对于一些原有的命令，如ls、chown等，如果不想用toolbox，也可以把它们的连接目标指向toolbox，拿chown来举例。

cd /system/bin

rm chown

ln -s busybox chown

这样做，最大的好处就是保证对系统的改动最少，又可以最大限度的扩展shell功能。

参考文档：

为Android加入busybox工具

http://blog.csdn.net/liaoshengjiong/archive/2009/03/04/3957725.aspx

什么是交叉编译

http://www.linuxeden.com/doc/article.php/21264

加入 busybox source

http://cwhuang.info/2010/03/ad-busybox-source

转 http://blog.csdn.net/a345017062/article/details/6250619

1. 软盘上安装引导器（grub）

　　一般制作软盘上跑的Linux引导器都使用sysLinux这个工具（这个工具不支持ext2分区格式，只能支持fat分区格式），因为我对grub比较熟悉，并且我在软盘上安装grub只用了132KB空间，不是很耗磁盘空间。

　　具体操作如下：

# mke2fs /dev/fd0

　　创建了 ext2 文件系统后，需要安装该文件系统：

# mount /dev/fd0 /mnt/floppy

　　现在，需要创建一些目录，并将一些关键文件（原先安装 GRUB 时已安装了这些文件）复制到软盘：

# mkdir /mnt/floppy/boot 
# mkdir /mnt/floppy/boot/grub 
# cp /boot/grub/stage1 /mnt/floppy/boot/grub 
# cp /boot/grub/stage2 /mnt/floppy/boot/grub

　　再有一个步骤，就能得到可用的引导盘。

　　在Linux bash中，从 root 用户运行“grub”，该程序非常有趣并值得注意，因为它实际上是 GRUB 引导装入器的半功能性版本。尽管 Linux 已经启动并正在运行，您仍可以运行 GRUB 并执行某些任务，而且其界面与使用 GRUB 引导盘或将 GRUB 安装到硬盘 MBR 时看到的界面(即GRUB控制台)完全相同。

　　在 grub> 提示符处，输入：

grub> root (fd0) 
grub> setup (fd0) 
grub> quit

　　现在，引导盘完成了。
　　2. 安装根文件系统
　　一套Linux系统要正常启动，根文件系统要包括下列文件夹：

/bin /etc /proc /tmp /var /dev /mnt

　　要包括下列基本的设备文件：

/dev/console /dev/fd0 /dev/null /dev/ram0 /dev/tty /dev/tty0

　　要包括下列配置文件：

/etc/rc.d/inittab /etc/rc.d/rc.sysinit /etc/fstab

　　要实现基本的功能，还要包括一些常用工具：如：sh，ls，cd，cat等。其中，前面三个部分不要多少空间的，但是常用工具会占用很多空间，要是用原来系统中的这些命令，就是全部用静态编译，不是用动态连接库，大概有2MB~3MB，放不进软盘。网络上解决的方案是使用BusyBox工具。具体可以到官方网站：www.busybox.net看看。下载BusyBox工具的源代码。

　　注意：

　　（1） 译的时候要静态编译，修改 Makefile 中的 DOSTATIC 参数，从false 改为 true，这样，编译出来的代码就不要依赖glibc了。

　　（2） 因为我们用的是 BusyBox 上的 init，与一般所使用的 init 不太一样，会先执行 /etc/init.d/rcS 而非 /etc/rc.d/rc.sysinit，为了做出来的 FloppyLinux 架构与 Redhat 的架构一样，所以修改了 BusyBox 中的 init.c底下是修到的部分内容∶

#ifndef INIT_SCRIPT
#define INIT_SRCIPT "/etc/rc.d/rc.sysinit"
#endif

　　具体操作如下：

　　（1） 官方网站上下载BusyBox的最新版本：busybox-0.60.5.tar.gz解开，按照上面的注意点修改源代码。

　　（2） 运行下列命令：

#make
#make install

　　（3） 译好的可势行文件放在 ./_install 文件夹里的。

#cp ./_install /tmp/floppy-Linux -r

　　（4） 动建立其它的文件或文件夹：

#cd /tmp/floppy-Linux
# mkdir dev etc etc/rc.d proc mnt tmp var
# chmod 755 dev etc etc/rc.d bin mnt tmp var
# chmod 555 proc
# cd dev
# mknod tty c 5 0
# mknod console c 5 1
# chmod 666 tty console
# mknod tty0 c 4 0
# chmod 666 tty0
# mknod ram0 b 1 0
# chmod 600 ram0
# mknod fd0 b 2 0
# chmod 600 fd0
# mknod null c 1 3
# chmod 666 null

　　（5） 建启动配置文件：（inittab,rc.sysinit,fstab）

initab:
::sysinit:/etc/rc.d/rc.sysinit
::askfirst:/bin/sh
rc.sysinit:
#!/bin/sh

[1] [2] 下一页 

mount -a
# chmod 755 rc.sysinit
fstab:
proc /proc proc defaults 0 0

　　（6） 作Ramdisk的镜像文件：

# dd if=/dev/zero of=/tmp/initrd bs=1k count=4096
# losetup /dev/loop0 /tmp/initrd
# mke2fs -m 0 /dev/loop0>
# mount -t ext2 /dev/loop0 /mnt
# cp -r /tmp/floppy-Linux/* /mnt
# umount /mnt
# losetup -d /dev/loop0
# dd if=/tmp/initrd gzip -9 > /tmp/initrd.gz
# rm -f /tmp/initrd
# sync

　　3．编译内核：

　　这部分内容不详细讲述，主要是去掉了一些不需要的选项，减小内核，编译出来的内核是725920Byte。里面包含了必要的网卡驱动和网络协议栈。

　　4．整合启动盘

　　现在所用到了的东西全部搞好了，下面就是整合一下：

　　全部文件（文件夹）如下：

/lost+found/
/boot/
/boot/grub/
/boot/grub/stage1 =========èGrub启动时用到的两个文件
/boot/grub/stage2
/boot/grub/menu.lst =========èGrub的配置文件指向grub.conf
/boot/grub/grub.conf
/boot/kernel =============è内核
/initrd.gz ===============è内存镜像文件

　　这样这张软盘就能启动一套Linux系统了，占用1.213MB。

安卓系统 浅谈，由此可以大概分析刷机变砖的形成
*****************系统的基本启动过程************************
本帖隐藏的内容需要回复才可以浏览(2周后自动解除隐藏)#1，整个系统的引导是从boot.bin开始的

#2，boot完成必要的初始化以后，通过pit信息找到sbl分区

#3，sbl在引导过程中，检测是否存在满足要求的按键组合，如果满足进入download模式（俗称挖煤）的条件，就进入download，如果是进入recovery模式的按键组合，就传递参数给kernel，也就是zImage分区，进入recovery模式，如果都没有，就传递参数给kernel，正常启动系统。

*****************变砖的基本成因***************************

本帖隐藏的内容需要回复才可以浏览
1、boot、pit、sbl直接决定了机器有没有变砖，如果这三个区有一个出了问题，机器将直接无法进入download模式，也就是彻底变砖了。

2、有的sbl版本不检测按键组合，这就是我们常说的锁三键，破解方法就是刷入检测按键组合的版本即可。（例如：I9000的锁三键）

3、boot和sbl具有对应关系，不是随便两个组合就能引导成功，如果单独刷入了这两个文件而彼此之间是不匹配的那就变砖了。

*****************Odin软件平台刷机详解**************************
1，pit和re-partion。这两个需要组合在一起使用，功能就是把pit文件写入到bml2分区，目前看到的pit文件内容基本一致，区别在于factoryfs和dbdatafs两个分区大小不同，也就是说不同的版本调整了factoty和dbdata分区的大小，以满足不同的要求。（建议不要乱刷）

#2，pda——Pda文件是整个rom的核心内容，一般是个tar包，完整的内容包括下面几个文件
boot.bin、sbl.bin、param.lfs、zImage、factoryfs.rfs、cache.rfs
看过上面的分区机构以后，就很容易理解了，odin刷机做的事情，就是解包后把各个文件克隆到各个对应的分区。具体哪个文件名对应哪个分区，则是根据pit文件里的信息来确定的，如果这次不刷pit文件，odin会去读机器内部的pit信息。
某些pda文件的后缀是md5，本质上还是一个tar包。（其实你不管用什么扩展名，刷机平台都会用一样的方式解压，只要确保文件是正常的就应该可以）

#3， Phone，也叫modem，原来wm系统的机器叫radio，都是一个概念，管理无线通讯的，对应分区表中的bml12

#4，Csc，一般也是一个tar包，里面包含dbdata.rfs和cache.rfs（这个在pda文件中也有，应该是会被csc覆盖的）。

#5，这里提到的文件每次刷机都不是必须的，比如我们往往单刷kernel，实际上就是只刷pda文件中的zImage。

#6，风险分析。通过前面讲的分区机构和系统引导过程，我们可以知道odin刷机主要的风险集中在pit分区和pda文件中的boot和sbl，如果这几个刷到一半出了问题，将直接导致机器变砖。

*****************Recovery模式刷机分析***************************

我们的机器还支持在recovery模式下刷机，由于官方的recovery程序功能有限，现在流行使用ClockworkMod Recovery，新版的Cognition 就是用这个刷的。
至于和官方的版本有什么功能增强，我没有查到相关资料，望高人补充。
这个方式下刷机使用的rom格式是一个zip包，在META-INF\com\google\android目录下有一个脚本update-script，recovery程序如何处理zip，是由这个脚本决定的。
现将Cog包里的脚本摘几句看看
format SYSTEM:
format CACHE:
format DATA:
//格式化三个分区
delete SDCARD:update.zip
copy_dir PACKAGE:sdcard SDCARD://sdcard目录下文件复制到sdcard

删除了sdcard上两个目录
delete_recursive SDCARD:Voodoo
delete_recursive SDCARD:Android

copy_dir PACKAGE:system SYSTEM://system目录下所有内容拷贝到system分区
copy_dir PACKAGE:updates TMP:/updates
format SYSTEM:
…….
…….       
//设置文件权限
set_perm_recursive 0 0 0755 0555 SYSTEM:etc/ppp
set_perm_recursive 0 0 0755 0755 SYSTEM:etc/init.d
set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluetooth
set_perm 0 0 0755 SYSTEM:etc/bluetooth
set_perm 3002 3002 0444 SYSTEM:etc/bluetooth/blacklist.conf
set_perm 0 0 755 TMP:/updates/bmlwrite

run_program /system/bin/busybox --install -s /system/xbin
//用bmlwrite直接克隆分区，其实和odin刷机一个道理。
run_program /tmp/updates/bmlwrite /tmp/updates/modem.bin /dev/block/bml12
run_program /tmp/updates/bmlwrite /tmp/updates/Sbl.bin /dev/block/bml4
run_program /tmp/updates/bmlwrite /tmp/updates/zImage /dev/block/bml7

注意上面的那个Sbl.bin，很多人变砖就是因为这个！原因前面已经说了。

此文为网友发过来的WORD文档，我略做修改，具体来源不明，在此发表感谢作者

北京理工大学  20981  陈罡

以下是偶翻译的关于boot.img和recovery.img的编辑和修改方面的文章，希望能够为感兴趣的朋友节约一些看资料的时间。感谢本文的作者：Alansj, DarkriftX, RyeBrye, Will, Try OP9, Tonyb486, Timmmm, Lxrose还有好多不知名的作者们在wiki上的不懈努力。

如何解包／编辑／大包boot.img文件

很多人用自己的方式解决了boot.img的解包／编辑／打包的问题，有人要求我来写一篇关于boot和recovery映像的文件结构和如何对其编辑的文章，于是就有了下面这篇文章。

目录
1、背景知识
2、boot和recovery映像的文件结构
3、对映像文件进行解包、编辑、打包的常规方法
3.1、另一种解包、编辑、打包的方法
4、将新的映像刷回到手机
5、解包、编辑、打包为我们带来了什么
6、本文讲的内容与使用update.zip刷机包不是一码事

正文
1、背景知识

Android手机的文件系统有许多存储器组成，以下是在adb shell下面的输出：
#cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
注意，不同的手机在上述存储设备的顺序可能会各不相同!一定要检查您的手机，确定在以下的操作中选择正确的设备号（mtdX，这个X的序号一定要检查清楚）。

在本向导中，我们主要描述对"recovery"和"boot"的存储设备进行操作；"system"存储设备保存了android系统目录的所有数据（在系统启动后会挂载到“system/”目录）；“userdata”存储设备将保存了android数据目录中的所有数据（在系统启动后会挂载到“data/”目录，里面是会有很多应用数据以及用户的preference之类的配置数据）。

从上面的输出可以看出来，recovery和boot分区对应着/dev/mtd/mtd1和/dev/mtd/mtd2，在你您开始做任何修改之前一定要做两件事情，第一件事情，一定要先对这两个分区进行备份。
可以使用如下命令进行备份：
# cat /dev/mtd/mtd1 > /sdcard/recovery.img
# cat /dev/mtd/mtd2 > /sdcard/boot.img
（注意added by lxros，只有手机获取了ROOT权限以后才能够执行上述的备份命令）

第二件事情，你您应该把你您最喜欢的update.zip刷机包放置到你您的sd卡的根目录上面。如此一来，即使你您在后续的操作中出了问题，也可以启动到recovery模式进行恢复。

另外一个你您需要知道的重要文件是在android系统目录下的/system/recovery.img，此文件是mtd1存储设备的完全拷贝。这个文件在每次关机的时候，会自动地被写回到mtd1存储设备里面。

这会意味着两个事情：
(1)任何对/dev/mtd/mtd1中数据的直接修改都会在下一次重启手机以后消失。
(2)如果希望对/dev/mtd/mtd1进行修改，最简单的做法是用你您自己的recovery.img替换掉/system/recovery.img。当你您创建自己的update.zip刷机包的时候（特别是在做刷机包的适配的时候），如果你您忘记替换这个/system/recovery.img,这个recovery.img就会在关机的时候被烧写到mtd1里面去或许会变砖。一定要注意这一点！

（译者的话，关于这个/system/recovery.img文件，在2.1的android的平台里面并没有找到，或许这个机制已经out了？！或者偶本人对这段话的理解不够深入？！希望明白的朋友不吝斧正）

2、boot和recovery映像的文件结构
boot和recovery映像并不是一个完整的文件系统，它们是一种android自定义的文件格式，该格式包括了2K的文件头，后面紧跟着是用gzip压缩过的内核，再后面是一个ramdisk内存盘，然后紧跟着第二阶段的载入器程序（这个载入器程序是可选的，在某些映像中或许没有这部分）。此类文件的定义可以从源代码android-src/system/core/mkbootimg找到一个叫做bootimg.h的文件。

（译者的话，原文是一个叫做mkbootimg.h的文件，但从Android 2.1的代码来看，该文件名应该是改为bootimg.h了）。

/*
** +-----------------+
** | boot header     | 1 page
** +-----------------+
** | kernel          | n pages  
** +-----------------+
** | ramdisk         | m pages  
** +-----------------+
** | second stage    | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
**    the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr.  kernel_args[] is
**    appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
**    else: jump to kernel_addr
*/

ramdisk映像是一个最基础的小型文件系统，它包括了初始化系统所需要的全部核心文件，例如:初始化init进程以及init.rc（可以用于设置很多系统的参数）等文件。如果你您希望了解更多关于此文件的信息可以参考以下网址：
http://git.source.android.com/?p=kernel/common.git;a=blob;f=Documentation/filesystems/ramfs-rootfs-initramfs.txt
以下是一个典型的ramdisk中包含的文件列表：
./init.trout.rc
./default.prop
./proc
./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data

recovery映像包含了一些额外的文件，例如一个叫做recovery的二进制程序，以及一些对该程序支持性的资源图片文件（当你您按下home+power组合键的时候就会运行这个recovery程序）。
典型的文件列表如下：
./res
./res/images
./res/images/progress_bar_empty_left_round.bmp
./res/images/icon_firmware_install.bmp
./res/images/indeterminate3.bmp
./res/images/progress_bar_fill.bmp
./res/images/progress_bar_left_round.bmp
./res/images/icon_error.bmp
./res/images/indeterminate1.bmp
./res/images/progress_bar_empty_right_round.bmp
./res/images/icon_firmware_error.bmp
./res/images/progress_bar_right_round.bmp
./res/images/indeterminate4.bmp
./res/images/indeterminate5.bmp
./res/images/indeterminate6.bmp
./res/images/progress_bar_empty.bmp
./res/images/indeterminate2.bmp
./res/images/icon_unpacking.bmp
./res/images/icon_installing.bmp
./sbin/recovery

3、对映像文件进行解包、编辑、打包的常规方法
（注意，下面我给你您介绍的是手工命令行方式进行解包以及重新打包的方法，但是我仍然创建了两个perl脚本，这两个脚本可以让你您的解包和打包工作变得轻松许多。可以参考本文的附件unpack-bootimg.zip和repack-bootimg.zip）

如果你您很擅长使用16进制编辑器的话，你您可以打开boot.img或者recovery.img，然后跳过开始的2K的头数据，然后寻找一大堆0的数据，在这一堆0的数据后面，紧跟着1F 8B这两个数字（1F 8B是gzip格式的文件的结束标记）。从此文件开始的地方（跳过2K的头），一大堆0后面紧跟着到1F 8B这两个数字为止的全部数据，就是gzip压缩过的linux内核。从1F 8B后面紧跟着的数据一直到文件的结尾包含的全部数据，就是ramdisk内存盘的数据。你您可以把把内核和ramdisk两个文件分别保存下来，在进行分别的修改和处理。我们可以通过un-cpio和un-gzip操作来读取ramdisk文件中的数据，可以使用如下的命令来实现这个目的，以下操作会生成一个目录，直接cd进去就可以看到ramdisk中的数据了：

gunzip -c ../your-ramdisk-file | cpio -i

此命令可以将ramdisk中的所有的文件解包到当前的工作目录下面，然后就可以对它进行编辑了。

当需要重新打包ramdisk的时候，就需要re-cpio然后re-gzip这些数据和目录，可以通过如下命令来实现：（cpio会把所有当前目录下面的文件都打包进去，因此，在进行此步骤之前，请把不需要的文件都清除掉。）

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

最后一步就是通过mkbootimg这个工具，把kernel和ramdisk打包在一起，生成一个boot.img：

mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file --ramdisk newramdisk.cpio.gz -o mynewimage.img

这里的mkbootimg工具会在编译android的源代码的时候会在~/android-src/out/host/linux-x86/bin目录下面自动生成。
下载地址：
http://git.source.android.com/?p=platform/system/core.git;a=tree;f=mkbootimg

现在，如果不想背这些复杂的命令或者摆弄那个让人眩晕的16进制编辑器的话，可以尝试使用我编写的用于解包和打包的perl脚本了。希望这些脚本能够节约各位的键盘。

3.1、另一种解包、编辑、打包的方法
下载split_bootimg.zip文件（译者注，会在本文的附件中提供），在此zip文件中包含一个perl文件，split_bootimg.pl脚本，该脚本可以读取boot.img头（根据Android源码中的bootimg.h读取）将kernel和ramdisk读取出来，此脚本也会输出内核命令行和板子名字。

（注意，不要使用从/dev/mtd/mtd2直接拷贝出来的boot.img，此映像可能在读取过程遭到损坏。）
下面是一个从TC4-RC28更新中提取出来的boot.img进行解包操作：
% ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

解包ramdisk的命令如下：
% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..

解码完毕后，就可以修改了（例如，在default.prop设置ro.secure=0等等）

使用mkbootfs工具（mkbootfs工具是编译完毕Android源代码以后，就会在~/android-src/out/host/linux-x86/bin自动生成）来重新创建ramdisk，可以使用如下命令来操作：
% mkbootfs ./ramdisk | gzip > ramdisk-new.gz

使用mkbootimg来重新创建boot.img，mkbootimg也可以在~/android-src/out/host/linux-x86/bin目录中可以找到：
% mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img
（注意：console=null的命令行选现是从TC4-RC30的boot.img引入的，用以去掉root shell）

4、将新的映像刷回到手机
可以将recovery.img拷贝到/system目录下面，然后重新启动手机，让手机自动为你您刷写到mtd里面（工作原理在上面已经提过了）。对于boot.img可以通过将其拷贝到sd卡的根目录，然后通过手机内的刷写工具将此映像写入到手机中。

例如，使用adb工具将boot.img拷贝到手机的sd卡的根目录：
adb push ./mynewimage.img /sdcard
然后通过adb shell登录手机的shell交互模式，利用命令行进行交互：
# cat /dev/zero > /dev/mtd/mtd2
   write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img
然后重启手机。

如果手机能够正常启动，那么祝贺你您，你您的修改和替换已经成功了；如果不能够顺利启动，则需要重新启动进入recovery模式，并且使用update.zip来恢复。

5、解包、编辑、打包为我们带来了什么
可以修改手机开机启动时候的画面，具体的操作的地址为：
http://forum.xda-developers.com/showthread.php?t=443431

6、本文讲的内容与使用update.zip刷机包不是一码事
您可以很容易地在其他论坛上看到关于如何自制update.zip刷机包的方法，也可以下载到很多在网络上共享的自制刷机包。例如：近期的多数刷机包都来自对rc30包的修改和调整。在update.zip刷机包里面会包括新的boot.img，recovery.img以及整个system/目录下的若干文件的替换和更新。如果您希望自己自制boot.img以及recovery.img，建议您选取相对较新的更新和版本。（选用较老的映像的话，或许会出现兼容性问题）。

http://www.cublog.cn/u/26691/showart_2194274.html

手机文件系统分为不同的部分，可能如下，不同的系统顺序不同，
#cat /proc/mtd
dev:     size    erasesize   name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
我们主要涉及recovery和boot，在我们操作之前最好是备份他俩。
# cat /dev/mtd/mtd1 > /sdcard/mtd1.img
# cat /dev/mtd/mtd2 > /sdcard/mtd2.img

System存放/中挂载的所有文件，userdata中存放data目录中的数据，主要是你安装的apps及其文件。
我们最好把自己喜欢的update.zip发在sdcard的root目录中，以在弄乱boot分区后可以恢复。
有另外一个重要的文件 /system/recovery.img，他是mtd1的完全拷贝。每次关机他都会重新刷写mtd1一次，这代表你对recovery即/dev/mtd/mtd1的修改再重启后都无效。如果要改变mtd1，最好是插入image在 /system/recovery.img中，如果你升级系统没有替换 /system/recovery.img会很惨的。
Boot和recovery不是正常的文件系统，是android自定的格式，有一个2k的头，接着是gzipped的kernel和ramdisk，一个可选的second stage loader（少见）。定义在mkbootimg.h中。
+-----------------+
| boot header      | 1 page
+-----------------+
| kernel           | n pages  
+-----------------+
| ramdisk          | m pages  
+-----------------+
| second stage     | o pages
+-----------------+

n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size

0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)
Ramdisk是一个小型文件系统包含用来初始化系统的核心文件，它包含关键的初始化进程，比如init.rc（可以设定系统范围的属性），下面是ramdisk中的一系列的文件。关于ramdisk的文档如下地址
./init.trout.rc
./default.prop
./proc
./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data
Recovery image还有额外的文件，包含recovery二进制程序及其支持文件（在home+power按下重启时运行），文件如下
./res
./res/images
./res/images/progress_bar_empty_left_round.bmp
./res/images/icon_firmware_install.bmp
./res/images/indeterminate3.bmp
./res/images/progress_bar_fill.bmp
./res/images/progress_bar_left_round.bmp
./res/images/icon_error.bmp
./res/images/indeterminate1.bmp
./res/images/progress_bar_empty_right_round.bmp
./res/images/icon_firmware_error.bmp
./res/images/progress_bar_right_round.bmp
./res/images/indeterminate4.bmp
./res/images/indeterminate5.bmp
./res/images/indeterminate6.bmp
./res/images/progress_bar_empty.bmp
./res/images/indeterminate2.bmp
./res/images/icon_unpacking.bmp
./res/images/icon_installing.bmp
./sbin/recovery
解压编辑和压缩镜像
镜像中有一串00接着1F 8B，0之前为kernel，1F 8B之后为ramdisk，我们可以编辑ramdisk，不过得先un gizp它，再un cpio它。我们可以用如下命令

gunzip -c ../your-ramdisk-file | cpio -i
之后在工作目录中会有所有的ramdisk的文件，我们可以编辑它。

为了重新创建ramdisk，我们的gzip和re cpio它，所有工作目录中的文件都将被加入ramdisk中。
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

最后我们可以组合内核，使用mkbootimg程序，命令如下
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file --ramdisk newramdisk.cpio.gz -o mynewimage.img

把image刷写到手机上：
如果有新的recovery image，直接插入手机中，重启。如果是boot，得使用adb如下。
adb push ./mynewimage.img /sdcard

得到root权限。使用如下两条命令：

# cat /dev/zero > /dev/mtd/mtd2
    write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img
Reboot
如果有错误，使用update.zip重新升级。

Alternative Method
Download split_bootimg.zip . This Zip file contains one Perl file, split_bootimg.pl, which reads the boot.img header (according to the bootimg.h of the Android source code) to extract the kernel and ramdisk. The script also outputs the kernel command line and board name (if specified).
(Note: Do not use a boot.img image extracted directly from /dev/mtd/mtd2. This image may become corrupted during the read process.)
The following example uses the boot.img from the full TC4-RC28 update:
% ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
Extract the ramdisk.
% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..
Make any changes necessary (e.g., set ro.secure=0 in default.prop).
Recreate the cpio archive using the mkbootfs binary produced from building the Android source code (The cpio utility in OS X does not recognize the newc format, therefore mkbootfs is the best option for OS X users).
% mkbootfs ./ramdisk | gzip > ramdisk-new.gz
Recreate the image file using the mkbootimg binary produced from building the Android source code.
% mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img
For Nexus One : Add --base 0x20000000 to mkbootimg command-line.

(Note: the console=null command line option was introduced in the TC4-RC30 boot images to remove the root shell (TODO: add link))
Flashing your new image back onto the phone
You will probably only ever be flashing boot images directly to the phone, given the fact that /system/recovery.img automatically flashes the recovery device for you (as noted above). If you have created a new recovery image, just stick it in /system/recovery.img and reboot. If you are flashing a boot image, stick it on your phone via adb (a tool included in the Android SDK):
adb push ./mynewimage.img /sdcard
Then, open a shell to your phone via 'adb shell', get root, and do the following two commands to flash your new boot image:
# cat /dev/zero > /dev/mtd/mtd2
    write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img
Reboot.
If your phone starts all the way up, congratulations. If not, you did something wrong and you'll need to boot into recovery mode and apply your update.zip file (reboot while holding down home+power, when you get the recovery screen press alt+L and then alt+S).
Something fun to do with your new found power
If you place a file titled initlogo.rle in the root directory of your boot image, the phone will display this image upon boot (after the "G1" image and before the Android animation). In order to create this file, you need to create a 320x480 image in Photoshop or Gimp and save it as a "raw image" file. You then need to compress that image with the program to565. More details on thathere.
This is not the same thing as applying an update.zip
You will see other places on the forums that describe how to create customized update.zip files, as well as update.zip files that people are sharing. For example, there is a recent update.zip which is a modified version of rc30 (with the anti-root aspects disabled). The update.zip files include new boot images, recovery images, and typically replacements for the entire system/ directory as well as other updates. If you are creating a custom boot or recovery image, it is typically a good idea to start with the image distributed with the most recent update you have applied (flashing an image from an older release could have unintended consequences).

摘自《Android系统原理及开发要点详解》

Android启动脚本init.rc

在 Android中使用启动脚本init.rc,可以在系统的初始化过程中进行一些简单的初始化操作。这个脚本被直接安装到目标系统的根文件系统中，被 init可执行程序解析。 init.rc是在init启动后被执行的启动脚本，其语法主要包含了以下内容：

Commands：命令
Actions： 动作
Triggers:触发条件
Services：服务
Options： 选项
Propertise：属性

(1) Commands是一些基本的操作，例如：
    mkdir /sdcard 0000 system system
    mkdir /system
    mkdir /data 0771 system system
    mkdir /cache 0770 system cache
    mkdir /config 0500 root root
    mkdir /sqlite_stmt_journals 01777 root root
    mount tmpfs tmpfs /sqlite_stmt_journals size=4m
这些命令在init可执行程序中被解析，然后调用相关的函数来实现。

(2) Actions(动作)表示一系列的命令，通常在Triggers（触发条件）中调用，动作和触发条件的形式为：
   on <trigger>
      <command>
      <command>
      <command>

动作的使用示例如下：
    on init
    export PATH /sbin:/system/sbin:/system/bin:/system/xbin
    mkdir /system
init表示一个触发条件，这个触发事件发生后，进行设置环境变量和建立目录的操作称为一个“动作”

(3) Services（服务）通常表示启动一个可执行程序，Options（选项）是服务的附加内容，用于配合服务使用。

service vold /system/bin/vold
    socket vold stream 0660 root mount

service bootsound /system/bin/playmp3
    user media
    group audio
    oneshot

vold和bootsound分别是两个服务的名称，/system/bin/vold和/system /bin/playmp3分别是他们所对应的可执行程序。
socket、user、group、oneshot就是配合服务使用的选项。其中oneshot选项表示该服务只启动一次，而如果没有oneshot选项，
这个可执行程序会一直存在--如果可执行程序被杀死，则会重新启动。

(4) Properties（属性）是系统中使用的一些值，可以进行设置和读取。

    setprop ro.FOREGROUND_APP_MEM 1536
    setprop ro.VISIBLE_APP_MEM 2048
    on property:ro.kernel.qemu=1
    start adbd
setprop 用于设置属性，on property可以用于判断属性，这里的属性在整个Android系统运行中都是一致的。

init脚本的关键字可以参考init进程的system/core/init/keyword.h文件。
init.rc的使用方法，可以参考说明文件system/core/init/readme.txt

如果想要修改启动过程只需要修改init.c（system/core/init）或者init.rc里的内容即可.


附录：system/core/init/readme.txt

Android Init Language
---------------------

The Android Init Language consists of four broad classes of statements,
which are Actions, Commands, Services, and Options.

All of these are line-oriented, consisting of tokens separated by
whitespace. The c-style backslash escapes may be used to insert
whitespace into a token. Double quotes may also be used to prevent
whitespace from breaking text into multiple tokens. The backslash,
when it is the last character on a line, may be used for line-folding.

Lines which start with a # (leading whitespace allowed) are comments.

Actions and Services implicitly declare a new section. All commands
or options belong to the section most recently declared. Commands
or options before the first section are ignored.

Actions and Services have unique names. If a second Action or Service
is declared with the same name as an existing one, it is ignored as
an error. (??? should we override instead)

Actions
-------
Actions are named sequences of commands. Actions have a trigger which
is used to determine when the action should occur. When an event
occurs which matches an action's trigger, that action is added to
the tail of a to-be-executed queue (unless it is already on the
queue).

Each action in the queue is dequeued in sequence and each command in
that action is executed in sequence. Init handles other activities
(device creation/destruction, property setting, process restarting)
"between" the execution of the commands in activities.

Actions take the form of:

on <trigger>
   <command>
   <command>
   <command>

Services
--------
Services are programs which init launches and (optionally) restarts
when they exit. Services take the form of:

service <name> <pathname> [ <argument> ]*
   <option>
   <option>
   ...

Options
-------
Options are modifiers to services. They affect how and when init
runs the service.

critical
   This is a device-critical service. If it exits more than four times in
   four minutes, the device will reboot into recovery mode.

disabled
   This service will not automatically start with its class.
   It must be explicitly started by name.

setenv <name> <value>
   Set the environment variable <name> to <value> in the launched process.

socket <name> <type> <perm> [ <user> [ <group> ] ]
   Create a unix domain socket named /dev/socket/<name> and pass
   its fd to the launched process. <type> must be "dgram" or "stream".
   User and group default to 0.

user <username>
   Change to username before exec'ing this service.
   Currently defaults to root. (??? probably should default to nobody)
   Currently, if your process requires linux capabilities then you cannot use
   this command. You must instead request the capabilities in-process while
   still root, and then drop to your desired uid.

group <groupname> [ <groupname> ]*
   Change to groupname before exec'ing this service. Additional
   groupnames beyond the (required) first one are used to set the
   supplemental groups of the process (via setgroups()).
   Currently defaults to root. (??? probably should default to nobody)

oneshot
   Do not restart the service when it exits.

class <name>
   Specify a class name for the service. All services in a
   named class may be started or stopped together. A service
   is in the class "default" if one is not specified via the
   class option.

onrestart
    Execute a Command (see below) when service restarts.

Triggers
--------
   Triggers are strings which can be used to match certain kinds
   of events and used to cause an action to occur.

boot
   This is the first trigger that will occur when init starts
   (after /init.conf is loaded)

<name>=<value>
   Triggers of this form occur when the property <name> is set
   to the specific value <value>.

device-added-<path>
device-removed-<path>
   Triggers of these forms occur when a device node is added
   or removed.

service-exited-<name>
   Triggers of this form occur when the specified service exits.

Commands
--------

exec <path> [ <argument> ]*
   Fork and execute a program (<path>). This will block until
   the program completes execution. It is best to avoid exec
   as unlike the builtin commands, it runs the risk of getting
   init "stuck". (??? maybe there should be a timeout?)

export <name> <value>
   Set the environment variable <name> equal to <value> in the
   global environment (which will be inherited by all processes
   started after this command is executed)

ifup <interface>
   Bring the network interface <interface> online.

import <filename>
   Parse an init config file, extending the current configuration.

hostname <name>
   Set the host name.

chdir <directory>
   Change working directory.

chmod <octal-mode> <path>
   Change file access permissions.

chown <owner> <group> <path>
   Change file owner and group.

chroot <directory>
Change process root directory.

class_start <serviceclass>
   Start all services of the specified class if they are
   not already running.

class_stop <serviceclass>
   Stop all services of the specified class if they are
   currently running.

domainname <name>
   Set the domain name.

insmod <path>
   Install the module at <path>

mkdir <path> [mode] [owner] [group]
   Create a directory at <path>, optionally with the given mode, owner, and
   group. If not provided, the directory is created with permissions 755 and
   owned by the root user and root group.

mount <type> <device> <dir> [ <mountoption> ]*
   Attempt to mount the named device at the directory <dir>
   <device> may be of the form mtd@name to specify a mtd block
   device by name.
   <mountoption>s include "ro", "rw", "remount", "noatime", ...

setkey
   TBD

setprop <name> <value>
   Set system property <name> to <value>.

setrlimit <resource> <cur> <max>
   Set the rlimit for a resource.

start <service>
   Start a service running if it is not already running.

stop <service>
   Stop a service from running if it is currently running.

symlink <target> <path>
   Create a symbolic link at <path> with the value <target>

sysclktz <mins_west_of_gmt>
   Set the system clock base (0 if system clock ticks in GMT)

trigger <event>
   Trigger an event. Used to queue an action from another
   action.

write <path> <string> [ <string> ]*
   Open the file at <path> and write one or more strings
   to it with write(2)

Properties
----------
Init updates some system properties to provide some insight into
what it's doing:

init.action
   Equal to the name of the action currently being executed or "" if none

init.command
   Equal to the command being executed or "" if none.

init.svc.<name>
   State of a named service ("stopped", "running", "restarting")

Example init.conf
-----------------

# not complete -- just providing some examples of usage
#
on boot
   export PATH /sbin:/system/sbin:/system/bin
   export LD_LIBRARY_PATH /system/lib

   mkdir /dev
   mkdir /proc
   mkdir /sys

   mount tmpfs tmpfs /dev
   mkdir /dev/pts
   mkdir /dev/socket
   mount devpts devpts /dev/pts
   mount proc proc /proc
   mount sysfs sysfs /sys

   write /proc/cpu/alignment 4

   ifup lo

   hostname localhost
   domainname localhost

   mount yaffs2 mtd@system /system
   mount yaffs2 mtd@userdata /data

   import /system/etc/init.conf

   class_start default

service adbd /sbin/adbd
   user adb
   group adb

service usbd /system/bin/usbd -r
   user usbd
   group usbd
   socket usbd 666

service zygote /system/bin/app_process -Xzygote /system/bin --zygote
   socket zygote 666

service runtime /system/bin/runtime
   user system
   group system

on device-added-/dev/compass
   start akmd

on device-removed-/dev/compass
   stop akmd

service akmd /sbin/akmd
   disabled
   user akmd
   group akmd

Debugging notes
---------------
By default, programs executed by init will drop stdout and stderr into
/dev/null. To help with debugging, you can execute your program via the
Andoird program logwrapper. This will redirect stdout/stderr into the
Android logging system (accessed via logcat).

For example
service akmd /system/bin/logwrapper /sbin/akmd