从CM刷机过程和原理分析Android系统结构.doc

从CM刷机过程和原理分析Android系统结构 前面的文章都是分析Android系统源码，似乎不够接地气。如果能让Android系统源码在真实设备上跑跑看效果，那该多好。这不就是传说中的刷ROM吗？刷ROM这个话题是老罗以前一直避免谈的，因为觉得没有全面了解Android系统前就谈ROM是不完整的。写完了101篇文章后，老罗觉得第102篇文章该谈谈这个话题了，并且选择CM这个有代表性的ROM来谈，目标是加深大家对Android系统的了解。 说起刷ROM的动机，除了上面说的用来看Android系统源码在真实设备上的运行效果，还有很多值得说的。回想起PC时代，我们对我们自己拥有的设备（电脑），基本上能做的就是在上面重装系统。这个系统是厂商做好给我们的，里面有什么我们就用什么，不能随心所欲地定制。当然，如果你用的是Linux系统，你是可以随心所欲地对它进行定制的。不过可惜的是，我们的女神用的都是Windows系统。你和女神说你想要什么样的Linux系统，我给你定制一个，她会不知道你说的是什么——她需要的是一个不会中毒的又跑得快的Windows系统而已。现如今虽然很多女神用的是仍然是我们不能随心所欲定制的iOS系统，但是在移动设备上，iOS系统毕竟不能做到Windows在PC那样的一家独大——我们还有不少女神是用Android系统的。所以，如果你现在和女神说，我可以帮你刷一个专属的精简Android系统，里面没有一堆你不需要的预装软件，会让你的手机跑得很快，那女神得有多崇拜你啊。 当然，刷ROM的动机不能只是为了让女神崇拜，作为一个程序猿，我们的首要任务是维护宇宙和平。怎么维护呢？至少程序有BUG不能不改吧。你不改的话，老板是不会放过你的。但是，碰到那些很棘手的BUG，怎么办呢？例如，你是一个Android应用开发者，调用一个API接口的时候，总是抛出一个异常，而这个异常不跟到API内部实现去看看实在是不知道什么原因造成的。这时候，如果你手头上有这个手机的系统源代码，找这个API内部实现的地方，加一两行调试代码，再编译回手机上去跑，是不是就很容易定位问题了呢？ 所以说，会刷ROM，不只是可以获得女神崇拜，还可以维护世界和平，作为一个Android开发者，你还有什么理由不去学习刷ROM呢？既然你决定学习刷ROM了，那你就得先搞清楚两个问题：1. 什么是刷ROM；2. 怎么学习刷ROM。 在回答第一个问题之前，我们先来看看Android设备从硬件到系统的结构，如图1所示： 最底层的是各种硬件设备，往上一层是Bootloader。Bootloader是什么概念呢？我们都知道，PC主板上有一小段程序叫做BIOS，主板加电时它是第一个跑起来的程序，负责初始化硬件，以及将OS启动起来。在嵌入式世界里（手机也是属于嵌入式设备），也有一小段类似BIOS的程序，不过它不叫BIOS，而是叫Bootloader。使用最广泛的Bootloader是一个叫uboot的程序，它支持非常多的体系结构。经过编译后，uboot会生成一个uboot.bin镜像，将这个镜像烧到设备上的一个特定分区去，就可以作为Bootloader使用了。 Bootloader支持交互式启动，也就是我们可以让Bootloader初始化完成硬件之后，不是马上去启动OS，而是停留在当前状态，等待用户输入命令告诉它接下来该干什么。这种启动模块就称为Fastboot模式。对于Android设备来说，我们可以通过adb reboot bootloader命令来让它重新启动并且进入到Fastboot模式中去。 在讨论Fastboot模式之前，我们先了解一下嵌入式设备的ROM结构（NAND flash之类的芯片）。通常，一个能够正常启动的嵌入式设备的ROM包含有以下四个分区： 1. Bootloader分区，也就是存放uboot.bin的分区 2. Bootloader用来保存环境变量的分区 3. Kernel分区，也就是存放OS内核的分区 4. Rootfs分区，也就是存入系统第一个进程init对应的程序的分区 当设备处于Fastboot模式时，我们可以通过另外一个工具fastboot来让设备执行指定的命令。对搞机者来说，最常用的命令就是刷入各种镜像文件了，例如，往Kernel分区和Rootfs分区刷入指定的镜像。 对于Android设备来说，当它处于Fastboot模式时，我们可以将一个包含有Kernel和Rootfs的Recovery.img镜像通过fastboot工具刷入到