全面認識Android手機（MIUI ROM適配之旅第二天——準備工作）

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檔案，這是移植工作的關鍵。

    deodex.sh