在分析ContentProvider的工作原理的过程中我们提出了一种插件化方案：在进程启动之初，
手动把ContentProvider安装到本进程，使得后续对于插件ContentProvider的请求能够顺利完成。
我们也指出它的一个严重缺陷，那就是它只能在插件系统内部掩耳盗铃，在插件系统之外，
第三方App依然无法感知到插件中的ContentProvider的存在。
如果插件的ContentProvider组件仅仅是为了共享给其他插件或者宿主程序使用，那么这种方案可以解决问题；
不需要Hook AMS，非常简单。
但是，如果希望把插件ContenProvider共享给整个系统呢？在分析AMS中获取ContentProvider的过程中我们了解到，
ContentProvider信息的注册是在Android系统启动或者新安装App的时候完成的，而AMS把ContentProvider返回
给第三方App也是在system_server进程完成；我们无法对其暗箱操作。
在完成Activity，Service组件的插件化之后，这种限制对我们来说已经是小case了：我们在宿主程序里面注册一个货真价实、
被系统认可的StubContentProvider组件，把这个组件共享给第三方App；
然后通过代理分发技术把第三方App对于插件ContentProvider的请求通过这个StubContentProvider分发给对应的插件。
但是这还存在一个问题，由于第三方App查阅的其实是StubContentProvider，因此他们查阅的URI也必然是
StubContentProvider的authority，要查询到插件的ContentProvider，必须把要查询的真正的插件ContentProvider信息传递进来。
这个问题的解决方案也很容易，我们可以制定一个「插件查询协议」来实现。
举个例子，假设插件系统的宿主程序在AndroidManifest.xml中注册了一个StubContentProvider，
它的Authority为com.test.host_authority；由于这个组件被注册在AndroidManifest.xml中，是系统认可的ContentProvider组件，
整个系统都是可以使用这个共享组件的，使用它的URI一般为content://com.test.host_authority；
那么，如果插件系统中存在一个插件，这个插件提供了一个PluginContentProvider，它的Authority为com.test.plugin_authorith，
因为这个插件的PluginContentProvider没有在宿主程序的AndroidMainifest.xml中注册（预先注册就失去插件的意义了），
整个系统是无法感知到它的存在的；前面提到代理分发技术，也就是，我们让第三方App请求宿主程序的StubContentProvider，
这个 StubContentProvider把请求转发给合适的插件的ContentProvider就能完成了(插件内部通过预先 installProvider可以查询所有的ContentProvider组件)；
这个协议可以有很多，比如说：如果第三方App需要请求插件的 StubContentProvider，
可以以content://com.test.host_authority/com.test.plugin_authorith去查询系统；也就是说，
我们假装请求StubContentProvider，把真正的需要请求的PluginContentProvider的 Authority放在路径参数里面，
StubContentProvider收到这个请求之后，拿到这个真正的Authority去请求插件的 PluginContentProvider，
拿到结果之后再返回给第三方App。
这样，我们通过「代理分发技术」以及「插件查询协议」可以完美解决「共享」的问题，
开篇提到了我们之前对于Activity，Service组件插件化方案中对于「共享」功能的缺失，按照这个思路，基本可以解决这一系列问题。
比如，对于第三方App无法绑定插件服务的问题，我们可以注册一个StubService，把真正需要bind的插件服务信息放在intent的某个字段中，
然后在StubService的onBind中解析出这个插件 服务信息，然后去拿到插件Service组件的Binder对象返回给第三方。实现步骤如下.
要实现预先installProvider，我们首先需要知道，所谓的「预先」到底是在什么时候？
前文我们提到过App进程安装ContentProvider的时机非常之早，在Application类的onCreate回调执行之前已经完成了；这意味着什么？
现在我们对于ContentProvider插件化的实现方式是通过「代理分发技术」，也就是说在请求插件ContentProvider的时候会
先请求宿主程序的StubContentProvider；如果一个第三方App查询插件的ContentProvider，而宿主程序没有启动的 话，
AMS会启动宿主程序并等待宿主程序的StubContentProvider完成安装，一旦安装完成就会把得到的IContentProvider
返回给这个第三方App；第三方App拿到IContentProvider这个Binder对象之后就可能发起CURD操作，
如果这个时候插件ContentProvider还没有启动，那么肯定就会出异常；要记住，“这个时候”可能宿主程序的onCreate还没有执行完毕呢！！
所以，我们基本可以得出结论，预先安装这个所谓的「预先」必须早于Application的onCreate方法，
在Android SDK给我们的回调里面，attachBaseContent这个方法是可以满足要求的，它在Application这个对象被创建之后就会立即调用。
解决了时机问题，那么我们接下来就可以安装ContentProvider了。
安装ContentProvider也就是要调用ActivityThread类的installProvider方法，这个方法需要的参数有点多，
而且它的第二个参数IActivityManager.ContentProviderHolder是一个隐藏类，我们不知道如何构造，
就算通过反射构造由于SDK没有暴露稳定性不易保证，我们看看有什么方法调用了这个installProvider。
installContentProviders这个方法直接调用installProvder看起来可以使用，但是它是一个private的方法，还有public的方法吗？继续往上寻找调用链，发现了installSystemProviders这个方法：
public final void installSystemProviders(List<ProviderInfo> providers) { if (providers != null) { installContentProviders(mInitialApplication, providers); } }但是，我们说过ContentProvider的安装必须相当早，必须在Application类的attachBaseContent方法内，
而这个mInitialApplication字段是在onCreate方法调用之后初始化的，所以，如果直接使用这个installSystemProviders势必抛出空指针异常；
因此，我们只有退而求其次，选择通过installContentProviders这个方法完成ContentProvider的安装.
要调用这个方法必须拿到ContentProvider对应的ProviderInfo，这个我们在之前也介绍过，可以通过PackageParser类完成，
当然这个类有一些兼容性问题，我们需要手动处理：
/** * 解析Apk文件中的 <provider>, 并存储起来 * 主要是调用PackageParser类的generateProviderInfo方法 * * @param apkFile 插件对应的apk文件 * @throws Exception 解析出错或者反射调用出错, 均会抛出异常 */ public static List<ProviderInfo> parseProviders(File apkFile) throws Exception { Class<?> packageParserClass = Class.forName("android.content.pm.PackageParser"); Method parsePackageMethod = packageParserClass.getDeclaredMethod("parsePackage", File.class, int.class); Object packageParser = packageParserClass.newInstance(); // 首先调用parsePackage获取到apk对象对应的Package对象 Object packageObj = parsePackageMethod.invoke(packageParser, apkFile, PackageManager.GET_PROVIDERS); // 读取Package对象里面的services字段 // 接下来要做的就是根据这个List<Provider> 获取到Provider对应的ProviderInfo Field providersField = packageObj.getClass().getDeclaredField("providers"); List providers = (List) providersField.get(packageObj); // 调用generateProviderInfo 方法, 把PackageParser.Provider转换成ProviderInfo Class<?> packageParser$ProviderClass = Class.forName("android.content.pm.PackageParser$Provider"); Class<?> packageUserStateClass = Class.forName("android.content.pm.PackageUserState"); Class<?> userHandler = Class.forName("android.os.UserHandle"); Method getCallingUserIdMethod = userHandler.getDeclaredMethod("getCallingUserId"); int userId = (Integer) getCallingUserIdMethod.invoke(null); Object defaultUserState = packageUserStateClass.newInstance(); // 需要调用 android.content.pm.PackageParser#generateProviderInfo Method generateProviderInfo = packageParserClass.getDeclaredMethod("generateProviderInfo", packageParser$ProviderClass, int.class, packageUserStateClass, int.class); List<ProviderInfo> ret = new ArrayList<>(); // 解析出intent对应的Provider组件 for (Object service : providers) { ProviderInfo info = (ProviderInfo) generateProviderInfo.invoke(packageParser, service, 0, defaultUserState, userId); ret.add(info); } return ret; }解析出ProviderInfo之后，就可以直接调用installContentProvider了：
/** * 在进程内部安装provider, 也就是调用 ActivityThread.installContentProviders方法 * * @param context you know * @param apkFile * @throws Exception */ public static void installProviders(Context context, File apkFile) throws Exception { List<ProviderInfo> providerInfos = parseProviders(apkFile); for (ProviderInfo providerInfo : providerInfos) { providerInfo.applicationInfo.packageName = context.getPackageName(); } Log.d("test", providerInfos.toString()); Class<?> activityThreadClass = Class.forName("android.app.ActivityThread"); Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread"); Object currentActivityThread = currentActivityThreadMethod.invoke(null); Method installProvidersMethod = activityThreadClass.getDeclaredMethod("installContentProviders", Context.class, List.class); installProvidersMethod.setAccessible(true); installProvidersMethod.invoke(currentActivityThread, context, providerInfos); }整个安装过程必须在Application类的attachBaseContent里面完成：
/** * 一定需要Application，并且在attachBaseContext里面Hook * 因为provider的初始化非常早，比Application的onCreate还要早 * 在别的地方hook都晚了。 */ public class UPFApplication extends Application { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); try { File apkFile = getFileStreamPath("testcontentprovider-debug.apk"); if (!apkFile.exists()) { Utils.extractAssets(base, "testcontentprovider-debug.apk"); } File odexFile = getFileStreamPath("test.odex"); // Hook ClassLoader, 让插件中的类能够被成功加载 BaseDexClassLoaderHookHelper.patchClassLoader(getClassLoader(), apkFile, odexFile); ProviderHelper.installProviders(base, getFileStreamPath("testcontentprovider-debug.apk")); } catch (Exception e) { throw new RuntimeException("hook failed", e); } } }把插件中的ContentProvider安装到插件系统中之后，在插件内部就可以自由使用这些ContentProvider了；
要把这些插件共享给整个系统，我们还需要一个货真价实的ContentProvider组件来执行分发：
<provider android:name="com.example.weishu.contentprovider_management.StubContentProvider" android:authorities="com.example.weishu.contentprovider_management.StubContentProvider" android:process=":p" android:exported="true" />第三方App如果要查询到插件的ContentProvider，必须遵循一个「插件查询协议」，
这样StubContentProvider才能把对于插件的请求分发到正确的插件组件：
/** * 为了使得插件的ContentProvder提供给外部使用，我们需要一个StubProvider做中转； * 如果外部程序需要使用插件系统中插件的ContentProvider，不能直接查询原来的那个uri * 我们对uri做一些手脚，使得插件系统能识别这个uri； * 这里的处理方式如下： * 原始查询插件的URI应该为：content://plugin_auth/path/query * 如果需要查询插件，需要修改为： content://stub_auth/plugin_auth/path/query * 也就是，我们把插件ContentProvider的信息放在URI的path中保存起来； * 然后在StubProvider中做分发。 * 当然，也可以使用QueryParamerter,比如： * content://plugin_auth/path/query/ -> content://stub_auth/path/query?plugin=plugin_auth * @param raw 外部查询我们使用的URI * @return 插件真正的URI */ private Uri getRealUri(Uri raw) { String rawAuth = raw.getAuthority(); if (!AUTHORITY.equals(rawAuth)) { Log.w(TAG, "rawAuth:" + rawAuth); } String uriString = raw.toString(); uriString = uriString.replaceAll(rawAuth + '/', ""); Uri newUri = Uri.parse(uriString); Log.i(TAG, "realUri:" + newUri); return newUri; }通过以上过程我们就实现了ContentProvider的插件化。需要说明的是，DroidPlugind的插件化与上述介绍的方案有一些不同之处：
1.首先DroidPlugin并没有选择预先安装的方案，而是选择HookActivityManagerNative，
拦截它的getContentProvider以及publishContentProvider方法实现 对于插件组件的控制；
从这里可以看出它对ContentProvider与Service的插件化几乎是相同的，Hook才是DroidPlugin Style ^_^.
2.然后，关于携带插件信息，或者说「插件查询协议」方面；DroidPlugin把插件信息放在查询参数里面，本文呢则是路径参数；这一点完全看个人喜好。
本文我们通过「代理分发技术」以及「插件查询协议」完成了ContentProvider组件的插件化，
并且给出了对「插件共享组件」的问题的一般解决方案。值得一提的是，系统的ContentProvider其实是lazy load的，
也就是说只有在需要使用的时候才会启动对应的ContentProvider，而我们对于插件的实现则是预先加载，
这里还有改进的空间，读者可以思考一下解决方案。
由于ContentProvider的使用频度非常低，而很多它使用的场景（比如系统）并不太需要「插件化」，
因此在实际的插件方案中，提供 ContentProvider插件化的方案非常之少；就算需要实现ContentProvider的插件化，
也只是解决插件内部之间共享组件的问题，并没有把插件组件暴露给整个系统。我个人觉得，如果只是希望插件化，
那么是否支持ContentProvider无伤大雅，但是，如果希望实现虚拟化或者说容器技术，所有组件是必须支持插件化的。
