爲什麼使用代碼插樁
首先我們來回顧第一章中的Android軟件架構圖，這個圖中框架層的代碼完全是由Java語言編寫的，對於這兩層的代碼，在沒有源代碼的情況下我們可以採取代碼插樁的方式來注入我們的代碼。但是對於下面幾層的代碼幾乎都是以機器碼的形式存在，機器碼也是可以修改的，但是修改難度和修改smali代碼的難度不可同日而語。我們這個系列的文章不介紹如何修改這些機器碼，大家有興趣的可以參考網上的相關資料。MIUI是基於源碼開發的，爲了提升整個效率，我們會修改下面幾層的代碼，比如說我們修改了dalvik虛擬機，skia繪圖庫等。幸好這些修改不多而且有些是爲了提升性能的，不影響MIUI的整體功能。MIUI的絕大部分修改都是對框架層和核心應用層，這樣保證了我們在原廠ROM的基礎上修改這兩個層的代碼達到移植MIUI的目的。
大家看到這裏可能有一個疑問，我們直接替換原廠ROM框架層和核心應用層這兩層的代碼不就得了。不行，因爲各個層次之間是有管理的，框架層和下層代碼的一些調用接口是各個廠家自己擴展的，簡單的整個替換MIUI框架層和核心應用層的代碼無法工作。
方法概述
這一章介紹MIUI框架層的移植，其實主要是修改system/framework目錄下的三個文件：framework.jar, android.policy.jar和services.jar。這3個文件是Android系統的核心：framework.jar提供了應用層調用的各種API的實現，android.policy.jar提供了鎖屏的實現以及手機窗口管理策略的實現。services.jar是一些核心服務Java層的實現，比如ActivityManagerService, PackageManagerService等，這些服務大都運行在system_server進程中。
我們目前2.3的代碼是基於google發佈的android 2.3.7源代碼開發的，大家下載附件中的壓縮包打開後的目錄結構爲：
porting-miui/
|—————–android
|————framework.jar
|————services.jar
|————android.policy.jar
|——————miui
|———-framework.jar
|———-services.jar
|———-android.policy.jar
|———–framework-res/
|———–framework-miui-res.apk
其中android目錄中的這三個文件是從google發佈的android2.3.7源代碼編譯而來的，
而miui目錄中的這三個文件則是我們在android2.3.7源代碼基礎上修改後的代碼編譯而來的。這樣我們可以先反編譯這些文件，找出反編譯後的差別之處，然後將這些差別之處應用到原廠ROM的這三個文件中。聽起來是不是和Linux下的patch過程很相似，是的，確實相似，只不過通常的patch是基於源代碼的，然後解決一些衝突。而我們是基於smali代碼，然後解決一些衝突。（解決衝突現在可能不太明白，沒關係，下面會有例子）。移植資源
在上一節中miui目錄下的framework-res目錄和framework-miui-res.apk這兩個是和移植資源相關的。framework-res目錄下是我們對系統資源所做的修改即/system/framework/framework-res.apk的修改，大家可以反編譯framework-res.apk，將這些修改合到framework-res中，然後再編譯回去，這個比較簡單，不多做介紹。
framework-miui-res.apk是miui的資源包，所有的miui app都會用到它。這個資源包也需要放在/system/framework/目錄中，在原廠ROM中，大家一般在/system/framework目錄下除了framework-res.apk，也會發現一些其它的xxx-res.apk。爲了針對這種情況，miui的資源ID都是以0x03開頭的，一般的原廠ROM是2個資源包，framework-res.apk的資源ID是以0x01開頭的，另外一個資源包以0x02開頭。但是我們發現國行的defy比較變態，這個目錄下有3個資源包，因此針對defy我們得特殊處理。所以如果你所移植的機型這個目錄下不止兩個資源包的話，需要和我們聯繫。未來我們會考慮MIUI的資源ID都以0x06開頭，我們相信應該沒有哪個原廠ROM變態到有5個資源包。
修改smali
這一章我們重點介紹如何修改原廠ROM的smali將MIUI的修改應用到上面去。我們不會將所有的修改都會在文中列出，挑選幾個有代表性的講解，剩下的大家可以自己去做。我們以i9100爲例講述如何修改。在第二篇準備工作中，我們給出了i9100國行ROM的下載鏈接，並且討論瞭如何在這個ROM的基礎上做deodex。爲了方便起見，我們把i9100原廠ROM做個deodex後的framework.jar，services.jar和android.policy.jar也放在了附件中。
4.1 比較差異
這裏的比較差異包含兩個部分：比較miui和原生android的差異，比較i9100和原生android的差異。
以framework.jar爲例，首先可以建3個目錄反彙編這3個jar包：
apktool d framework.jar
執行完畢後，會產生framework.jar.out目錄。
接下來使用附件中的腳本rmline.sh運行如下命令：
./rmline.sh framework.jar.out
rmline.sh是用以把smali所有以.line開頭的行去掉，這樣我們容易比較smali代碼上的差別。但是對於所移植的機型，請先複製一份爲去掉.line的framework.jar.out版本，因爲這些對調試很重要，我們能通過adb logcat報告的錯誤信息中去定位在哪一行。
接下來用大家說熟悉的文件比較工具來比較差異，Linux下推薦meld, Windows下推薦Beyond Compare。
用meld比較miui和原生android的區別，大家可以看到有很多新增的Miui開頭的類，和一個新增的miui目錄，這些新增的文件和目錄我們直接拷到i9100的framework.jar.out中對應的目錄中即可（使用有.line的版本）。爲什麼我們不把這些新增的類組織在一個單獨的jar包中呢（請大家思考一下這個問題）。
不比較那些相同的和新加的，我們只比較修改過的文件，在附件中有一個change-list文件，其中列出了我們修改過的文件，你會發現和這個比較結果有一點不符，如果你比較那些文件，會發現只是一些微小的差異（比如說nop這種空指令），這是由於apktool反編譯導致的。我們無需關心，我們只需要比較那些我們修改過的文件。
下面我們就開始修改smali文件了，我將這些修改分成3種情況，選擇有代表性的3個文件加以介紹，這3種情況難度依次增加。
4.2 直接替換
以ActivityThread.smali爲例，比較發現miui改了其中一個方法getTopLevelResources，而i9100和原生android的實現完全一樣，這種情形是最簡單也是最happy的，我們改的地方要適配的機型原廠ROM完全沒有修改，直接替換就可以了。
4.3 線性代碼
還是以ActivityThread.smali爲例，對於這個文件，miui一共改了兩個方法，一個是上面介紹的，另一個是applyConfigurationToResourcesLocked。通過比較得知，miui修改了這個方法，i9100也修改了這個方法。怎麼辦呢，我們先分析一下miui修改的代碼：
.method final applyConfigurationToResourcesLocked(Landroid/content/res/Configuration;)Z
invoke-virtual {v5, p1}, Landroid/content/res/Configuration;->updateFrom(Landroid/content/res/Configuration;)I
move-result v0
.local v0, changes:I
invoke-static {v0}, Landroid/app/MiuiThemeHelper;->handleExtraConfigurationChanges(I)V
invoke-virtual {p0, v7}, Landroid/app/ActivityThread;->getDisplayMetricsLocked(Z)Landroid/util/DisplayMetrics;
move-result-object v1
.local v1, dm:Landroid/util/DisplayMetrics;
在上面將miui增加的代碼用紅色標出，在講述之前，先解釋一下smali代碼的一些規律：
所有的局部變量用v開頭，方法的頂部.locals 8表示這個方法使用8個局部變量。所有的參數用p開頭，局部變量和參數都是從0開始編號。對於非靜態方法來說，p0就是對象本身的引用，即this指針。
這裏miui新增了一個靜態方法調用，對於這種順序執行的一段代碼，我們稱之爲線性代碼。這個例子比較簡單，只新增了一個靜態方法調用。線性代碼的特點是隻有一個入口和一個出口，在編譯器的術語這叫做基本塊。對於這種新增的代碼，我們找出它的上下文，即修改的代碼前後的操作。然後在i9100的該方法的smali代碼中找到相應的位置，把這個修改應用到i9100中去。這種修改也相對簡單，插入代碼的相應位置比較好定位。
4.4 條件判斷
這種情況指的是miui插入的代碼並不是一個線性代碼，而是有條件判斷的。我們以Resources.smali爲例，miui修改了其中的loadDrawable方法，修改後的結果如下：
.method loadDrawable(Landroid/util/TypedValue;I)Landroid/graphics/drawable/Drawable;
.end local v8 #e:Ljava/lang/Exception;
.end local v13 #rnf:Landroid/content/res/Resources$NotFoundException;
:cond_6
invoke-virtual/range {p0 .. p2},
Landroid/content/res/Resources;->loadOverlayDrawable(Landroid/util/TypedValue;I)Landroid/graphics/drawable/Drawable;
move-result-object v6
if-nez v6, :cond_1
:try_start_1
move-object/from16 v0, p0
紅色代碼是miui插入的代碼，我們再看一下i9100相對於原生android對這個方法的改動，發現改動非常大。這種情況怎麼辦呢，這種情況下的關鍵是找到所插入代碼的入口點和出口點（即這段代碼是從哪執行而來的，執行完畢後又往哪去開始執行代碼）。
首先，我們發現插入代碼的前面是一個標號:cond_6，這說明程序中應該有一個跳轉語句跳轉到這個標號:cond_6。而且這種程序應該也可以從:cond_6上面的語句順序執行而來（即它可能有兩個入口點），我們分別去找這兩個入口點的代碼。首先我們去找哪個語句使用了:cond_6，找到如下代碼：
const-string v15, ".xml"
invoke-virtual {v9, v15}, Ljava/lang/String;->endsWith(Ljava/lang/String;)Z
move-result v15
if-eqz v15, :cond_6
可以發現這段代碼是在判斷v9這個字符串是否以".xml"結尾，如果不是的話，跳轉到:cond_6。好，我們去i9100中找到對應的代碼邏輯。對於這個例子，我們完全可以以".xml"作爲一個關鍵字去i9100的loadDrawable方法中搜索一下，定位到如下代碼：
const-string v17, ".xml"
move-object v0, v10
move-object/from16 v1, v17
invoke-virtual {v0, v1}, Ljava/lang/String;->endsWith(Ljava/lang/String;)Z
move-result v17
if-eqz v17, :cond_b
這段代碼的邏輯和我們在miui中找到的代碼一樣，看來，我們應該把miui插入的代碼插入到:cond_b之後。找到i9100代碼中的:cond_b之後，我們看看這條代碼後面的代碼，發現和我們插入的代碼後面的代碼基本類似，這下可以確定miui新插入的代碼應該放在:cond_b之後了。
再來看看出口點，miui插入的代碼有兩個出口點（是一個條件判斷），
if-nez v6, :cond_1
如果v6爲空往下執行，如果不爲空，則跳轉到:cond_1，好，我們來看看:cond_1的代碼是在幹嘛？:cond_1的代碼如下：
:cond_1
:goto_1
if-eqz v6, :cond_2
move-object/from16 v0, p1
iget v0, v0, Landroid/util/TypedValue;->changingConfigurations:I
我們在i9100中發現了一段類似的代碼：
:cond_1
:goto_1
if-eqz v7, :cond_2
move-object/from16 v0, p1
iget v0, v0, Landroid/util/TypedValue;->changingConfigurations:I
只不過是v6變成了v7，說明這段代碼檢測v7的值，因此我們需要將我們插入的代碼改爲：
invoke-virtual/range {p0 .. p2},
Landroid/content/res/Resources;->loadOverlayDrawable(Landroid/util/TypedValue;I)Landroid/graphics/drawable/Drawable;
move-result-object v7
if-nez v7, :cond_1
4.5 內部類
在這一節的最後我們來介紹一下內部類。對於Java文件中的每一個內部類，都會產生一個單獨的smali文件，比如ActivityThread$1.smali，這些文件的命名規範是如果是匿名類，外部類+$+數字。否則的話是外部類+$+內部類的名字。
當在內部類中調用外部類的私有方法時，編譯器會自動合成一個靜態函數。比如下面這個類：
public class Hello {
public class A {
void func() {
setup();
}
}
private void setup() {
}
}
我們在內部類A的func方法中調用了外部類的setup方法，最終編譯的smali代碼爲：
Hello$A.smali文件代碼片段：
virtual methods
.method func()V
.locals 1
.prologue
.line 5
iget-object v0, p0, LHello$A;->this$0:LHello;
#calls: LHello;->setup()V
invoke-static {v0}, LHello;->access$000(LHello;)V
.line 6
return-void
.end method
Hello.smali代碼片段：
.method static synthetic access$000(LHello;)V
.locals 0
.parameter
.prologue
.line 1
invoke-direct {p0}, LHello;->setup()V
return-void
.end method
可以看到，編譯器自動合成了一個access$000方法，假如當我們在一個較複雜的內部類中加入了一個對外部類私有方法的調用，雖然只是導致新合成了一個方法，但是這些合成的方法名可能都會有變化，這樣的結果就是smali文件差異較大，這個時候需要仔細分析，找到調用的私有方法。然後給合成的方法選取一個未被使用的名字。
- 建議
最後想對修改smali代碼給出一些建議：
(1) 細心，仔細的定位插入代碼在相應機型代碼中的插入位置。
(2) 要注意局部變量序號的改變。
(3) 不要一次修改完所有的文件再用apktool重新編譯，如果插入代碼有錯誤，會無法編譯。但是apktool的編譯出錯信息是天書，你無從知道是哪個文件改錯了。
(4) 出現錯誤不要緊，檢查adb logcat的錯誤信息，找出錯誤發生的原因。
修改smali代碼沒那麼難，多實踐一定會掌握相應的技巧。