Hook機制之AMS&PMS
在前面的文章中我們介紹了DroidPlugin的Hook機制，也就是代理方式和Binder Hook；外掛框架通過AOP實現了外掛使用和開發的透明性。在講述DroidPlugin如何實現四大元件的外掛化之前，有必要說明一下它對ActivityManagerServiche以及PackageManagerService的Hook方式（以下簡稱AMS，PMS）。
ActivityManagerService對於FrameWork層的重要性不言而喻，Android的四大元件無一不與它打交道：
startActivity最終呼叫了AMS的startActivity系列方法，實現了Activity的啟動；Activity的生命週期回撥，也在AMS中完成；startService,bindService最終呼叫到AMS的startService和bindService方法；- 動態廣播的註冊和接收在
AMS中完成（靜態廣播在PMS中完成） getContentResolver最終從AMS的getContentProvider獲取到ContentProvider
而PMS則完成了諸如許可權校撿(checkPermission,checkUidPermission)，Apk meta資訊獲取(getApplicationInfo等)，四大元件資訊獲取(query系列方法)等重要功能。
在上文Hook機制之Binder Hook中講述了DroidPlugin的Binder Hook機制；我們知道AMS
PMS就是以Binder方式提供給應用程式使用的系統服務，理論上我們也可以採用這種方式Hook掉它們。但是由於這兩者使用得如此頻繁，Framework給他們了一些“特別優待”，這也給了我們相對於Binder Hook更加穩定可靠的hook方式。
AMS獲取過程
前文提到Android的四大元件無一不與AMS相關，也許讀者還有些許疑惑；這裡我就挑一個例子，依據Android原始碼來說明，一個簡單的startActivity是如何呼叫AMS最終通過IPC到system_server的。
不論讀者是否知道，我們使用startActivity有兩種形式：
- 直接呼叫
Context類的startActivity方法；這種方式啟動的Activity沒有Activity棧，因此不能以standard方式啟動，必須加上FLAG_ACTIVITY_NEW_TASK這個Flag。 - 呼叫被
Activity類過載過的startActivity方法，通常在我們的Activity中直接呼叫這個方法就是這種形式；
Context.startActivity
我們檢視Context類的startActivity方法，發現這竟然是一個抽象類；檢視Context的類繼承關係圖：
我們看到諸如Activity，Service等並沒有直接繼承Context，而是繼承了ContextWrapper；繼續檢視ContextWrapper的實現：
@Override
public void startActivity(Intent intent) {
mBase.startActivity(intent);
}WTF!! 果然人如其名，只是一個wrapper而已；這個mBase是什麼呢？這裡我先直接告訴你，它的真正實現是ContextImpl類；至於為什麼，有一條思路：mBase是在ContextWrapper構造的時候傳遞進來的，那麼在ContextWrapper構造的時候可以找到答案
什麼時候會構造ContextWrapper呢？它的子類Application，Service等被建立的時候。
可以在App的主執行緒AcitivityThread的performLaunchActivit方法裡面找到答案；更詳細的解析可以參考老羅的 Android應用程式啟動過程原始碼分析
好了，我們姑且當作已經知道Context.startActivity最終使用了ContextImpl裡面的方法，程式碼如下：
public void startActivity(Intent intent, Bundle options) {
warnIfCallingFromSystemProcess();
if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
throw new AndroidRuntimeException(
"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);
}程式碼相當簡單；我們知道了兩件事：
其一，我們知道了在Service等非Activity的Context裡面啟動Activity為什麼需要新增FLAG_ACTIVITY_NEW_TASK；
其二，真正的startActivity使用了Instrumentation類的execStartActivity方法；繼續跟蹤
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
// ... 省略無關程式碼
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess();
// ----------------look here!!!!!!!!!!!!!!!!!!!
int result = 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) {
}
return null;
}到這裡我們發現真正呼叫的是ActivityManagerNative的startActivity方法；如果你不清楚ActivityManager，ActivityManagerService以及ActivityManagerNative之間的關係；建議先仔細閱讀我之前關於Binder的文章 Binder學習指南。
Activity.startActivity
Activity類的startActivity方法相比Context而言直觀了很多；這個startActivity通過若干次呼叫輾轉到達startActivityForResult這個方法，在這個方法內部有如下程式碼：
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);可以看到，其實通過Activity和ContextImpl類啟動Activity並無本質不同，他們都通過Instrumentation這個輔助類呼叫到了ActivityManagerNative的方法。
Hook AMS
OK，我們到現在知道；其實startActivity最終通過ActivityManagerNative這個方法遠端呼叫了AMS的startActivity方法。那麼這個ActivityManagerNative是什麼呢？
ActivityManagerNative實際上就是ActivityManagerService這個遠端物件的Binder代理物件；每次需要與AMS打交道的時候，需要藉助這個代理物件通過驅動進而完成IPC呼叫。
我們繼續看ActivityManagerNative的getDefault()方法做了什麼：
static public IActivityManager getDefault() {
return gDefault.get();
}gDefault這個靜態變數的定義如下：
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity
IActivityManager am = asInterface(
return am;
}
};由於整個Framework與AMS打交道是如此頻繁，framework使用了一個單例把這個AMS的代理物件儲存了起來；這樣只要需要與AMS進行IPC呼叫，獲取這個單例即可。這是AMS這個系統服務與其他普通服務的不同之處，也是我們不通過Binder Hook的原因——我們只需要簡單地Hook掉這個單例即可。
這裡還有一點小麻煩：Android不同版本之間對於如何儲存這個單例的代理物件是不同的；Android 2.x系統直接使用了一個簡單的靜態變數儲存，Android 4.x以上抽象出了一個Singleton類；具體的差異可以使用grepcode進行比較：差異
我們以4.x以上的程式碼為例說明如何Hook掉AMS；方法使用的動態代理
Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");
// 獲取 gDefault 這個欄位, 想辦法替換它
Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
gDefaultField.setAccessible(true);
Object gDefault = gDefaultField.get(null);
// 4.x以上的gDefault是一個 android.util.Singleton物件; 我們取出這個單例裡面的欄位
Class<?> singleton = Class.forName("android.util.Singleton");
Field mInstanceField = singleton.getDeclaredField("mInstance");
mInstanceField.setAccessible(true);
// ActivityManagerNative 的gDefault物件裡面原始的 IActivityManager物件
Object rawIActivityManager = mInstanceField.get(gDefault);
// 建立一個這個物件的代理物件, 然後替換這個欄位, 讓我們的代理物件幫忙幹活
Class<?> iActivityManagerInterface = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
new Class<?>[] { iActivityManagerInterface }, new IActivityManagerHandler(rawIActivityManager));
mInstanceField.set(gDefault, proxy);好了，我們hook成功之後啟動Activity看看會發生什麼：
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityResumed called with args:[[email protected]]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityIdle called with args:[[email protected], null, false]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:startActivity called with args:[[email protected], com.weishu.upf.ams_pms_hook.app, Intent { act=android.intent.action.VIEW dat=http://wwww.baidu.com/... }, null, [email protected], null, -1, 0, null, null]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityPaused called with args:[[email protected]]簡單的幾行程式碼，AMS已經被我們完全劫持了!! 至於劫持了能幹什麼，自己發揮想象吧~
DroidPlugin關於AMS的Hook，可以檢視IActivityManagerHook這個類，它處理了我上述所說的相容性問題，其他原理相同。另外，也許有童鞋有疑問了，你用startActivity為例怎麼能確保Hook掉這個靜態變數之後就能保證所有使用AMS的入口都被Hook了呢？
答曰：無他，唯手熟爾。
Android Framewrok層對於四大元件的處理，呼叫AMS服務的時候，全部都是通過使用這種方式；若有疑問可以自行檢視原始碼。你可以從Context類的startActivity, startService,bindService, registerBroadcastReceiver, getContentResolver 等等入口進行跟蹤，最終都會發現它們都會使用ActivityManagerNative的這個AMS代理物件來完成對遠端AMS的訪問。
PMS獲取過程
PMS的獲取也是通過Context完成的，具體就是getPackageManager這個方法；我們姑且當作已經知道了Context的實現在ContextImpl類裡面，直奔ContextImpl類的getPackageManager方法：
public PackageManager getPackageManager() {
if (mPackageManager != null) {
return mPackageManager;
}
IPackageManager pm = ActivityThread.getPackageManager();
if (pm != null) {
// Doesn't matter if we make more than one instance.
return (mPackageManager = new ApplicationPackageManager(this, pm));
}
return null;
}可以看到，這裡幹了兩件事：
- 真正的
PMS的代理物件在ActivityThread類裡面 ContextImpl通過ApplicationPackageManager對它還進行了一層包裝
我們繼續檢視ActivityThread類的getPackageManager方法，原始碼如下：
public static IPackageManager getPackageManager() {
if (sPackageManager != null) {
return sPackageManager;
}
IBinder b = ServiceManager.getService("package");
sPackageManager = IPackageManager.Stub.asInterface(b);
return sPackageManager;
}可以看到，和AMS一樣，PMS的Binder代理物件也是一個全域性變數存放在一個靜態欄位中；我們可以如法炮製，Hook掉PMS。
現在我們的目的很明切，如果需要Hook PMS有兩個地方需要Hook掉：
ActivityThread的靜態欄位sPackageManager- 通過Context類的
getPackageManager方法獲取到的ApplicationPackageManager物件裡面的mPM欄位。
Hook PMS
現在使用代理Hook應該是輕車熟路了吧，通過上面的分析，我們Hook兩個地方；程式碼信手拈來：
// 獲取全域性的ActivityThread物件
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);
// 準備好代理物件, 用來替換原始的物件
Class<?> iPackageManagerInterface = Class.forName("android.content.pm.IPackageManager");
Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(),
new Class<?>[] { iPackageManagerInterface },
new HookHandler(sPackageManager));
// 1. 替換掉ActivityThread裡面的 sPackageManager 欄位
sPackageManagerField.set(currentActivityThread, proxy);
// 2. 替換 ApplicationPackageManager裡面的 mPM物件
PackageManager pm = context.getPackageManager();
Field mPmField = pm.getClass().getDeclaredField("mPM");
mPmField.setAccessible(true);
mPmField.set(pm, proxy);OK，我們又成功劫持了PackageManager！！DroidPlugin 處理PMS的程式碼可以在IPackageManagerHook檢視。
在結束講解PackageManager的Hook之前，我們需要說明一點；那就是Context的實現類裡面沒有使用靜態全域性變數來儲存PMS的代理物件，而是每擁有一個Context的例項就持有了一個PMS代理物件的引用；所以這裡有個很蛋疼的事情，那就是我們如果想要完全Hook住PMS，需要精確控制整個程序內部建立的Context物件；所幸，外掛框架中，外掛的Activity，Service，ContentProvider，Broadcast等所有使用到Context的地方，都是由框架控制建立的；因此我們要小心翼翼地替換掉所有這些物件持有的PMS代理物件。
我前面也提到過，靜態變數和單例都是良好的Hook點，這裡很好地反證了這句話：想要Hook掉一個例項變數該是多麼麻煩!
小結
寫到這裡，關於DroidPlugin的Hook技術的講解已經完結了；我相信讀者或多或少地認識到，其實Hook並不是一項神祕的技術；一個乾淨，透明的框架少不了AOP，而AOP也少不了Hook。
我所講解的Hook僅僅使用反射和動態代理技術，更加強大的Hook機制可以進行位元組碼編織，比如J2EE廣泛使用了cglib和asm進行AOP程式設計；而Android上現有的外掛框架還是載入編譯時程式碼，採用動態生成類的技術理論上也是可行的；之前有一篇文章Android動態載入黑科技 動態建立Activity模式，就講述了這種方式；現在全球的網際網路公司不排除有用這種技術實現外掛框架的可能 ；我相信不遠的未來，這種技術也會在Android上大放異彩。