ROM刷机原理及ROM制作技术初探

这一段时间刷了一堆ROM，安卓系列、CM、Hero、OldMos、隔壁新出的Android2.0，反正都尝了一下鲜。我的手机的照相机也刷得再也启不来了（不知道什么原因，杯具）。
有话说：“久病成良医”，想我们折腾了这么久的刷机，也得总结总结不是，小弟不才，远没成“良医”，但还是想把自己的一些认识和心得写出来，以期抛砖引玉...

一、刷机原理
记得第一次刷机，哪个心理紧张啊。其实紧张什么呢？就是因为不明白原理啊，只看到一堆的教程来依葫芦画瓢，生怕错了一步将手机变砖。
真正使我对刷机原理有一些理解的是看了这一篇文章：/adp.html
说起来，刷机就是两种方法：
一是recovery方法，就是我们平时将update.zip入到SD卡，然后alt-s的方法，这种方法是调用了recovery的方法将各种img或文件进行复制等操作。想了解recovery的工作原理吗？我也没找到好的资料，就在这看了看recovery的一些源码：/rowboat/bootable-recovery/commit/64893ccc09b25ac31bc6a17f5c7f43c7fa789576
二是fastboot方法，这个方法其实是比较酷的方法，说白点，fastboot就是将已有的各分区映象文件（img文件，意义上类似我们对光盘做的映象文件）直接覆盖写到指定分区中，有点暴力，也有点类似我们平时操作系统的Ghost还原。

这两种方法哪种更好，这就不好比高低了，总的来说：
Recovery方法更简单，只需要傻瓜式的将update.zip放到SD卡的要目录下，然后进入Recovery模式alt-s就可以了，但和任何傻瓜式东西一样，他的灵活度就很小了，而且出错了也都不知道如何解决。一般来说做Rom的高手为了保证Rom的可靠性，在安装程序中都会对一些安装环境进行一些确定，而各位的手机环境又是千变万化的，Rom高手也很难考虑周全，另外，Recovery程序本身也有一些环境验证。前一段时间很多人刷阿兴的3.0失败应该都可以归结于这些原因。
fastboot方法更灵活，功能也更强大，fastboot方法不需要依赖于recovery，甚至linux底层刷坏了recovery模式都进不了的情况下也可以通过fastboot方工刷回来。fastboot模式其实是调用spl进行刷机的，所以如果刷spl坏了，fastboot模式应该也进不了，也就是砖了。fastboot方法需要各位电脑上有fastboot程序，同时手机要进入fastboot模式才可以操作，关于这些知识，请参见google。


二、回头再来说说Android系统中的各分区（分区这个说法是不是不太准确？）
我了解到的Android系统中的分区有：
hboot（我们刷的SPL就是这玩意），这个分区是最基本的引导分区（类似电脑中的BIOS？），这个区坏了，差不多就变砖了，所以我们刷SPL时才要如此小心啊。
boot，这个分区

是linux操作系统的引导分区吧？
radio，这个分区是手机的一些底层设备相关的驱动或功能程序吧，如打电话和发短信等，不同的系统版本会有不同的radio配套，我们平时刷了高版本的ROM后，如果不刷高版本的Radio就有可能导致打电话不正常之类的。（在/adp.html这个文章中，就有不同android版本与之配套的不同版本Radio）
recovery，这个分区装的就是前面提到的recovery程序了，这个刷不同的recovery版本可以带来不同的功能，有兴趣的同学可以基于recovery的源码自己编译出一个自己的recovery出来？但一般来说，刷recovery最主要的就是提Root权限吧。
system，是一般发布的ROM的主要功能程序分区了，我们说的ROM功能和自带程序的定制应该就是基于这个分区的修改和编译了。
userdata，用户数据，不说了。
cache，缓存，不说了，一般是用来OTA升级时的缓存，我们说刷SPL可以增加程序区的空间大小就是主要将这个区的大小缩水了然后加大了程序区的分区大小。

三、一个典型ROM的剖析
我们平时升级的Rom都是打包成适合Recovery方式刷机的包。能够被Recovery程序识别并处理的包应该有一个固定的格式，我理解的一些重要的约束如下：
1）必须是标准的zip压缩包；
2）recovery脚本必须存入在META-INF\com\google\android\update-script；
3）其它的一些证书和签名信息应该都放在\META-INF\下；

我们先来看看阿兴的3.0的recovery脚本： show_progress 0.500000 0 //显示进度度

format SYSTEM://格式化system分区

copy_dir PACKAGE:system SYSTEM://将Rom包中system目录所有内容copy到system分区



//以下就是对复制的文件进行一些属性和权限设定了



symlink dumpstate SYSTEM:bin/bugreport

symlink dumpstate SYSTEM:bin/dumpcrash

symlink toolbox SYSTEM:bin/cat

symlink toolbox SYSTEM:bin/chmod

symlink toolbox SYSTEM:bin/chown

symlink toolbox SYSTEM:bin/cmp

symlink toolbox SYSTEM:bin/date

symlink toolbox SYSTEM:bin/dd

symlink toolbox SYSTEM:bin/df

symlink toolbox SYSTEM:bin/dmesg

symlink toolbox SYSTEM:bin/getevent

symlink toolbox SYSTEM:bin/getprop

symlink toolbox SYSTEM:bin/hd

symlink toolbox SYSTEM:bin/id

symlink toolbox SYSTEM:bin/ifconfig

symlink toolbox SYSTEM:bin/iftop

symlink toolbox SYSTEM:bin/insmod

symlink toolbox SYSTEM:bin/ioctl

symlink toolbox SYSTEM:bin/kill

symlink toolbox SYSTEM:bin/ln

symlink toolbox SYSTEM:bin/log

symlink toolbox SYSTEM:bin/ls

symlink toolbox SYSTEM:bin/lsmod

symlink toolbox SYSTEM:bin/mkdir

symlink toolbox SYSTEM:bin/mount

symlink toolbox SYSTEM:bin/mv

symlink toolbox SYSTEM:bin/netstat

symlink toolbox SYSTEM:bin/newfs_msdos

symlink toolbox SYSTEM:bin/notify

symlink toolbox SYSTEM:bin/printenv

symlink toolbox SYSTEM:bin/ps

syml

ink toolbox SYSTEM:bin/reboot

symlink toolbox SYSTEM:bin/renice

symlink toolbox SYSTEM:bin/rm

symlink toolbox SYSTEM:bin/rmdir

symlink toolbox SYSTEM:bin/rmmod

symlink toolbox SYSTEM:bin/route

symlink toolbox SYSTEM:bin/schedtop

symlink toolbox SYSTEM:bin/sendevent

symlink toolbox SYSTEM:bin/setconsole

symlink toolbox SYSTEM:bin/setprop

symlink toolbox SYSTEM:bin/sleep

symlink toolbox SYSTEM:bin/smd

symlink toolbox SYSTEM:bin/start

symlink toolbox SYSTEM:bin/stop

symlink toolbox SYSTEM:bin/sync

symlink toolbox SYSTEM:bin/top

symlink toolbox SYSTEM:bin/umount

symlink toolbox SYSTEM:bin/vmstat

symlink toolbox SYSTEM:bin/watchprops

symlink toolbox SYSTEM:bin/wipe

set_perm_recursive 0 0 0755 0644 SYSTEM:

set_perm_recursive 0 2000 0755 0755 SYSTEM:bin

set_perm 0 3003 02755 SYSTEM:bin/netcfg

set_perm 0 3004 02755 SYSTEM:bin/ping

set_perm 0 0 04755 SYSTEM:bin/su

set_perm 1001 1005 0440 SYSTEM:etc/AudioPara4.csv

set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluez

set_perm 0 0 0755 SYSTEM:etc/bluez

set_perm_recursive 0 2000 0755 0755 SYSTEM:etc/init.d

set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf

set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks

set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh

set_perm_recursive 0 0 0755 0555 SYSTEM:etc/ppp



show_progress 0.200000 0 //再次显示进度

delete_recursive DATA:dalvik-cache

copy_dir PACKAGE:data DATA:

set_perm_recursive 1000 1000 0771 0555 DATA:dalvik-cache



write_raw_image PACKAGE:boot.img BOOT://将Rom包中boot.img镜像文件直接刷到boot分区

//没有看到写其它的镜像分区了，看论坛上有人说阿兴的Rom强制写了recovery分区，没看到代码啊，冤情了阿兴吧



show_progress 0.200000 10
复制代码大家看了以上的Rom update脚本后，应该明白其实Rom升级的行为并不神秘了吧。
其实就是依据recovery提供的命令来写一段脚本，这些命令也还都能从字面上明白大概是做什么的，但具体这些命令的参数及行为细节，我也没有找到相关的文档了，只是从前文提供的recovery源码中大概看了一下。如果各位想自己动手做Rom，想必这些脚本命令还是得搞清楚的。

另外，我们明白了Rom的组成后，我们就应该能够很清楚的知道一个Rom到底会做什么了。例如阿兴的3.0Rom，除了写android的系统外，再默认装了一些程序外，再刷了一下Boot分区外（这个这次是必须的），确实没做什么了。

另外，一个Rom中到底还内置哪些默认程序呢，我们可以打开Rom中的子目录看看就知道了，如阿兴的Rom中就放了这些程序：
system\app\HiApkMarket.apk，安卓市场
...

四、我们有没有可能自己定制ROM呢
理论上我们是可以自己定制的。
最简单的定制应该就是拿一个现有的认为还不错的基础ROM，替换一些资源，

加一些系统自带程序，然后打包发布；
再玩高级一点，就应该自己去修改一些系统自带的程序，如汉化一些系统原始程序；
还玩高级一点，就应该自己到android官方站点去下载android系统的源码来编译，并基于系统级的定制和移植了，如现在火热的android2.0源码编译系统移植。

如果是简单一点的自制ROM，主要应该会要解决如下几个问题：

1）选定一个比较好和稳定的内核和基础
就用阿兴3.0包中的吧，就是update.zip包中的哪个boot.img
另外，system目录中大部分也是直接可用的，就可以作为自定义Rom的基础。

2）修改系统
同样也可以基于阿兴的3.0包来改，例如可以这样来定制的东西：
system\etc\apns-conf.xml，这是设置APN接入点的；
system\etc\hosts，这是设置Host文件的，现在有很多人用阿兴的包绑定不了GMail，就可以在这个Host文件中增加一条：74.125.93.113 （当然，这个地址用能多信也不好说）
...还有什么东西要自己去定制就自己去翻看瞧瞧。

3）Rom的重新打包签名
前文已经介绍了一个Rom包的基本结构，但完全按照这个结构打包还是不能被Recovery安装的，因为没有签名！
Rom签名可以下载一个自动签名工具Auto-sign，具体到哪下，请Google。（注：Rom签名工具需要Java1.6支持，所以系统还得有JRE1.6的环境）