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文件,这是移植工作的关键。