|
1. 為什么使用代碼插樁 首先我們來回顧第一章中的Android軟件架構(gòu)圖，這個(gè)圖中框架層的代碼完全是由Java語言編寫的，對于這兩層的代碼，在沒有源代碼的情況下我們可以 采取代碼插樁的方式來注入我們的代碼。但是對于下面幾層的代碼幾乎都是以機(jī)器碼的形式存在，機(jī)器碼也是可以修改的，但是修改難度和修改smali代碼的難 度不可同日而語。我們這個(gè)系列的文章不介紹如何修改這些機(jī)器碼，大家有興趣的可以參考網(wǎng)上的相關(guān)資料。MIUI是基于源碼開發(fā)的，為了提升整個(gè)效率，我們 會修改下面幾層的代碼，比如說我們修改了dalvik虛擬機(jī)，skia繪圖庫等。幸好這些修改不多而且有些是為了提升性能的，不影響MIUI的整體功能。 MIUI的絕大部分修改都是對框架層和核心應(yīng)用層，這樣保證了我們在原廠ROM的基礎(chǔ)上修改這兩個(gè)層的代碼達(dá)到移植MIUI的目的。 大家看到這里可能有一個(gè)疑問，我們直接替換原廠ROM框架層和核心應(yīng)用層這兩層的代碼不就得了。不行，因?yàn)楦鱾€(gè)層次之間是有管理的，框架層和下層代碼的一些調(diào)用接口是各個(gè)廠家自己擴(kuò)展的，簡單的整個(gè)替換MIUI框架層和核心應(yīng)用層的代碼無法工作。 2. 方法概述 這一章介紹MIUI框架層的移植，其實(shí)主要是修改system/framework目錄下的三個(gè)文件：framework.jar, android.policy.jar和services.jar。這3個(gè)文件是Android系統(tǒng)的核心：framework.jar提供了應(yīng)用層調(diào)用 的各種API的實(shí)現(xiàn)，android.policy.jar提供了鎖屏的實(shí)現(xiàn)以及手機(jī)窗口管理策略的實(shí)現(xiàn)。services.jar是一些核心服務(wù) Java層的實(shí)現(xiàn)，比如ActivityManagerService, PackageManagerService等，這些服務(wù)大都運(yùn)行在system_server進(jìn)程中。 我們目前2.3的代碼是基于google發(fā)布的android 2.3.7源代碼開發(fā)的，大家下載附件中的壓縮包打開后的目錄結(jié)構(gòu)為： 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目錄中的這三個(gè)文件是從google發(fā)布的android2.3.7源代碼編譯而來的， 而miui目錄中的這三個(gè)文件則是我們在android2.3.7源代碼基礎(chǔ)上修改后的代碼編譯而來的。這樣我們可以先反編譯這些文件，找出反編譯后的差 別之處，然后將這些差別之處應(yīng)用到原廠ROM的這三個(gè)文件中。聽起來是不是和Linux下的patch過程很相似，是的，確實(shí)相似，只不過通常的 patch是基于源代碼的，然后解決一些沖突。而我們是基于smali代碼，然后解決一些沖突。（解決沖突現(xiàn)在可能不太明白，沒關(guān)系，下面會有例子）。 3. 移植資源 在上一節(jié)中miui目錄下的framework-res目錄和framework-miui-res.apk這兩個(gè)是和移植資源相關(guān)的。 framework-res目錄下是我們對系統(tǒng)資源所做的修改即/system/framework/framework-res.apk的修改，大家可 以反編譯framework-res.apk，將這些修改合到framework-res中，然后再編譯回去，這個(gè)比較簡單，不多做介紹。 framework-miui-res.apk是miui的資源包，所有的miui app都會用到它。這個(gè)資源包也需要放在/system/framework/目錄中，在原廠ROM中，大家一般在/system/framework目 錄下除了framework-res.apk，也會發(fā)現(xiàn)一些其它的xxx-res.apk。為了針對這種情況，miui的資源ID都是以0x03開頭的， 一般的原廠ROM是2個(gè)資源包，framework-res.apk的資源ID是以0x01開頭的，另外一個(gè)資源包以0x02開頭。但是我們發(fā)現(xiàn)國行的 defy比較變態(tài)，這個(gè)目錄下有3個(gè)資源包，因此針對defy我們得特殊處理。所以如果你所移植的機(jī)型這個(gè)目錄下不止兩個(gè)資源包的話，需要和我們聯(lián)系。未 來我們會考慮MIUI的資源ID都以0x06開頭，我們相信應(yīng)該沒有哪個(gè)原廠ROM變態(tài)到有5個(gè)資源包。 4. 修改smali 這一章我們重點(diǎn)介紹如何修改原廠ROM的smali將MIUI的修改應(yīng)用到上面去。我們不會將所有的修改都會在文中列出，挑選幾個(gè)有代表性的講解，剩下的 大家可以自己去做。我們以i9100為例講述如何修改。在第二篇準(zhǔn)備工作中，我們給出了i9100國行ROM的下載鏈接，并且討論了如何在這個(gè)ROM的基 礎(chǔ)上做deodex。為了方便起見，我們把i9100原廠ROM做個(gè)deodex后的framework.jar，services.jar和 android.policy.jar也放在了附件中。 4.1 比較差異 這里的比較差異包含兩個(gè)部分：比較miui和原生android的差異，比較i9100和原生android的差異。 以framework.jar為例，首先可以建3個(gè)目錄反匯編這3個(gè)jar包： apktool d framework.jar 執(zhí)行完畢后，會產(chǎn)生framework.jar.out目錄。 接下來使用附件中的腳本rmline.sh運(yùn)行如下命令： ./rmline.sh framework.jar.out rmline.sh是用以把smali所有以.line開頭的行去掉，這樣我們?nèi)菀妆容^smali代碼上的差別。但是對于所移植的機(jī)型，請先復(fù)制一份為去 掉.line的framework.jar.out版本，因?yàn)檫@些對調(diào)試很重要，我們能通過adb logcat報(bào)告的錯(cuò)誤信息中去定位在哪一行。 接下來用大家說熟悉的文件比較工具來比較差異，Linux下推薦meld, Windows下推薦Beyond Compare。 用meld比較miui和原生android的區(qū)別，大家可以看到有很多新增的Miui開頭的類，和一個(gè)新增的miui目錄，這些新增的文件和目錄我們直 接拷到i9100的framework.jar.out中對應(yīng)的目錄中即可（使用有.line的版本）。為什么我們不把這些新增的類組織在一個(gè)單獨(dú)的 jar包中呢（請大家思考一下這個(gè)問題）。 不比較那些相同的和新加的，我們只比較修改過的文件，在附件中有一個(gè)change-list文件，其中列出了我們修改過的文件，你會發(fā)現(xiàn)和這個(gè)比較結(jié)果有 一點(diǎn)不符，如果你比較那些文件，會發(fā)現(xiàn)只是一些微小的差異（比如說nop這種空指令），這是由于apktool反編譯導(dǎo)致的。我們無需關(guān)心，我們只需要比 較那些我們修改過的文件。 下面我們就開始修改smali文件了，我將這些修改分成3種情況，選擇有代表性的3個(gè)文件加以介紹，這3種情況難度依次增加。 4.2 直接替換 以ActivityThread.smali為例，比較發(fā)現(xiàn)miui改了其中一個(gè)方法getTopLevelResources，而i9100和原生 android的實(shí)現(xiàn)完全一樣，這種情形是最簡單也是最happy的，我們改的地方要適配的機(jī)型原廠ROM完全沒有修改，直接替換就可以了。 4.3 線性代碼 還是以ActivityThread.smali為例，對于這個(gè)文件，miui一共改了兩個(gè)方法，一個(gè)是上面介紹的，另一個(gè)是 applyConfigurationToResourcesLocked。通過比較得知，miui修改了這個(gè)方法，i9100也修改了這個(gè)方法。怎么辦 呢，我們先分析一下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增加的代碼用紅色標(biāo)出，在講述之前，先解釋一下smali代碼的一些規(guī)律： 所有的局部變量用v開頭，方法的頂部.locals 8表示這個(gè)方法使用8個(gè)局部變量。所有的參數(shù)用p開頭，局部變量和參數(shù)都是從0開始編號。對于非靜態(tài)方法來說，p0就是對象本身的引用，即this指針。 這里miui新增了一個(gè)靜態(tài)方法調(diào)用，對于這種順序執(zhí)行的一段代碼，我們稱之為線性代碼。這個(gè)例子比較簡單，只新增了一個(gè)靜態(tài)方法調(diào)用。線性代碼的特點(diǎn)是 只有一個(gè)入口和一個(gè)出口，在編譯器的術(shù)語這叫做基本塊。對于這種新增的代碼，我們找出它的上下文，即修改的代碼前后的操作。然后在i9100的該方法的 smali代碼中找到相應(yīng)的位置，把這個(gè)修改應(yīng)用到i9100中去。這種修改也相對簡單，插入代碼的相應(yīng)位置比較好定位。 4.4 條件判斷 這種情況指的是miui插入的代碼并不是一個(gè)線性代碼，而是有條件判斷的。我們以Resources.smali為例，miui修改了其中的loadDrawable方法，修改后的結(jié)果如下： .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對這個(gè)方法的改動，發(fā)現(xiàn)改動非常大。這種情況怎么辦呢，這種情況下的關(guān)鍵是找到所插入代碼的入口點(diǎn)和出口點(diǎn)（即這段代碼是從哪執(zhí)行而來的，執(zhí)行完畢后又往哪去開始執(zhí)行代碼）。 首先，我們發(fā)現(xiàn)插入代碼的前面是一個(gè)標(biāo)號:cond_6，這說明程序中應(yīng)該有一個(gè)跳轉(zhuǎn)語句跳轉(zhuǎn)到這個(gè)標(biāo)號:cond_6。而且這種程序應(yīng)該也可以 從:cond_6上面的語句順序執(zhí)行而來（即它可能有兩個(gè)入口點(diǎn)），我們分別去找這兩個(gè)入口點(diǎn)的代碼。首先我們?nèi)フ夷膫€(gè)語句使用了: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 可以發(fā)現(xiàn)這段代碼是在判斷v9這個(gè)字符串是否以".xml"結(jié)尾，如果不是的話，跳轉(zhuǎn)到:cond_6。好，我們?nèi)9100中找到對應(yīng)的代碼邏輯。對于 這個(gè)例子，我們完全可以以".xml"作為一個(gè)關(guān)鍵字去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中找到的代碼一樣，看來，我們應(yīng)該把miui插入的代碼插入到:cond_b之后。找到i9100代碼中的:cond_b 之后，我們看看這條代碼后面的代碼，發(fā)現(xiàn)和我們插入的代碼后面的代碼基本類似，這下可以確定miui新插入的代碼應(yīng)該放在:cond_b之后了。 再來看看出口點(diǎn)，miui插入的代碼有兩個(gè)出口點(diǎn)（是一個(gè)條件判斷）， if-nez v6, :cond_1 如果v6為空往下執(zhí)行，如果不為空，則跳轉(zhuǎn)到: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中發(fā)現(xiàn)了一段類似的代碼： :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 內(nèi)部類 在這一節(jié)的最后我們來介紹一下內(nèi)部類。對于Java文件中的每一個(gè)內(nèi)部類，都會產(chǎn)生一個(gè)單獨(dú)的smali文件，比如ActivityThread$1.smali，這些文件的命名規(guī)范是如果是匿名類，外部類+$+數(shù)字。否則的話是外部類+$+內(nèi)部類的名字。 當(dāng)在內(nèi)部類中調(diào)用外部類的私有方法時(shí)，編譯器會自動合成一個(gè)靜態(tài)函數(shù)。比如下面這個(gè)類： public class Hello { public class A { void func() { setup(); } } private void setup() { } } 我們在內(nèi)部類A的func方法中調(diào)用了外部類的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 可以看到，編譯器自動合成了一個(gè)access$000方法，假如當(dāng)我們在一個(gè)較復(fù)雜的內(nèi)部類中加入了一個(gè)對外部類私有方法的調(diào)用，雖然只是導(dǎo)致新合成了一 個(gè)方法，但是這些合成的方法名可能都會有變化，這樣的結(jié)果就是smali文件差異較大，這個(gè)時(shí)候需要仔細(xì)分析，找到調(diào)用的私有方法。然后給合成的方法選取 一個(gè)未被使用的名字。 5. 建議 最后想對修改smali代碼給出一些建議： (1) 細(xì)心，仔細(xì)的定位插入代碼在相應(yīng)機(jī)型代碼中的插入位置。 (2) 要注意局部變量序號的改變。 (3) 不要一次修改完所有的文件再用apktool重新編譯，如果插入代碼有錯(cuò)誤，會無法編譯。但是apktool的編譯出錯(cuò)信息是天書，你無從知道是哪個(gè)文件改錯(cuò)了。 (4) 出現(xiàn)錯(cuò)誤不要緊，檢查adb logcat的錯(cuò)誤信息，找出錯(cuò)誤發(fā)生的原因。 修改smali代碼沒那么難，多實(shí)踐一定會掌握相應(yīng)的技巧。 |
|
|
