插件化框架實(shí)現(xiàn)：基于kotlin的插件化框架

插件化組件的問(wèn)題

• 通過(guò)類(lèi)加載可以實(shí)現(xiàn)加載插件的代碼势腮，但是在Android系統(tǒng)中后添，組件是有“生命”的，而且必須是合法的瘟滨，也就是說(shuō)有兩個(gè)問(wèn)題當(dāng)啟動(dòng)系統(tǒng)組件的時(shí)候候醒，需要處理組件的合法性和生命周期

Activity啟動(dòng)流程

ActivityLaunch.png

插件化Activity的解決方案

• 代理
  • 通過(guò)宿主Activity的生命周期調(diào)用插件Activity的對(duì)應(yīng)生命周期方法
  • 當(dāng)然這種方式對(duì)插件的開(kāi)發(fā)代碼的侵入性太大能颁，現(xiàn)在業(yè)界也越來(lái)越少使用這種方式
• 欺上瞞下
  • 通過(guò)反射或者動(dòng)態(tài)代理來(lái)實(shí)現(xiàn)系統(tǒng)關(guān)鍵模塊關(guān)鍵方法的hook攔截操作
  • 通過(guò)hook系統(tǒng)關(guān)鍵模塊來(lái)實(shí)現(xiàn)插件Activity -> 占坑Activity、占坑Activity -> 插件Activity的過(guò)程倒淫，通過(guò)占坑Activity來(lái)繞過(guò)PMS對(duì)組件合法性的驗(yàn)證伙菊，再切換到插件Activity來(lái)實(shí)現(xiàn)整個(gè)欺上瞞下的過(guò)程
  • 欺上瞞下不一定需要hook系統(tǒng)模塊，360的RePlugin實(shí)現(xiàn)就是不通過(guò)hook 系統(tǒng)相應(yīng)模塊

AMS

• 根據(jù)Activity的啟動(dòng)流程敌土，stratActivity(…)最終會(huì)通過(guò)Instrumentation的execStartActivity(…)方法：

public ActivityResult execStartActivity(
        Context who, IBinder contextThread, IBinder token, Activity target,
        Intent intent, int requestCode, Bundle options) {
    IApplicationThread whoThread = (IApplicationThread) contextThread;
    // ActivityMonitors 相關(guān) ...
    
    try {
        intent.migrateExtraStreamToClipData();
        intent.prepareToLeaveProcess();
        int result = ActivityManagerNative.getDefault()
            .startActivity(whoThread, who.getBasePackageName(), intent,
                    intent.resolveTypeIfNeeded(who.getContentResolver()),
                    token, target != null ? target.mEmbeddedID : null,
                    requestCode, 0, null, options);
        checkStartActivityResult(result, intent);
    } catch (RemoteException e) {
    }
    return null;
}

• ActivityManagerNative.getDefault()

static public IActivityManager getDefault() {
   return gDefault.get();
}

private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
    protected IActivityManager create() {
        IBinder b = ServiceManager.getService("activity");
        IActivityManager am = asInterface(b);
        return am;
    }
};

public abstract class Singleton<T> {
    private T mInstance;

    protected abstract T create();

    public final T get() {
        synchronized (this) {
            if (mInstance == null) {
                mInstance = create();
            }
            return mInstance;
        }
    }
}

public interface IActivityManager extends IInterface {
    public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
            String resolvedType, IBinder resultTo, String resultWho, int requestCode, int flags,
            ProfilerInfo profilerInfo, Bundle options) throws RemoteException;

    // .... 其他接口方法的定義
}

插件Activity -> 宿主Activity

• 通過(guò)上面代碼镜硕，我們可以找到IActivityManager作為Hook點(diǎn)

// 創(chuàng)建一個(gè)這個(gè)對(duì)象的代理對(duì)象, 然后替換這個(gè)字段, 讓我們的代理對(duì)象幫忙干活
Class<?> iActivityManagerInterface = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
        new Class<?>[] { iActivityManagerInterface }, new IActivityManagerHandler(rawIActivityManager));
mInstanceField.set(gDefault, proxy);

• 通過(guò)Java動(dòng)態(tài)代理IActivityManager，將IActivityManager的調(diào)用轉(zhuǎn)發(fā)到IActivityManagerHandler做startActivity(...)等操作的攔截處理返干，實(shí)現(xiàn)插件Activity -> 宿主Activity的替換

宿主Activity -> 插件Activity

那怎么完成宿主Activity -> 插件Activity的轉(zhuǎn)換呢兴枯？

• 由于DroidPlugin采用hook AMS，這里講一下DroidPlugin如何實(shí)現(xiàn)宿主Activity -> 插件Activity矩欠，是通過(guò)hook ActivityThread的H的Callback财剖，也就是Handler的Callback來(lái)攔截LAUNCH_ACTIVITY處理悠夯，實(shí)現(xiàn)宿主Activity -> 插件Activity

AMS 版本差異

Android 4.x

• Android 4.x以上抽象出了一個(gè)Singleton類(lèi)，見(jiàn)上面代碼

Android 2.x

• Android 2.x系統(tǒng)直接使用了一個(gè)簡(jiǎn)單的靜態(tài)變量存儲(chǔ)

private static IActivityManager gDefault;

static public IActivityManager getDefault() {
    if (gDefault != null) {
        //if (Config.LOGV) Log.v(
        //    "ActivityManager", "returning cur default = " + gDefault);
        return gDefault;
    }
    IBinder b = ServiceManager.getService("activity");
    if (Config.LOGV) Log.v("ActivityManager", "default service binder = " + b);
    gDefault = asInterface(b);
    if (Config.LOGV) Log.v("ActivityManager", "default service = " + gDefault);
    return gDefault;
}

Instrumentation

• 根據(jù)Activity的啟動(dòng)流程躺坟，stratActivity(…)最終會(huì)通過(guò)Instrumentation的execStartActivity(…)方法沦补，在這個(gè)方法中再去通過(guò)AMS Proxy去調(diào)用AMS的startActivity(...)，AMS進(jìn)行相關(guān)處理后咪橙，會(huì)回調(diào)ActivityThread的handleLaunchActivity(…)夕膀，在handleLaunchActivity(…)中會(huì)調(diào)用Instrumentation的newActivity(…)創(chuàng)建activity，并調(diào)用activity的onCrate(…)美侦、onStart(…)产舞、onResume(...)等方法

插件Activity -> 占坑Activity

• 在這個(gè)過(guò)程中，通過(guò)hook Instrumentation execStartActivity(…)實(shí)現(xiàn)插件Activity -> 占坑Activity來(lái)完成系統(tǒng)組件的驗(yàn)證
• 注意菠剩，目前 Instrumentation execStartActivity(…)存在版本差異庞瘸，具體差異見(jiàn)下文

占坑Activity -> 插件Activity

• 通過(guò)hook Instrumentation newActivity(…)來(lái)實(shí)現(xiàn)占坑Activity -> 插件Activity來(lái)完成插件Activity的創(chuàng)建

Instrumentation版本差異

• Instrumentation execStartActivity( … ) 函數(shù)存在版本差異，所以如果hook的時(shí)候可能需要做兼容赠叼，分別是：

API <= 15

• API <= 15

public ActivityResult execStartActivity(
                Context who, IBinder contextThread, IBinder token, Activity target,
                Intent intent, int requestCode, android.os.Bundle options) { ... }

API > 15

• API > 15

public ActivityResult execStartActivity(
                Context who, IBinder contextThread, IBinder token, Activity target,
                Intent intent, int requestCode, android.os.Bundle options) { ... }

Hook Application & Activity startActivity

• 回到Activity的啟動(dòng)流程擦囊，從Activity調(diào)用startActivityForResult(...)到Instrumentation到AMS Proxy，可以看到之前分別都是從Instrumentation到AMS Proxy進(jìn)行Hook嘴办，將要啟動(dòng)的插件Activity替換為占坑Activity瞬场，繞過(guò)PMS的驗(yàn)證，到創(chuàng)建Activity的時(shí)候涧郊，再hook創(chuàng)建插件Activity
• 由于hook Instrumentation以及AMS Proxy來(lái)實(shí)現(xiàn)插件Activity -> 占坑Activity存在Android不同版本問(wèn)題贯被，而且其實(shí)可以重寫(xiě)B(tài)aseActivityApplication及Activity的startActivity()方法，避免插件Activity -> 占坑Activity的兼容性問(wèn)題

開(kāi)源實(shí)現(xiàn)

DroidPlugin

• Hook AMS & hook ActivityThread的Handler的Callback

VirtualAPK

• Hook系統(tǒng)的Instrumentation execStartActivity( … ) 以及 newActivity(...)

Replugin

• Replugin在啟動(dòng)插件Activity的時(shí)候妆艘，會(huì)將要啟動(dòng)的插件Activity替換成占坑Activity彤灶，啟動(dòng)占坑Activity，這里不同的是批旺，在啟動(dòng)過(guò)程中幌陕，會(huì)建立占坑Activity與插件Activity的映射關(guān)系，等到ClassLoader去加載占坑Activity的時(shí)候汽煮，會(huì)通過(guò)映射關(guān)系去加載插件Activity搏熄，從而啟動(dòng)插件Activity
• 當(dāng)然這個(gè)流程的細(xì)節(jié)很多，代碼跳轉(zhuǎn)特別多暇赤，比較復(fù)雜心例，細(xì)節(jié)的東西很難一下子整理和注意，就不貼代碼

插件Broadcast Receiver的處理

• Broadcast Receiver的注冊(cè)方式有兩種鞋囊，在Manifest文件中靜態(tài)注冊(cè)止后，在代碼中動(dòng)態(tài)注冊(cè)
• 通過(guò)代碼動(dòng)態(tài)注冊(cè)的Broadcast Receiver不需要做任何處理，通過(guò)Manifest靜態(tài)注冊(cè)的可以在插件安裝過(guò)程中解析Manifest的Broadcast Receiver溜腐，并轉(zhuǎn)化成動(dòng)態(tài)注冊(cè)的方式
• 需要注意的是插件的Receiver只能通過(guò)隱式調(diào)用