1. 搭建移植环境

“工欲善其事，必先利其器”。在制作自己的ROM之前我们必须做好准备工作，搭建好移植环境。

我们这个系列的主旨是如何基于原厂ROM修改。我们所涉及的修改理论上说是不需要源码的，对源码开发感兴趣的可以参照http://source.android.com。对于ROM制作者来说，我们建议你下载一份google发布的android源代码，这不是必需的，但是对于理解排查ROM适配中的一些错误有很大帮助。

1.1 选择操作系统
我们MIUI开发组做ROM开发使用的系统是Ubuntu 10以上版本。做ROM移植，Windows(Windows XP和Windows 7)和Mac都可以。但是由于开发组的日常使用是Ubuntu系统，我们将要共享的一些脚本程序都是运行在Ubuntu之上的，以后的介绍基本上是基于Ubuntu的，同时我会尽力提及在Windows下的操作。Mac我用得非常少，这方面很抱歉。但是用Mac来移植是完全可以的，大家可以根据本文介绍所需要的工具，参照网上的一些资料来搭建Mac移植环境。

1.2 安装Android SDK

关于在Linux, Windows和Mac上详细的如何安装Android SDK的介绍请参照http://developer.android.com/sdk/installing.html。（有人嚷，看不懂鸟语怎么办，首先我真诚的觉得做ROM移植还是懂点基本的鸟语好，第二我必须得承认不懂鸟语也是可以做ROM移植的。这种情况请大家去google搜索一下，网上有很多如何安装Android SDK的中文介绍。）

为了验证这一步是否成功，打开手机中的系统设置，选择应用程序—开发，确保选中“USB调试”，然后用USB线连接你的手机，在Ubuntu Shell或Windows控制台下运行命令adb devices，如果显示和下面的信息类似，恭喜你，adb可以识别你的手机了。
List of devices attached
304D1955996BE28E    device
注意：
(1) 有可能会提示找不到adb，这个时候请确保将adb所在路径添加到系统的环境变量中。
(2) 在Windows下，必须安装手机相应的驱动才能成功识别手机。
(3) 在Ubuntu下，有可能会提示“no such permissions”，这个时候有两种办法，第一种是以root的身份运行。第二种办法：
(3.1) 运行lsusb命令，对于我的三星手机，输出如下：
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 098: ID 04e8:685e Samsung Electronics Co., Ltd
。。。
找到手机对应的那一行，记录下04e8:685e，这个分别表示该设备的vendorId和productId。如果不确定手机对应的是哪一行，可以在连上手机前后运行lsusb，找到区别的那一行。
(3.2) 在/etc/udev/rules.d目录下新建一个文件99-android.rules。编辑如下：
SUBSYSTEMS==”usb”, ATTRS{idVendor}=”04e8″, ATTRS{idProduct}=”685e”, MODE=”0666″, OWNER=”你的登录身份”
(3.3) 重启usb服务，sudo restart udev，重连手机。

adb在我们的移植过程中扮演非常重要的角色，它和接下来要介绍的apktool是移植工作中的双子星座，都是行走江湖必备利器。在以后的章节中我们会多次和它相遇。

1.3 apktool和baksmali/smali
首先建议大家新建一个目录tools，把将要下载的工具都放在这个目录中。

apktool: 这个是我们修改ROM最重要的工具，没有之一。我们会在下一章整篇文章中详细的介绍它。地址：http://code.google.com/p/android-apktool/
smali/baksmali: 它们是Android下dalvik虚拟机的汇编/反汇编器。apktool实际上是基于smali/baksmali的封装，在下一节中我们会介绍它们的使用场合。地址：http://code.google.com/p/smali/

2. 熟悉移植的机型

“千里之行，始于足下”。做移植之前，首先得熟悉我们要移植的机型。

2.1 逛论坛刷机

想打人先学会被打，想做刷机包先学会刷机。先去各大论坛逛逛，了解你的机型是如何刷机的。在这里，不得不提到一个必逛的论坛：http://forum.xda-developers.com/。

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

2.2 寻找合适的原厂ROM，确保root

什么是合适的原厂ROM呢，首先要版本合适，我们这个系列谈论的是基于原厂ROM移植MIUI，目前2.3的MIUI是基于android2.3.7源码开发的，从android2.3.3到android2.3.7这几个版本变化都不太大，因此2.3.3到2.3.7的原厂ROM版本都是合适的。4.0的MIUI在移植时我们也会给出MIUI基于哪一android4.0版本的源码开发的。

其次检查所安装的ROM是否有root权限。root权限分两种：
一种是手机root：这种root权限外在表现是你的手机上安装了一个授权管理软件，当你使用RE管理器的时候会弹出一个对话框询问是否授予root权限。
一种是内核root: 这种是上一种root权限的超集。
判断上述哪种root权限的方法，在Ubuntu Shell或Windows控制台下运行如下命令：
adb root（该命令的含义是以root权限运行adb)
adb remount（该命令的含义是将system分区的权限设成可读写）
如果这两条命令都成功，是内核root。运行adb shell，可以看到手机shell提示符为#。
如果上述两条命令失败，运行adb shell可以看到手机shell提示符为$。如果此时运行su命令，手机弹出是否授予root权限，这说明手机上安装了授权管理程序。这种情况下运行su命令后，手机shell提示符也会变为#。
我们提供的一些工具是基于你的手机获取了内核root权限，如果是手机root，也是可以的，但是需要修改一下脚本。因为只是手机root，adb remount命令会失败。这个时候需要在手机shell里重新remount system分区，并且修改system的目录权限，这样才能修改system分区的内容，而且需要修改我们提供的某些脚本。（之后不针对只有手机root权限做出特殊说明，我们相信你知道如何在这种模式下修改system分区）。

一般来说我们都能在网上找到仅做过root的原厂ROM。如果找不到，需要在论坛中找到资料详细的了解如何root，不同机型如何获取root权限不大一样，也不可能在这样的一篇文章中完全列出，大家自己在论坛上多多了解。

最后检查所选择的ROM可以进入Recovery模式刷机，不一定要求必需是CWM Recovery, 有wipe data/cache和安装zip包等功能的简单Recovery就可以，当然有CWM Recovery更好。

2.3 adb logcat

前面说过了adb是一个非常重要的命令，其中在机型适配过程中我们最常用的就是adb logcat。通过这个命令我们可以看到详细的log信息。
每一行的大致格式为：
I/ActivityManager(  585): Starting activity: Intent { action=android.intent.action…}
其中第一个字母表示信息优先级别（E表示错误，W表示警告，I表示普通信息等）。
斜杠后的ActivityManager表示信息标记tag，通常标记表示了打印出相应信息的模块或程序。
可以通过adb logcat tag:* *:S只显示相应tag打印的所有信息。
括号中的数字表示进程ID(pid)，表示程序所在的进程ID。
冒号后的句子就是具体的信息说明了，当我们遇到错误的时候adb logcat会给出详细的错误信息，我们通过这些错误信息去定位错误。后续的章节会陆续提到。
在机型适配中常用adb logcat *:E来查看所有的错误信息。

详细的adb说明可以参考http://developer.android.com/guide/developing/tools/adb.html。在选定好ROM之后，我们要确保在开机之初，差不多是显示开机动画时adb logcat命令就能显示详细的log信息，如果adb logcat只是在桌面程序出现之后才打印信息或者根本不打印任何信息，移植工作很难进行下去。如果只是简单的修改一些图片资源的话可以，但是对于适配MIUI来说我们要求在适配机型一开始就确保adb logcat功能的正常运行。

3. deodex
当把我们要移植的机型刷好做过内核root,可以进入recovery模式刷机的原厂ROM后，第一件事就是需要做deodex。什么是deodex，啊，这真的是一个long long story。

话说Android发明之日起，准备让开发人员使用Java语言来在Android手机平台上进行应用程序开发（为什么用Java, Java程序员大喊道，谁用谁知道呀）。Java程序一般使用java编译器(javac命令）从源文件(.java结尾的文件)编译成类文件(.class结尾的文件，又被称作字节码)，一般很多类文件被打包成一个JAR包（JAR包实际是一个zip压缩包），然后用java虚拟机解释执行这些类文件。采用类文件格式以及使用标准的Java虚拟机需要向Java的所有者（当时是SUN公司，后来被Oracle公司收购，默哀一下）缴纳授权费用并遵守相应的版权协议。Google不想缴纳这笔费用并受协议的约束，于是这丫想出来一个“偷天换日，偷梁换柱”的方法，用的是Java的壳，但是那颗心已不是Java的心。简单来说，就是当编译Android上的Java程序时，第一步还是编译成类文件打包成JAR包，然后会将这个JAR包转换为一个叫classes.dex的文件，这个dex文件是什么玩意呢，这是google发明出来的一个用于它自己的虚拟机上的一个字节码文件格式。Android上得这个虚拟机就叫做dalvik虚拟机（dalvik是冰岛的一个小镇的名字，当时google的工程师在给这个虚拟机苦思冥想一个名字，后来一个主要的工程师Dan Bronstein我的祖先当初生活在冰岛的这个小镇，就以它命名吧。据说Dan本人从没去过冰岛，Android发布后，冰岛很是骄傲，当地的报纸专门登载了这件事并热切欢迎Dan回乡探亲）。那么odex是啥呢，它叫optimized dex，即优化过的dex文件。

讲了这么多，你只需要理解odex是一种优化过的dex文件就行了，至于怎么优化的不在我们讲述的范围内。odex文件是互相依赖的，简单的理解就是我们改了其中一个文件，其它的odex文件就不起作用了。为此，我们必须做一个deodex操作，就是将odex文件变为dex文件。

一般来说原厂ROM发布时都是以odex文件格式发布的，如何判断呢。运行如下命令:
adb shell ls /system/framework
如果看到很多以odex结尾的文件，那么该ROM就是做个odex的，大家可以用我们提供在附件中的脚本deodex.sh来自动的做deodex操作。

该脚本首先确保你安装了smali/baksmali工具，然后从你的手机中pull出system分区下framework和app目录的内容，先把这些目录的内容备份在odex.bak.tar中。然后分别对这两个目录做deodex操作，最后把deodex后的文件push到手机上。具体的大家参照脚本。

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

4. 小结，案例分析
在本章中我们说到了首先熟悉自己的机型，然后寻找一个内核root，合适版本，能recovery模式刷机的原厂ROM。以i9100为例，首先我们在miui论坛新手上路区找到i9100的odin包刷机方法，然后在网上下载到http://115.com/file/cl7t65xn# I9100_ZCKJ1_wipe.zip这个原厂ROOT ZIP包，通过Recovery模式刷这个ZIP包。验证adb root可用，运行deodex工具做deodex操作，这样我们就有了一个做过deodex的原厂ROM了。

明天我们就重点介绍apktool和smali文件，这是移植工作的关键。