android 插件化框架VitualAPK
推荐阅读：
LeakCanary 与 鹅场Matrix ResourceCanary对比分析
Android插件化已经出来好几年了，各大厂都出了各自方案，引用Wiki中VirtualAPK和其他开源框架的对比如下：
VirtualAPK
VirtualAPK是滴滴出行自研的一款优秀的插件化框架，主要有如下几个特性。
功能完备
- 支持几乎所有的Android特性；
- 四大组件方面
四大组件均不需要在宿主manifest中预注册，每个组件都有完整的生命周期。
- Activity：支持显示和隐式调用，支持Activity的
theme和LaunchMode，支持透明主题； - Service：支持显示和隐式调用，支持Service的
start、stop、bind和unbind，并支持跨进程bind插件中的Service； - Receiver：支持静态注册和动态注册的Receiver；
- ContentProvider：支持provider的所有操作，包括
CRUD和call方法等，支持跨进程访问插件中的Provider。
- 自定义View：支持
自定义View，支持自定义属性和style，支持动画； - PendingIntent：支持
PendingIntent以及和其相关的Alarm、Notification和AppWidget； - 支持插件
Application以及插件manifest中的meta-data； - 支持插件中的
so。
VirtualAPK对插件没有额外的约束，原生的apk即可作为插件。插件工程编译生成apk后，即可通过宿主App加载，每个插件apk被加载后，都会在宿主中创建一个单独的LoadedPlugin对象。如下图所示，通过这些LoadedPlugin对象，VirtualAPK就可以管理插件并赋予插件新的意义，使其可以像手机中安装过的App一样运行。 
一、Application支持
通常情况，我们可能在Applicaton中做的事情，如下：
1.onCreate中做三方库的初始化
2.registerActivityLifeCycleCallbacks监控
3.ComponentCallbacks2支持，做些资源清理动作
4.attachBaseContext() 中 multiDex install（插件不需要考虑）
从前3方面，看看VitualAPK支持哪些？
在PluginManager加载Plugin,构建LoadedPlugin事，就构建了插件Application,代码如下：
protected Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) throws Exception { if (null != this.mApplication) { return this.mApplication; } String appClass = this.mPackage.applicationInfo.className; if (forceDefaultAppClass || null == appClass) { appClass = "android.app.Application"; } this.mApplication = instrumentation.newApplication(this.mClassLoader, appClass, this.getPluginContext()); // inject activityLifecycleCallbacks of the host application
//宿主Application 监控插件Activity的生命周期 mApplication.registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacksProxy());
//插件Application.onCreate()回调 instrumentation.callApplicationOnCreate(this.mApplication); return this.mApplication; }
从源码可以看到，在构建插件Appliation后就回调了其onCreate方法，ActivityLifecycleCallbacksProxy反射获取了宿主Application的mActivityLifecycleCallbacks，在插件Activity生命周期监控回调也派发到宿主Activity生命周期监控中。
先看看ActivityLifecycleCallbacks机制，Activity生命周期关键代码如下：
public class Activity { protected void onCreate(@Nullable Bundle savedInstanceState) { ...
//派发ActivityLifeCallbacks.onActivityCreated()方法 getApplication().dispatchActivityCreated(this, savedInstanceState); ... } protected void onStart() { ...
//派发ActivityLifeCallbacks.onActivityStarted()方法 getApplication().dispatchActivityStarted(this); ... } ... }
显而易见，Activity的生命周期监控都是其Activity生命周期函数中派发。从后文Activity支持分析中，显然插件Application可以监控到插件的Activity生命周期。
Application，Activity,Service,ContentProvider都实现了ComponentCallbacks2
//ComponentCallbacks2的接口函数 void onTrimMemory() void onConfigurationChanged(Configuration newConfig); void onLowMemory();
而这些函数都由ActivtyThread.mH发送异步消息，调用相应对应函数，而ActvityThread维护Application,Service,Activity,ContentProvider的相关记录，能够回调ComponentCallbacks2接口相应方法，但是插件Application并没有在ActivityThread记录过，而在LoadedPlugin中，并没有对ComponentCallbacks2进行相应的处理，所以VitualAPK并不支持插件Application的ComponentCallbacks2，而插件Activity,Service,ContentProvider是否支持ComponentCallbacks2，见后文。
二、Activity 支持
需要考虑如下问题：
1.怎样启动Activity
2.怎样加载activity
3.加载资源
4.怎样保证生命周期
5.是否支持多进程
6.ComponentCallbacks2支持，做些资源清理动作
1.启动Activity
正常情况下，Activity启动调用了 Instrumentation.execStartActivity方法，完成AMS远程Activity，再由mh发送异步activity启动消息，从binder线程池环境切换到ActivityThread主线程环境，开始正真的activity启动。插件里activity没有宿主AndroidManifest.xml注册，常规方法是没法启动插件activity的。对于插件 Activity 启动，VitualApk采用的是宿主 manifest 中占坑的方式来绕过系统校验，然后再加载真正的activity。
什么是占坑？就是构造一系列假的 Activity 替身，在 AndroidMainfest.xml 里面进行注册，以绕过检测，然后到了真正启动 Activity 的时候，再把它变回，去启动真正的目标 Activity。那么这一步是怎么做的呢？
坑位Activity注册如下：
<application>
<activity android:exported="false" android:name="com.didi.virtualapk.delegate.StubActivity" android:launchMode="standard"/>
<!-- Stub Activities -->
<activity android:exported="false" android:name=".A$1" android:launchMode="standard"/>
<activity android:exported="false" android:name=".A$2" android:launchMode="standard"
android:theme="@android:style/Theme.Translucent" />
<!-- Stub Activities -->
<activity android:exported="false" android:name=".B$1" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$2" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$3" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$4" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$5" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$6" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$7" android:launchMode="singleTop"/>
<activity android:exported="false" android:name=".B$8" android:launchMode="singleTop"/>
<!-- Stub Activities -->
<activity android:exported="false" android:name=".C$1" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$2" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$3" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$4" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$5" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$6" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$7" android:launchMode="singleTask"/>
<activity android:exported="false" android:name=".C$8" android:launchMode="singleTask"/>
<!-- Stub Activities -->
<activity android:exported="false" android:name=".D$1" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$2" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$3" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$4" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$5" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$6" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$7" android:launchMode="singleInstance"/>
<activity android:exported="false" android:name=".D$8" android:launchMode="singleInstance"/>
</application>
可以发现，在清单里面注册了一堆假的 StubActivity。 ABCD分别对应不同的启动模式，那么，我们启动插件的 Activity 的时候，是如何把它改为清单里面已注册的这些假的 Activity 名呢？
构建PluginManager时，Hook 了一个 VAInstrumentation 以替代系统的 Instrumentation，并ActivityThread.mH设置了callback,拦截处理Activity启动请求。
protected void hookInstrumentationAndHandler() {
try {
ActivityThread activityThread = ActivityThread.currentActivityThread();
Instrumentation baseInstrumentation = activityThread.getInstrumentation();
//Hook instrumentation,重设ActivityThread的mInstrmentation
final VAInstrumentation instrumentation = createInstrumentation(baseInstrumentation);
Reflector.with(activityThread).field("mInstrumentation").set(instrumentation);
//Hook Handler mh,设置其mCallback,拦截Activity启动消息
Handler mainHandler = Reflector.with(activityThread).method("getHandler").call();
Reflector.with(mainHandler).field("mCallback").set(instrumentation);
this.mInstrumentation = instrumentation;
Log.d(TAG, "hookInstrumentationAndHandler succeed : " + mInstrumentation);
} catch (Exception e) {
Log.w(TAG, e);
}
}
VAInstrumentation 相关的代码如下：
public ActivityResult execStartActivity(...) { injectIntent(intent); return mBase.execStartActivity(...); } protected void injectIntent(Intent intent) {
//确定Intent Component targetActivity的packageName,从已经加载的插件中检索 mPluginManager.getComponentsHandler().transformIntentToExplicitAsNeeded(intent); // null component is an implicitly intent if (intent.getComponent() != null) { Log.i(TAG, String.format("execStartActivity[%s : %s]", intent.getComponent().getPackageName(), intent.getComponent().getClassName())); // resolve intent with Stub Activity if needed 用那些注册的假的StubActivity来替换真实的Activity，以绕过检测 this.mPluginManager.getComponentsHandler().markIntentIfNeeded(intent); } }
绕过了系统的检测，通过mH发送LAUNCH_ACTIVITY的异步消息，由于Hook的时候设置了callback,拦截了LAUNCH_ACTIVITY,给Intent设置了插件的Theme,classloader,然后按照mH原有的逻辑走。
提个问题，通过adb shell dumpsys activity activities可以看到插件Activity? 显然只能看到坑位Activity,因为在AMS登记的是坑位Activity,验证如下：
2.加载activity
当ActivityThread使用Instrumentation.newActivity,构造activity，自然是调用VAInstrumentation的newActivity方法,代码如下：
public Activity newActivity(ClassLoader cl, String className, Intent intent) throws InstantiationException, IllegalAccessException, ClassNotFoundException { try {
//先使用host 的 classloader加载类 cl.loadClass(className); Log.i(TAG, String.format("newActivity[%s]", className)); } catch (ClassNotFoundException e) {
//根据intent 从加载的插件中检索到 插件Activity ComponentName component = PluginUtil.getComponent(intent); if (component == null) { return newActivity(mBase.newActivity(cl, className, intent)); }
String targetClassName = component.getClassName(); Log.i(TAG, String.format("newActivity[%s : %s/%s]", className, component.getPackageName(), targetClassName)); LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(component); if (plugin == null) { // Not found then goto stub activity. boolean debuggable = false; try { Context context = this.mPluginManager.getHostContext(); debuggable = (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0; } catch (Throwable ex) { } if (debuggable) { throw new ActivityNotFoundException("error intent: " + intent.toURI()); } Log.i(TAG, "Not found. starting the stub activity: " + StubActivity.class); return newActivity(mBase.newActivity(cl, StubActivity.class.getName(), intent)); }
//插件的Activity,使用插件自己的classloader,用插件Activity类，替换坑位Activity类名 Activity activity = mBase.newActivity(plugin.getClassLoader(), targetClassName, intent); activity.setIntent(intent); // for 4.1+ 把插件Activity的Resources设置为Resources Reflector.QuietReflector.with(activity).field("mResources").set(plugin.getResources()); return newActivity(activity); } return newActivity(mBase.newActivity(cl, className, intent)); }
优先使用宿主host的classloader加载Activity,找不到，若是插件Activity,替换坑位Activity,使用插件的classloader加载。
那么插件的classloader是怎样构建的，代码如下：
protected ClassLoader createClassLoader(Context context, File apk, File libsDir, ClassLoader parent) throws Exception { File dexOutputDir = getDir(context, Constants.OPTIMIZE_DIR); String dexOutputPath = dexOutputDir.getAbsolutePath();
//插件classloder的 parent 为宿主host的classloader
//插件plugin可以加载宿主host的class,宿主host不能插件plugin的class DexClassLoader loader = new DexClassLoader(apk.getAbsolutePath(), dexOutputPath, libsDir.getAbsolutePath(), parent);
//开启加载器组合，插件的dex,so文件都设置host classloader的dexPathList（见BaseDexClassLoader）
//这样host与plugin,plugin与plugin之间可以互相加载对方的class了 if (Constants.COMBINE_CLASSLOADER) { DexUtil.insertDex(loader, parent, libsDir); } return loader; }
VirtualApk始终开启COMBINE_CLASSLOADER，也就是说host与plugin,plugin与plugin之间可以互相加载对方的class了。
3.资源加载
在VAInstrumentation.newActivity中，插件Activty的mResources 被设置为对应插件的Resources
Reflector.QuietReflector.with(activity).field("mResources").set(plugin.getResources());
那么看看插件的Resources是怎样构建的，代码如下：
if (Constants.COMBINE_RESOURCES) {
//资源组合开启，则把插件的apk路径添加宿主Resources的相关的参数，并把插件resources替换为宿主的resrouces,
//这个过程很复杂，需要同步所有应用Resources地方，需要兼容 系统版本api和rom return ResourcesManager.createResources(context, packageName, apk); } else {
//插件只能访问自身的Resource资源 Resources hostResources = context.getResources(); AssetManager assetManager = createAssetManager(context, apk); return new Resources(assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration()); }
VirtualApk始终开启COMBINE_RESOURCES，也就是说host与plugin,plugin与plugin之间可以互相加载对方的Reources资源了。
4.生命周期回调
ActivtyThread维护这启动的activity集合ArrayMap<IBinder, ActivityClientRecord> mActivities，自然而然生命周期也就同步了，需要注意的是：在调度插件的onCreate生命周期函数需要需要设置插件Activity的mBase，mResource,mApplication等，因为在Activity实例化后，进行attch动作，需要重置为插件对应的配置。
protected void injectActivity(Activity activity) { final Intent intent = activity.getIntent(); if (PluginUtil.isIntentFromPlugin(intent)) { Context base = activity.getBaseContext(); try { LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(intent); Reflector.with(base).field("mResources").set(plugin.getResources()); Reflector reflector = Reflector.with(activity); reflector.field("mBase").set(plugin.createPluginContext(activity.getBaseContext())); reflector.field("mApplication").set(plugin.getApplication()); // set screenOrientation ActivityInfo activityInfo = plugin.getActivityInfo(PluginUtil.getComponent(intent)); if (activityInfo.screenOrientation != ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED) { activity.setRequestedOrientation(activityInfo.screenOrientation); } // for native activity ComponentName component = PluginUtil.getComponent(intent); Intent wrapperIntent = new Intent(intent); wrapperIntent.setClassName(component.getPackageName(), component.getClassName()); activity.setIntent(wrapperIntent); } catch (Exception e) { Log.w(TAG, e); } }
}
5.是否多进程
插件Activity在其他进程中启动
<activity android:name=".OtherProcessActivity" android:process=":other"、>
打开该插件Activity，会创建该界面，adb查看相关进程，结果如下：
没发现：other相关的进程，想想也是，坑位Activity都没有设置android:Process，只能运行在主进程中。
6.支持ComponentCallbacks2，做些资源清理动作
插件Activity在ActivityThread有登记，收集的ComponentCallbacks2接口，包括了插件Activity，所以能派发到插件Activity。
三、Service支持
需要考虑如下问题：
1.Service启动
2.是否支持多进程
3.Service生命周期
4.是否支持ComponentCallbacks2，做些资源清理动作
1.Service启动
动态代理AMS，拦截service相关的请求，将其中转给Service Runtime去处理，Service Runtime会接管系统的所有操作
public class ActivityManagerProxy implements InvocationHandler { if ("startService".equals(method.getName())) { try { return startService(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Start service error", e); } } else if ("stopService".equals(method.getName())) { try { return stopService(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Stop Service error", e); } } else if ("stopServiceToken".equals(method.getName())) { try { return stopServiceToken(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Stop service token error", e); } } else if ("bindService".equals(method.getName())) { try { return bindService(proxy, method, args); } catch (Throwable e) { Log.w(TAG, e); } } else if ("unbindService".equals(method.getName())) { try { return unbindService(proxy, method, args); } catch (Throwable e) { Log.w(TAG, e); } } else if ("getIntentSender".equals(method.getName())) { try { getIntentSender(method, args); } catch (Exception e) { Log.w(TAG, e); } } else if ("overridePendingTransition".equals(method.getName())){ try { overridePendingTransition(method, args); } catch (Exception e){ Log.w(TAG, e); } } try { // sometimes system binder has problems. return method.invoke(this.mActivityManager, args); } catch (Throwable th) { ... }
protected ComponentName startDelegateServiceForTarget(Intent target, ServiceInfo serviceInfo, Bundle extras, int command) {
//把插件Service相关操作的Intent 转为为 坑位Service相关命令派发的Intent
Intent wrapperIntent = wrapperTargetIntent(target, serviceInfo, extras, command);
return mPluginManager.getHostContext().startService(wrapperIntent);
}
}
Service runtime也注册两个坑位Service,由坑位Service分发插件Service的相关操作，一个LocalService,用来派发与宿主同进程的插件service操作，一个是RemoteService,用来派发与宿主不同进程的插件service操作，插件service并没有在AMS、ActivityThread登记过，由Service runtime自身维护。
2.是否支持多进程
RemoteService用来派发与宿主不同进程的插件service操作，只不过插件Service运行在RemoteService所在的:daemon,没有运行在插件Service指定的进程上。
3.Service生命周期
坑位Service在派发插件Service操作的时候，会回调相应的生命周期的周期函数。
需要注意以下两点：
1）通常情况下bindService启动Service,该Service的生命周期跟绑定着生命周期一致，但是插件Service有VitualAPK Service runtime维护，runtime没有做插件Serice跟绑定者生命周期一致处理，需要手动调用unbindService，关闭该Service。
2）通常情况下startService和bindService或者使用，关闭Service需要调用stop和unbind方法，而插件Service混合启动，只需要调用stop或者unbind方法就可以关闭Service|。
4.不支持ComponentCallbacks2，做些资源清理动作
插件Service没有在ActivityThread登记，收集的ComponentCallbacks2没有包括插件Service,所以插件不支持ComponentCallbacks2。
四、BroadcastReceiver支持
BroadcastRecevier注册分为动态注册和静态注册。
插件BroadcastRecevier的动态注册，只需要能够加载到插件BroadcastReceiver类即可，在前文分析中插件与宿主、插件与插件的classloader都可以加载对方的类，显然VitaulAPK是支持插件的动态注册。
插件BroadcastRecevier的静态注册，即在插件的AndroidManifest.xml中注册，VituaAPK在加载插件时，通过PackageParserCompat的parsePackage方法解析了AndroidManifest.xml中Application和四大组件信息，
然后反射实例化插件BroadcastRecevier把插件的静态注册改为动态注册，代码如下：
public LoadedPlugin(PluginManager pluginManager, Context context, File apk) throws Exception { this.mPackage = PackageParserCompat.parsePackage(context, apk, PackageParser.PARSE_MUST_BE_APK); this.mPackageInfo.packageName = this.mPackage.packageName; if (pluginManager.getLoadedPlugin(mPackageInfo.packageName) != null) { throw new RuntimeException("plugin has already been loaded : " + mPackageInfo.packageName); } // Register broadcast receivers dynamically Map<ComponentName, ActivityInfo> receivers = new HashMap<ComponentName, ActivityInfo>(); for (PackageParser.Activity receiver : this.mPackage.receivers) { receivers.put(receiver.getComponentName(), receiver.info); //反射实例化BroadcastReceiver BroadcastReceiver br = BroadcastReceiver.class.cast(getClassLoader().loadClass(receiver.getComponentName().getClassName()).newInstance()); for (PackageParser.ActivityIntentInfo aii : receiver.intents) { this.mHostContext.registerReceiver(br, aii);//动态注册 } } this.mReceiverInfos = Collections.unmodifiableMap(receivers); this.mPackageInfo.receivers = receivers.values().toArray(new ActivityInfo[receivers.size()]); }
当然插件的静态注册，在唤醒app的广播接收中会失效。
五、ContentProvider支持
ContentProvider是数据共享型组件，进程间和进程内均可共享，由ContentResolver统一管理访问ContentProvider,我们通过使用context.getContentResolver()，context的实例为contextImpl,ContentResolver通过IContentProvider远程服务代理访问ContentProvider服务接口增删改查。IContentProvider服务代理从ActivityThread中获取，如下：
public final IContentProvider acquireProvider( Context c, String auth, int userId, boolean stable) {
//从本进程中获取 final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable); if (provider != null) { return provider; } // There is a possible race here. Another thread may try to acquire // the same provider at the same time. When this happens, we want to ensure // that the first one wins. // Note that we cannot hold the lock while acquiring and installing the // provider since it might take a long time to run and it could also potentially // be re-entrant in the case where the provider is in the same process. IActivityManager.ContentProviderHolder holder = null; try {
//从ams中获取 holder = ActivityManagerNative.getDefault().getContentProvider( getApplicationThread(), auth, userId, stable); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } if (holder == null) { Slog.e(TAG, "Failed to find provider info for " + auth); return null; } // Install provider will increment the reference count for us, and break // any ties in the race. holder = installProvider(c, holder, holder.info, true /*noisy*/, holder.noReleaseNeeded, stable); return holder.provider; }
可以IContentProvider的来源，ActivityThread和AMS，优先从本进程中获取。在应用的启动时候，ContentProvider也跟着启动，在AMS中有相应的记录，
插件ContentProvider在AMS中没有记录，VitualApk使用代理转发，宿主坑位ContentProvider拦截了ContentProvider操作，由坑位ContentProvider派发到具体的插件ContentProvider,代码如下：
public class RemoteContentProvider extends ContentProvider { private static final String TAG = Constants.TAG_PREFIX + "RemoteContentProvider"; public static final String KEY_PKG = "pkg"; public static final String KEY_PLUGIN = "plugin"; public static final String KEY_URI = "uri"; public static final String KEY_WRAPPER_URI = "wrapper_uri"; private static Map<String, ContentProvider> sCachedProviders = new HashMap<>(); @Override public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
//获取插件的ContentProvider ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.query(pluginUri, projection, selection, selectionArgs, sortOrder); } return null; } @Override public Uri insert(Uri uri, ContentValues values) {
//获取插件的ContentProvider ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.insert(pluginUri, values); } return uri; } @Override public int delete(Uri uri, String selection, String[] selectionArgs) {
//获取插件的ContentProvider ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.delete(pluginUri, selection, selectionArgs); } return 0; } @Override public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
//获取插件的ContentProvider ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.update(pluginUri, values, selection, selectionArgs); } return 0; } @Override public int bulkInsert(Uri uri, ContentValues[] values) { ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.bulkInsert(pluginUri, values); } return 0; } ... }
插件中ContentProvider没有经过Android Framework层，由坑位ContentProvider维护。
插件有自己的ContentResolver:PluginContentResolver,插件访问ContentProvider时，先从插件管理器中找对应ProviderInfo,找到了则用插件的IContentProvider，否则使用宿主的IContentProvider。
@Override protected IContentProvider acquireProvider(Context context, String auth) { if (mPluginManager.resolveContentProvider(auth, 0) != null) { return mPluginManager.getIContentProvider(); } return super.acquireProvider(context, auth); } @Override protected IContentProvider acquireExistingProvider(Context context, String auth) { if (mPluginManager.resolveContentProvider(auth, 0) != null) { return mPluginManager.getIContentProvider(); } return super.acquireExistingProvider(context, auth); } @TargetApi(Build.VERSION_CODES.JELLY_BEAN) @Override protected IContentProvider acquireUnstableProvider(Context context, String auth) { if (mPluginManager.resolveContentProvider(auth, 0) != null) { return mPluginManager.getIContentProvider(); } return super.acquireUnstableProvider(context, auth); }
那么插件中IContentProvider,怎来的了？宿主坑位ContentProvider,在ActivityThread中肯定存在对应IContentProvider,插件IContentProvider，对其进行动态代理构建了一个。
protected void hookIContentProviderAsNeeded() { Uri uri = Uri.parse(RemoteContentProvider.getUri(mContext)); mContext.getContentResolver().call(uri, "wakeup", null, null); try { Field authority = null; Field provider = null; ActivityThread activityThread = ActivityThread.currentActivityThread(); Map providerMap = Reflector.with(activityThread).field("mProviderMap").get(); Iterator iter = providerMap.entrySet().iterator(); while (iter.hasNext()) { Map.Entry entry = (Map.Entry) iter.next(); Object key = entry.getKey(); Object val = entry.getValue(); String auth; if (key instanceof String) { auth = (String) key; } else { if (authority == null) { authority = key.getClass().getDeclaredField("authority"); authority.setAccessible(true); } auth = (String) authority.get(key); } if (auth.equals(RemoteContentProvider.getAuthority(mContext))) { if (provider == null) { provider = val.getClass().getDeclaredField("mProvider"); provider.setAccessible(true); }
//插件IContentProvider IContentProvider rawProvider = (IContentProvider) provider.get(val); IContentProvider proxy = IContentProviderProxy.newInstance(mContext, rawProvider); mIContentProvider = proxy; Log.d(TAG, "hookIContentProvider succeed : " + mIContentProvider); break; } } } catch (Exception e) { Log.w(TAG, e); } }
IContentProviderProxyi的nvoke函数首先将访问插件的Uri转到宿主占坑Uri
@Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Log.v(TAG, method.toGenericString() + " : " + Arrays.toString(args));
//插件Uri转为宿主占坑Uri
wrapperUri(method, args); try { return method.invoke(mBase, args); } catch (InvocationTargetException e) { throw e.getTargetException(); }
}
插件的Uri转到宿主占坑Uri,代码如下：
//
public static Uri wrapperUri(LoadedPlugin loadedPlugin, Uri pluginUri) { String pkg = loadedPlugin.getPackageName(); String pluginUriString = Uri.encode(pluginUri.toString()); StringBuilder builder = new StringBuilder(RemoteContentProvider.getUri(loadedPlugin.getHostContext())); builder.append("/?plugin=" + loadedPlugin.getLocation()); builder.append("&pkg=" + pkg); builder.append("&uri=" + pluginUriString); Uri wrapperUri = Uri.parse(builder.toString()); return wrapperUri; }
总结
VitualAPK 四大组件实现原理如下：
1.Activity 采用宿主manifest中占坑的方式来绕过系统校验，然后再加载真正的activity；
2.Service 动态代理AMS，拦截service相关的请求，将其中转给Service Runtime去处理，Service Runtime会接管系统的所有操作；
3.Receiver 将插件中静态注册的receiver重新注册一遍；
4.ContentProvider 动态代理IContentProvider，拦截provider相关的请求，将其中转给Provider Runtime去处理，Provider Runtime会接管系统的所有操作。
插件组件需要注意的地方：
参考资料：
VirtualApk源码分析-BroadcastReceiver插件化
VirtualApk源码分析-ContentProvider插件化
如果您对博主的更新内容持续感兴趣，请关注公众号！
