搭建移植環境
“工欲善其事，必先利其器”。在製作自己的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.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功能的正常運行。
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，具體的用戶請參照該工具的幫助文檔。
小結，案例分析
在本章中我們說到了首先熟悉自己的機型，然後尋找一個內核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文件，這是移植工作的關鍵。