轉(zhuǎn)：http://weishu.me/2016/03/07/understand-plugin-framework-ams-pms-hook/
在前面的文章中我們介紹了DroidPlugin的Hook機(jī)制，也就是代理方式和Binder Hook；插件框架通過AOP實(shí)現(xiàn)了插件使用和開發(fā)的透明性。在講述DroidPlugin如何實(shí)現(xiàn)四大組件的插件化之前，有必要說明一下它對(duì)ActivityManagerServiche以及PackageManagerService的Hook方式（以下簡(jiǎn)稱AMS，PMS）。
ActivityManagerService對(duì)于FrameWork層的重要性不言而喻，Android的四大組件無一不與它打交道：
startActivity最終調(diào)用了AMS的startActivity系列方法，實(shí)現(xiàn)了Activity的啟動(dòng)；Activity的生命周期回調(diào)，也在AMS中完成；
startService,bindService最終調(diào)用到AMS的startService和bindService方法；
動(dòng)態(tài)廣播的注冊(cè)和接收在AMS中完成（靜態(tài)廣播在PMS中完成）
getContentResolver最終從AMS的getContentProvider獲取到ContentProvider
而PMS則完成了諸如權(quán)限校撿(checkPermission,checkUidPermission)，Apk meta信息獲取(getApplicationInfo等)，四大組件信息獲取(query系列方法)等重要功能。
在上文Android插件化原理解析——Hook機(jī)制之Binder Hook中講述了DroidPlugin的Binder Hook機(jī)制；我們知道AMS和PMS就是以Binder方式提供給應(yīng)用程序使用的系統(tǒng)服務(wù)，理論上我們也可以采用這種方式Hook掉它們。但是由于這兩者使用得如此頻繁，F(xiàn)ramework給他們了一些“特別優(yōu)待”，這也給了我們相對(duì)于Binder Hook更加穩(wěn)定可靠的hook方式。
閱讀本文之前，可以先clone一份understand-plugin-framework，參考此項(xiàng)目的ams-pms-hook模塊。另外，插件框架原理解析系列文章見索引。
AMS獲取過程
前文提到Android的四大組件無一不與AMS相關(guān)，也許讀者還有些許疑惑；這里我就挑一個(gè)例子，依據(jù)Android源碼來說明，一個(gè)簡(jiǎn)單的startActivity是如何調(diào)用AMS最終通過IPC到system_server的。
不論讀者是否知道，我們使用startActivity有兩種形式：
直接調(diào)用Context類的startActivity方法；這種方式啟動(dòng)的Activity沒有Activity棧，因此不能以standard方式啟動(dòng)，必須加上FLAG_ACTIVITY_NEW_TASK這個(gè)Flag。
調(diào)用被Activity類重載過的startActivity方法，通常在我們的Activity中直接調(diào)用這個(gè)方法就是這種形式；
Context.startActivity
我們查看Context類的startActivity方法，發(fā)現(xiàn)這竟然是一個(gè)抽象類；查看Context的類繼承關(guān)系圖如下：
我們看到諸如Activity，Service等并沒有直接繼承Context，而是繼承了ContextWrapper；繼續(xù)查看ContextWrapper的實(shí)現(xiàn)：
@Override
publicvoidstartActivity(Intent intent){
mBase.startActivity(intent);
}
WTF!! 果然人如其名，只是一個(gè)wrapper而已；這個(gè)mBase是什么呢？這里我先直接告訴你，它的真正實(shí)現(xiàn)是ContextImpl類；至于為什么，有一條思路：mBase是在ContextWrapper構(gòu)造的時(shí)候傳遞進(jìn)來的，那么在ContextWrapper構(gòu)造的時(shí)候可以找到答案
什么時(shí)候會(huì)構(gòu)造ContextWrapper呢？它的子類Application，Service等被創(chuàng)建的時(shí)候。
可以在App的主線程AcitivityThread的performLaunchActivit方法里面找到答案；更詳細(xì)的解析可以參考老羅的Android應(yīng)用程序啟動(dòng)過程源代碼分析
好了，我們姑且當(dāng)作已經(jīng)知道Context.startActivity最終使用了ContextImpl里面的方法，代碼如下：
publicvoidstartActivity(Intent intent, Bundle options){
warnIfCallingFromSystemProcess();
if((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) ==0) {
thrownewAndroidRuntimeException(
"Calling startActivity() from outside of an Activity "
+" context requires the FLAG_ACTIVITY_NEW_TASK flag."
+" Is this really what you want?");
}
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(),null,
(Activity)null, intent, -1, options);
}
代碼相當(dāng)簡(jiǎn)單；我們知道了兩件事：
其一，我們知道了在Service等非Activity的Context里面啟動(dòng)Activity為什么需要添加FLAG_ACTIVITY_NEW_TASK；
其二，真正的startActivity使用了Instrumentation類的execStartActivity方法；繼續(xù)跟蹤：
publicActivityResultexecStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent,intrequestCode, Bundle options){
// ... 省略無關(guān)代碼
try{
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess();
// ----------------look here!!!!!!!!!!!!!!!!!!!
intresult = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target !=null? target.mEmbeddedID :null,
requestCode,0,null,null, options);
checkStartActivityResult(result, intent);
}catch(RemoteException e) {
}
returnnull;
}
到這里我們發(fā)現(xiàn)真正調(diào)用的是ActivityManagerNative的startActivity方法；如果你不清楚ActivityManager，ActivityManagerService以及ActivityManagerNative之間的關(guān)系；建議先仔細(xì)閱讀我之前關(guān)于Binder的文章Binder學(xué)習(xí)指南。
Activity.startActivity
Activity類的startActivity方法相比Context而言直觀了很多；這個(gè)startActivity通過若干次調(diào)用輾轉(zhuǎn)到達(dá)startActivityForResult這個(gè)方法，在這個(gè)方法內(nèi)部有如下代碼：
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken,this,
intent, requestCode, options);
可以看到，其實(shí)通過Activity和ContextImpl類啟動(dòng)Activity并無本質(zhì)不同，他們都通過Instrumentation這個(gè)輔助類調(diào)用到了ActivityManagerNative的方法。
Hook AMS
OK，我們到現(xiàn)在知道；其實(shí)startActivity最終通過ActivityManagerNative這個(gè)方法遠(yuǎn)程調(diào)用了AMS的startActivity方法。那么這個(gè)ActivityManagerNative是什么呢？
ActivityManagerNative實(shí)際上就是ActivityManagerService這個(gè)遠(yuǎn)程對(duì)象的Binder代理對(duì)象；每次需要與AMS打交道的時(shí)候，需要借助這個(gè)代理對(duì)象通過驅(qū)動(dòng)進(jìn)而完成IPC調(diào)用。
我們繼續(xù)看ActivityManagerNative的getDefault()方法做了什么：
staticpublicIActivityManagergetDefault(){
returngDefault.get();
}
gDefault這個(gè)靜態(tài)變量的定義如下：
private static final Singleton gDefault = new Singleton() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity
IActivityManager am = asInterface(
return am;
}
};
由于整個(gè)Framework與AMS打交道是如此頻繁，framework使用了一個(gè)單例把這個(gè)AMS的代理對(duì)象保存了起來；這樣只要需要與AMS進(jìn)行IPC調(diào)用，獲取這個(gè)單例即可。這是AMS這個(gè)系統(tǒng)服務(wù)與其他普通服務(wù)的不同之處，也是我們不通過Binder Hook的原因——我們只需要簡(jiǎn)單地Hook掉這個(gè)單例即可。
這里還有一點(diǎn)小麻煩：Android不同版本之間對(duì)于如何保存這個(gè)單例的代理對(duì)象是不同的；Android 2.x系統(tǒng)直接使用了一個(gè)簡(jiǎn)單的靜態(tài)變量存儲(chǔ)，Android 4.x以上抽象出了一個(gè)Singleton類；具體的差異可以使用grepcode進(jìn)行比較：差異
我們以4.x以上的代碼為例說明如何Hook掉AMS；方法使用的動(dòng)態(tài)代理，如果有不理解的，可以參考之前的系列文章Android插件化原理解析——Hook機(jī)制之動(dòng)態(tài)代理
Class activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");
// 獲取 gDefault 這個(gè)字段, 想辦法替換它
Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
gDefaultField.setAccessible(true);
Object gDefault = gDefaultField.get(null);
// 4.x以上的gDefault是一個(gè) android.util.Singleton對(duì)象; 我們?nèi)〕鲞@個(gè)單例里面的字段
Class singleton = Class.forName("android.util.Singleton");
Field mInstanceField = singleton.getDeclaredField("mInstance");
mInstanceField.setAccessible(true);
// ActivityManagerNative 的gDefault對(duì)象里面原始的 IActivityManager對(duì)象
Object rawIActivityManager = mInstanceField.get(gDefault);
// 創(chuàng)建一個(gè)這個(gè)對(duì)象的代理對(duì)象, 然后替換這個(gè)字段, 讓我們的代理對(duì)象幫忙干活
Class iActivityManagerInterface = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
newClass[] { iActivityManagerInterface },newIActivityManagerHandler(rawIActivityManager));
mInstanceField.set(gDefault, proxy);
好了，我們hook成功之后啟動(dòng)Activity看看會(huì)發(fā)生什么：
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕method:activityResumed calledwithargs:[android.os.BinderProxy@9bc71b2]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕method:activityIdle calledwithargs:[android.os.BinderProxy@9bc71b2, null,false]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕method:startActivity calledwithargs:[android.app.ActivityThread$ApplicationThread@17e750c, com.weishu.upf.ams_pms_hook.app, Intent{ act=android.intent.action.VIEW dat=http://wwww.baidu.com/... }, null, android.os.BinderProxy@9bc71b2, null, -1,0, null, null]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕method:activityPaused calledwithargs:[android.os.BinderProxy@9bc71b2]
可以看到，簡(jiǎn)單的幾行代碼，AMS已經(jīng)被我們完全劫持了!! 至于劫持了能干什么，自己發(fā)揮想象吧~
DroidPlugin關(guān)于AMS的Hook，可以查看IActivityManagerHook這個(gè)類，它處理了我上述所說的兼容性問題，其他原理相同。另外，也許有童鞋有疑問了，你用startActivity為例怎么能確保Hook掉這個(gè)靜態(tài)變量之后就能保證所有使用AMS的入口都被Hook了呢？
答曰：無他，唯手熟爾。
Android Framewrok層對(duì)于四大組件的處理，調(diào)用AMS服務(wù)的時(shí)候，全部都是通過使用這種方式；若有疑問可以自行查看源碼。你可以從Context類的startActivity, startService,bindService, registerBroadcastReceiver, getContentResolver 等等入口進(jìn)行跟蹤，最終都會(huì)發(fā)現(xiàn)它們都會(huì)使用ActivityManagerNative的這個(gè)AMS代理對(duì)象來完成對(duì)遠(yuǎn)程AMS的訪問。
PMS獲取過程
PMS的獲取也是通過Context完成的，具體就是getPackageManager這個(gè)方法；我們姑且當(dāng)作已經(jīng)知道了Context的實(shí)現(xiàn)在ContextImpl類里面，直奔ContextImpl類的getPackageManager方法：
publicPackageManagergetPackageManager(){
if(mPackageManager !=null) {
returnmPackageManager;
}
IPackageManager pm = ActivityThread.getPackageManager();
if(pm !=null) {
// Doesn't matter if we make more than one instance.
return(mPackageManager =newApplicationPackageManager(this, pm));
}
returnnull;
}
可以看到，這里干了兩件事：
真正的PMS的代理對(duì)象在ActivityThread類里面
ContextImpl通過ApplicationPackageManager對(duì)它還進(jìn)行了一層包裝
我們繼續(xù)查看ActivityThread類的getPackageManager方法，源碼如下：
publicstaticIPackageManagergetPackageManager(){
if(sPackageManager !=null) {
returnsPackageManager;
}
IBinder b = ServiceManager.getService("package");
sPackageManager = IPackageManager.Stub.asInterface(b);
returnsPackageManager;
}
可以看到，和AMS一樣，PMS的Binder代理對(duì)象也是一個(gè)全局變量存放在一個(gè)靜態(tài)字段中；我們可以如法炮制，Hook掉PMS。
現(xiàn)在我們的目的很明切，如果需要HookPMS有兩個(gè)地方需要Hook掉：
ActivityThread的靜態(tài)字段sPackageManager
通過Context類的getPackageManager方法獲取到的ApplicationPackageManager對(duì)象里面的mPM字段。
Hook PMS
現(xiàn)在使用代理Hook應(yīng)該是輕車熟路了吧，通過上面的分析，我們Hook兩個(gè)地方；代碼信手拈來：
// 獲取全局的ActivityThread對(duì)象
Class activityThreadClass = Class.forName("android.app.ActivityThread");
Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
Object currentActivityThread = currentActivityThreadMethod.invoke(null);
// 獲取ActivityThread里面原始的 sPackageManager
Field sPackageManagerField = activityThreadClass.getDeclaredField("sPackageManager");
sPackageManagerField.setAccessible(true);
Object sPackageManager = sPackageManagerField.get(currentActivityThread);
// 準(zhǔn)備好代理對(duì)象, 用來替換原始的對(duì)象
Class iPackageManagerInterface = Class.forName("android.content.pm.IPackageManager");
Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(),
newClass[] { iPackageManagerInterface },
newHookHandler(sPackageManager));
// 1. 替換掉ActivityThread里面的 sPackageManager 字段
sPackageManagerField.set(currentActivityThread, proxy);
// 2. 替換 ApplicationPackageManager里面的 mPM對(duì)象
PackageManager pm = context.getPackageManager();
Field mPmField = pm.getClass().getDeclaredField("mPM");
mPmField.setAccessible(true);
mPmField.set(pm, proxy);
好了，Hook完畢我們驗(yàn)證以下結(jié)論；調(diào)用一下PMS的getInstalledApplications方法，打印日志如下：
03-0715:07:27.1878306-8306/com.weishu.upf.ams_pms_hook.app D/IActivityManagerHandler﹕ hey, baby; you are hook!!
03-0715:07:27.1878306-8306/com.weishu.upf.ams_pms_hook.app D/IActivityManagerHandler﹕ method:getInstalledApplications called with args:[0,0]
OK，我們又成功劫持了PackageManager??！DroidPlugin 處理PMS的代碼可以在IPackageManagerHook查看。
在結(jié)束講解PackageManager的Hook之前，我們需要說明一點(diǎn)；那就是Context的實(shí)現(xiàn)類里面沒有使用靜態(tài)全局變量來保存PMS的代理對(duì)象，而是每擁有一個(gè)Context的實(shí)例就持有了一個(gè)PMS代理對(duì)象的引用；所以這里有個(gè)很蛋疼的事情，那就是我們?nèi)绻胍耆獺ook住PMS，需要精確控制整個(gè)進(jìn)程內(nèi)部創(chuàng)建的Context對(duì)象；所幸，插件框架中，插件的Activity，Service，ContentProvider，Broadcast等所有使用到Context的地方，都是由框架控制創(chuàng)建的；因此我們要小心翼翼地替換掉所有這些對(duì)象持有的PMS代理對(duì)象。
我前面也提到過，靜態(tài)變量和單例都是良好的Hook點(diǎn)，這里很好地反證了這句話：想要Hook掉一個(gè)實(shí)例變量該是多么麻煩!
小結(jié)
寫到這里，關(guān)于DroidPlugin的Hook技術(shù)的講解已經(jīng)完結(jié)了；我相信讀者或多或少地認(rèn)識(shí)到，其實(shí)Hook并不是一項(xiàng)神秘的技術(shù)；一個(gè)干凈，透明的框架少不了AOP，而AOP也少不了Hook。
我所講解的Hook僅僅使用反射和動(dòng)態(tài)代理技術(shù)，更加強(qiáng)大的Hook機(jī)制可以進(jìn)行字節(jié)碼編織，比如J2EE廣泛使用了cglib和asm進(jìn)行AOP編程；而Android上現(xiàn)有的插件框架還是加載編譯時(shí)代碼，采用動(dòng)態(tài)生成類的技術(shù)理論上也是可行的；之前有一篇文章Android動(dòng)態(tài)加載黑科技 動(dòng)態(tài)創(chuàng)建Activity模式，就講述了這種方式；現(xiàn)在全球的互聯(lián)網(wǎng)公司不排除有用這種技術(shù)實(shí)現(xiàn)插件框架的可能 ；我相信不遠(yuǎn)的未來，這種技術(shù)也會(huì)在Android上大放異彩。
了解完Hook技術(shù)之后，接下來的系列文章會(huì)講述DroidPlugin對(duì)Android四大組件在插件系統(tǒng)上的處理，插件框架對(duì)于這一部分的實(shí)現(xiàn)是DroidPlugin的精髓，Hook只不過是工具而已。學(xué)習(xí)這部分內(nèi)容需要對(duì)于Activity，Service，Broadcast以及ContentProvider的工作機(jī)制有一定的了解，因此我也會(huì)在必要的時(shí)候穿插講解一些Android Framework的知識(shí)；我相信這一定會(huì)對(duì)讀者大有裨益。
