插件化框架實現：基于kotlin的插件化框架

插件化組件的問題

• 通過類加載可以實現加載插件的代碼，但是在Android系統中，組件是有“生命”的，而且必須是合法的，也就是說有兩個問題當啟動系統組件的時候，需要處理組件的合法性和生命周期

Activity啟動流程

ActivityLaunch.png

插件化Activity的解決方案

• 代理
  • 通過宿主Activity的生命周期調用插件Activity的對應生命周期方法
  • 當然這種方式對插件的開發代碼的侵入性太大，現在業界也越來越少使用這種方式
• 欺上瞞下
  • 通過反射或者動態代理來實現系統關鍵模塊關鍵方法的hook攔截操作
  • 通過hook系統關鍵模塊來實現插件Activity -> 占坑Activity、占坑Activity -> 插件Activity的過程，通過占坑Activity來繞過PMS對組件合法性的驗證，再切換到插件Activity來實現整個欺上瞞下的過程
  • 欺上瞞下不一定需要hook系統模塊，360的RePlugin實現就是不通過hook 系統相應模塊

AMS

• 根據Activity的啟動流程，stratActivity(…)最終會通過Instrumentation的execStartActivity(…)方法：

public ActivityResult execStartActivity(
        Context who, IBinder contextThread, IBinder token, Activity target,
        Intent intent, int requestCode, Bundle options) {
    IApplicationThread whoThread = (IApplicationThread) contextThread;
    // ActivityMonitors 相關 ...
    
    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

• 通過上面代碼，我們可以找到IActivityManager作為Hook點

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

• 通過Java動態代理IActivityManager，將IActivityManager的調用轉發到IActivityManagerHandler做startActivity(...)等操作的攔截處理，實現插件Activity -> 宿主Activity的替換

宿主Activity -> 插件Activity

那怎么完成宿主Activity -> 插件Activity的轉換呢？

• 由于DroidPlugin采用hook AMS，這里講一下DroidPlugin如何實現宿主Activity -> 插件Activity，是通過hook ActivityThread的H的Callback，也就是Handler的Callback來攔截LAUNCH_ACTIVITY處理，實現宿主Activity -> 插件Activity

AMS 版本差異

Android 4.x

• Android 4.x以上抽象出了一個Singleton類，見上面代碼

Android 2.x

• Android 2.x系統直接使用了一個簡單的靜態變量存儲

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

• 根據Activity的啟動流程，stratActivity(…)最終會通過Instrumentation的execStartActivity(…)方法，在這個方法中再去通過AMS Proxy去調用AMS的startActivity(...)，AMS進行相關處理后，會回調ActivityThread的handleLaunchActivity(…)，在handleLaunchActivity(…)中會調用Instrumentation的newActivity(…)創建activity，并調用activity的onCrate(…)、onStart(…)、onResume(...)等方法

插件Activity -> 占坑Activity

• 在這個過程中，通過hook Instrumentation execStartActivity(…)實現插件Activity -> 占坑Activity來完成系統組件的驗證
• 注意，目前 Instrumentation execStartActivity(…)存在版本差異，具體差異見下文

占坑Activity -> 插件Activity

• 通過hook Instrumentation newActivity(…)來實現占坑Activity -> 插件Activity來完成插件Activity的創建

Instrumentation版本差異

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

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的啟動流程，從Activity調用startActivityForResult(...)到Instrumentation到AMS Proxy，可以看到之前分別都是從Instrumentation到AMS Proxy進行Hook，將要啟動的插件Activity替換為占坑Activity，繞過PMS的驗證，到創建Activity的時候，再hook創建插件Activity
• 由于hook Instrumentation以及AMS Proxy來實現插件Activity -> 占坑Activity存在Android不同版本問題，而且其實可以重寫BaseActivityApplication及Activity的startActivity()方法，避免插件Activity -> 占坑Activity的兼容性問題

開源實現

DroidPlugin

• Hook AMS & hook ActivityThread的Handler的Callback

VirtualAPK

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

Replugin

• Replugin在啟動插件Activity的時候，會將要啟動的插件Activity替換成占坑Activity，啟動占坑Activity，這里不同的是，在啟動過程中，會建立占坑Activity與插件Activity的映射關系，等到ClassLoader去加載占坑Activity的時候，會通過映射關系去加載插件Activity，從而啟動插件Activity
• 當然這個流程的細節很多，代碼跳轉特別多，比較復雜，細節的東西很難一下子整理和注意，就不貼代碼

插件Broadcast Receiver的處理

• Broadcast Receiver的注冊方式有兩種，在Manifest文件中靜態注冊，在代碼中動態注冊
• 通過代碼動態注冊的Broadcast Receiver不需要做任何處理，通過Manifest靜態注冊的可以在插件安裝過程中解析Manifest的Broadcast Receiver，并轉化成動態注冊的方式
• 需要注意的是插件的Receiver只能通過隱式調用