【JK团队|MIUI移植第三课】寻找合适的原厂ROM

第三章寻找合适的原厂ROM

1.熟悉移植的机型
“千里之行，始于足下”。做移植之前，首先得熟悉我们要移植的机型。
1.1逛论坛刷机
想要打人先学会被打，想做刷机包先学会刷机。先去各大论坛逛逛，了解你的机型是如何刷机的。在这里，不得不提到一个必逛的论坛：http://forum.xda-developers.com/。这是国外的一个手机论坛，该论坛技术性强，用户富有分享精神，机型全面。

这个期间一定要掌握所在机型的刷机方法，需要用到什么工具，多刷几个ROM玩玩，尽量熟悉刷机过程。

1.2合适的原厂ROM
在第一步熟悉了要移植的机型，刷了这大那大出的ROM后，接下来我们要开始集中精力寻找一个合适的原厂ROM，因为一般来说，原厂ROM的稳定性最好。这个时候能找到那种在原厂ROM的基础上仅做过ROOT和deodex的版本是最好的（下面会详细介绍何为ROOT和deodex）。

那么如何判断一个原厂ROM是否合适呢：
首先要版本合适，我们这个系列谈论的是基于原厂ROM移植MIUI，目前2.3的MIUI是基于android2.3.7源码开发的，从android2.3.3到android2.3.7这几个版本变化都不太大，因此2.3.3到2.3.7的原厂ROM版本都是合适的。

其次检查所安装的ROM是否有root权限。
root权限分两种：
第一种是手机root：这种root权限的外在表现是你的手机上安装了一个授权管理软件。、第二种是内核root：这种root权限的外在表现如下：
在UbuntuShell下运行如下命令：
$adbroot（该命令的含义是以root权限运行adb)
$adbremount（该命令的含义是将system分区的权限设成可读可写）
如果这两条命令都成功，表明是内核root。运行adbshell，可以看到手机shell提示符为#。

如果上述两条命令失败，运行adbshell可以看到手机shell提示符为$。如果此时运行su命令，手机弹出是否授予root权限，这说明手机上安装了授权管理程序。这种情况下运行su命令后，手机shell提示符也会变为#。

在之后的章节我们会看到，定制MIUIROM的关键是能修改system分区的内容，这两 种root权限都可以将system分区设成可读写的，只是内核root权限提供了最大的方便性，强烈推荐找到一个内核root过的ROM。

patchrom项目提供的工具和脚本是基于你的手机获取了内核root权限，如果是手机root，也是可以的，但是需要修改一下脚本。因为只是手机root，adbremount命令会失败。这个时候需要在手机shell里重新remountsystem分区，并且修改system的目录权限，这样才能修改system分区的内容，而且需要修改我们提供的某些脚本。（之后不针对只有手机root权限做出特殊说明，我们相信你知道如何在这种模式下修改system分区）。

最后检查所选择的ROM可以进入Recovery模式刷机，不一定要求必需是CWMRecovery,有wipedata/cache和安装zip包等功能的简单Recovery就可以，当然有CWMRecovery更好。针对每个机型，要想自动生成MIUIROM刷机包，我们要求对每个机型提供一个ZIP格式的刷机包，该刷机包可以通过Recovery安装。对于有的机型，如果没有找到可以通过Recovery安装的ZIP包怎么办，不用担心，我们在第七章中会介绍如何在手机现有系统的基础上制作ZIP包。

1.3 adblogcat
在第一章介绍过adb是一个非常重要的命令，其中在机型适配过程中我们最常用的就是adblogcat。通过这个命令我们可以看到详细的log信息。
每一行的大致格式为：
I/ActivityManager(585):Startingactivity:Intent{action=android.intent.action…}
其中第一个字母表示信息优先级别（E表示错误，W表示警告，I表示普通信息等）。

斜杠后的ActivityManager表示信息标记tag，通常标记表示了打印出相应信息的模块或程序。可以通过adblogcattag:**:S只显示相应tag打印的所有信息。
括号中的数字表示进程ID(pid)，表示程序所在的进程ID。

冒号后的句子就是具体的信息说明了，当我们遇到错误的时候adblogcat会给出详细的错误信息，我们通过这些错误信息去定位错误。

在机型适配中常用adblogcat*:E来查看所有的错误信息。

详细的adb说明可以参考http://developer.android.com/guide/developing/tools/adb.html。在选定好ROM之后，我们要确保在开机之初，差不多是显示开机动画时adblogcat命令就能显示详细的log信息，如果adblogcat只是在桌面程序出现之后才打印信息或者根本不打印任何信息，移植工作很难进行下去。

如果只是简单的修改一些图片资源的话可以，但是对于适配MIUI来说我们要求在适配机型一开始就确保adblogcat功能的正常运行。

2.修改boot.img
在第二章认识Android手机中我们提到过，内核root的关键是根文件系统中default.prop文件的两个属性ro.secure和ro.debuggable的值。

根文件系统和内核一起放在boot分区中，如果我们能够修改boot分区中的这个文件，那么我们就可以自己root内核了。

下面介绍一个root内核的办法，一般来说某个机型的完整刷机包下有一个boot.img文件，该文件就是boot分区的镜像文件，安装刷机包时，会使用该文件刷写boot分区。

google给boot.img文件定义了一个标准的格式，如果遵从这个标准格式，我们可以用下面的办法来修改它，但是如果不遵从，需要逛论坛详细的了解如何修改boot分区。有的机型遵从，比如说华为的u8800，有的机型不遵从，比如说三星的i9100,i9000等。

判断是否遵从有一个简单但不是一定准确的办法，如果刷机包中的文件名为boot.img，一般来说遵从。

如果不是，那么不遵从。比如说三星的i9100的刷机包中这个文件命名为zImage（可以在xda论坛上找到详细的修改zImage的教程）。

假定我们在patchrom目录下，给定一个boot.img，运行如下命令：
$tools/unpackbootimg-iboot.img
输出类似如下文字：
BOARD_KERNEL_CMDLINEconsole=ttyDCC0androidboot.hardware=xxx
BOARD_KERNEL_BASE00200000
BOARD_PAGE_SIZE4096
如果这些输出有乱码，那么可以判定该boot.img不遵从标准格式。记下这些参数，接下来还要用到。

同时在patchrom目录下会看到一个boot.img-ramdisk.gz文件，该文件即是根文件系统的压缩包。还有一个boot.img-kernel文件，该文件即是Linux内核。
$mkdirramdisk
$cdramdisk
$gzip-dc../boo.img-ramdisk.gz|cpio-i
运行这三个命令后，ramdisk目录即为手机启动后的根文件系统目录，用任何编辑器修改default.prop文件。
$cd..
$tools/mkbootfs./ramdisk|gzip>ramdisk-new.gz
将ramdisk目录重新打包。
$tools/mkbootimg–cmdline’console=ttyDCC0androidboot.hardware=xxx’–kernelboot.img-kernel–ramdiskramdisk-new.gz–base0x00200000–pagesize4096-oboot-new.img运行该命令生成新的boot.img，
–cmdline:该选项为之前打印的BOARD_KERNEL_CMDLINE
–kernel：该选项为Linux内核文件
–ramdisk：该选项为根文件系统压缩包
–base：该选项为之前打印的BOARD_KERNEL_BASE
–pagesize：该选项为之前打印的BOARD_PAGE_SIZE
-o：该选项为输出文件名

3.deodex
当我们把要移植的机型按照上述步骤刷好了合适的原厂ROM后，第一件事就是需要做deodex。什么是deodex？啊，这真的是一个longlongstory。

话说Android发明之日起，准备让开发人员使用Java语言来在Android手机平台上进行应用程序开发（为什么用Java,Java程序员大喊道，谁用谁知道呀）。

Java程序一般使用java编译器(javac命令）从源文件(.java结尾的文件)编译成类文件(.class结尾的文件，又被称作字节码)，然后很多类文件被打包成一个JAR包（JAR包实际是一个zip压缩包），然后用java虚拟机解释执行这些类文件。

采用类文件格式以及使用标准的Java虚拟机需要向Java的所有者（当时是SUN公司，后来被Oracle公司收购，默哀一下）缴纳授权费用并遵守相应的版权协议。

Google不想缴纳这笔费用并受协议的约束，于是这丫想出来一个“偷天换日，偷梁换柱”的方法，用的是Java的壳，但是那颗心已不是Java的心（正是因为google绕过了Java授权，所以现在Oracle紧咬着google打官司）。

简单来说，就是当编译Android上的Java程序时，第一步还是编译成类文件打包成JAR包，然后会将这个JAR包转换为一个叫classes.dex的文件，这个dex文件是什么玩意呢，这是google发明出来的一个用于它自己的虚拟机上的一个字节码文件格式。Android上得这个虚拟机就叫做dalvik虚拟机（dalvik是冰岛的一个小镇的名字，当时google的工程师在给这个虚拟机苦思冥想一个名字，后来一个主要的工程师DanBronstein我的祖先当初生活在冰岛的这个小镇，就以它命名吧。

据说Dan本人从没去过冰岛，Android发布后，冰岛很是骄傲，当地的报纸专门登载了这件事并热切欢迎Dan回乡探亲）。那么odex是啥呢，它叫optimizeddex，即优化过的dex文件。讲了这么多，你只需要理解odex是一种优化过的dex文件就行了，至于怎么优化的不在我们讲述的范围内。

odex文件是互相依赖的，简单的理解就是我们改了其中一个文件，其它的odex文件就不起作用了。为此，我们必须做一个deodex操作，就是将odex文件变为dex文件，让这些文件可以独立修改。

一般来说原厂ROM发布时都是以odex文件格式发布的，如何判断呢。运行如下命令:$adbshellls/system/framework
如果看到很多以odex结尾的文件，那么该ROM就是做过odex的，大家可以用patchrom/tools目录下的deodex.sh脚本来自动的做deodex操作。

Windows用户可以下载http://www.xeudoxus.com/android/xUltimate-v2.3.3.zip这个工具来做deodex，具体的用法请参照该工具的帮助文档。