android 插件化框架VitualAPK

Posted sihaixuan

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了android 插件化框架VitualAPK相关的知识，希望对你有一定的参考价值。

推荐阅读：

滴滴Booster移动App质量优化框架-学习之旅 一

Android 模块Api化演练

不一样视角的Glide剖析(一)

LeakCanary 与 鹅场Matrix ResourceCanary对比分析

 

android插件化已经出来好几年了，各大厂都出了各自方案，引用Wiki中VirtualAPK和其他开源框架的对比如下：

技术图片

 

 

VirtualAPK

VirtualAPK是滴滴出行自研的一款优秀的插件化框架，主要有如下几个特性。

功能完备

  • 支持几乎所有的Android特性；
  • 四大组件方面

四大组件均不需要在宿主manifest中预注册，每个组件都有完整的生命周期。

  1. Activity：支持显示和隐式调用，支持Activity的theme和LaunchMode，支持透明主题；
  2. Service：支持显示和隐式调用，支持Service的start、stop、bind和unbind，并支持跨进程bind插件中的Service；
  3. Receiver：支持静态注册和动态注册的Receiver；
  4. 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。那么这一步是怎么做的呢？

真坑注册如下：

    <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;







 


Uri变成了content://host_authority/plugin_authority，其中host_authority表示宿主占坑ContentProvider对应的Auth，plugin_authority代表了实际要启动的插件ContentProvider的Auth,由此可以插件的ContentProvider的数据保存占坑ContentProvider中。


 


插件ContentProvider onCreate回调


占坑ContentProvider维护这插件的ContentProvider,在构建插件的ConentProvider之后，调用了attch方法，会回调onCreate方法。


 


不支持插件ContentProvider ComponentCallbacks2


插件的ContentProvider没有ActivityCurrent记录过，占坑ContentProvider维护这插件的ContentProvider，占坑ContentProvider没有重载相关ComponentCallbacks2接口方法，对插件ContentProvider进行派发。


总结



VitualAPK 四大组件实现原理如下：




1.Activity 采用宿主manifest中占坑的方式来绕过系统校验，然后再加载真正的activity；


2.Service 动态代理AMS，拦截service相关的请求，将其中转给Service Runtime去处理，Service Runtime会接管系统的所有操作；


3.Receiver 将插件中静态注册的receiver重新注册一遍；


4.ContentProvider 动态代理IContentProvider，拦截provider相关的请求，将其中转给Provider Runtime去处理，Provider Runtime会接管系统的所有操作。


 


插件组件需要注意的地方：


技术图片


 


 


 






 


参考资料：


didi/VirtualAPK/wiki


VirtualApk源码分析-BroadcastReceiver插件化


onLowMemory执行流程


 VirtualApk源码分析-ContentProvider插件化


 


如果您对博主的更新内容持续感兴趣，请关注公众号！


技术图片
以上是关于android 插件化框架VitualAPK的主要内容，如果未能解决你的问题，请参考以下文章
 

 Android 插件化Hook 插件化框架 ( hook 插件化原理 | 插件包管理 )


 Android 插件化“ 插桩式 “ 插件化框架 ( 运行应用 | 代码整理 )


 Android 插件化“ 插桩式 “ 插件化框架 ( 注入上下文的使用 )


 Android 插件化Hook 插件化框架 ( 反射工具类 | 反射常用操作整理 )


 Android 插件化“ 插桩式 “ 插件化框架 ( 获取插件入口 Activity 组件 | 加载插件 Resources 资源 )


 Android 插件化Hook 插件化框架 ( 通过反射获取 “插件包“ 中的 Element[] dexElements )