插件化框架实现：基于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只能通过隐式调用