插件化框架实现：基于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
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, android.os.Bundle options) { ... }
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只能通过隐式调用
