android 插件加载机制之二

Posted 2020-09-14 Achillisjack

------本文转载自 Android插件化原理解析——插件加载机制 

    这一系列的文章实在是写的好!

5 Hook ClassLoader

从上述分析中我们得知，在获取LoadedApk的过程中使用了一份缓存数据；

这个缓存数据是一个Map，从包名到LoadedApk的一个映射。正常情况下，我们的插件肯定不会存在于这个对象里面；

但是如果我们手动把我们插件的信息添加到里面呢？系统在查找缓存的过程中，会直接命中缓存！

进而使用我们添加进去的LoadedApk的ClassLoader来加载这个特定的Activity类！这样我们就能接管我们自己插件类的加载过程了！

这个缓存对象mPackages存在于ActivityThread类中；老方法，我们首先获取这个对象：

// 先获取到当前的ActivityThread对象
Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
currentActivityThreadMethod.setAccessible(true);
Object currentActivityThread = currentActivityThreadMethod.invoke(null);

// 获取到 mPackages 这个静态成员变量, 这里缓存了dex包的信息
Field mPackagesField = activityThreadClass.getDeclaredField("mPackages");
mPackagesField.setAccessible(true);
Map mPackages = (Map) mPackagesField.get(currentActivityThread);

拿到这个Map之后接下来怎么办呢？我们需要填充这个map，把插件的信息塞进这个map里面，

以便系统在查找的时候能命中缓存。但是这个填充这个Map我们出了需要包名之外，

还需要一个LoadedApk对象；如何创建一个LoadedApk对象呢？

我们当然可以直接反射调用它的构造函数直接创建出需要的对象，但是万一哪里有疏漏，构造参数填错了怎么办？

又或者Android的不同版本使用了不同的参数，导致我们创建出来的对象与系统创建出的对象不一致，无法work怎么办？

因此我们需要使用与系统完全相同的方式创建LoadedApk对象；从上文分析得知，

系统创建LoadedApk对象是通过getPackageInfo来完成的，因此我们可以调用这个函数来创建LoadedApk对象；

但是这个函数是private的，我们无法使用。

有的童鞋可能会有疑问了，private不是也能反射到吗？我们确实能够调用这个函数，

但是private表明这个函数是内部实现，或许那一天Google高兴，把这个函数改个名字我们就直接GG了；

但是public函数不同，public被导出的函数你无法保证是否有别人调用它，因此大部分情况下不会修改；

我们最好调用public函数来保证尽可能少的遇到兼容性问题。

（当然，如果实在木有路可以考虑调用私有方法，自己处理兼容性问题，这个我们以后也会遇到）

间接调用getPackageInfo这个私有函数的public函数有同名的getPackageInfo系列和getPackageInfoNoCheck；

简单查看源代码发现，getPackageInfo除了获取包的信息，还检查了包的一些组件；

为了绕过这些验证，我们选择使用getPackageInfoNoCheck获取LoadedApk信息。

5.1 构建插件LoadedApk对象

我们这一步的目的很明确，通过getPackageInfoNoCheck函数创建出我们需要的LoadedApk对象，以供接下来使用。

这个函数的签名如下：

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
            CompatibilityInfo compatInfo) {

因此，为了调用这个函数，我们需要构造两个参数。其一是ApplicationInfo，其二是CompatibilityInfo；

第二个参数顾名思义，代表这个App的兼容性信息，比如targetSDK版本等等，这里我们只需要提取出app的信息，

因此直接使用默认的兼容性即可；在CompatibilityInfo类里面有一个公有字段

DEFAULT_COMPATIBILITY_INFO代表默认兼容性信息；因此，我们的首要目标是获取这个ApplicationInfo信息。

5.2 构建插件ApplicationInfo信息

我们首先看看ApplicationInfo代表什么，这个类的文档说的很清楚：

Information you can retrieve about aparticular application. This corresponds to information collected from theAndroidManifest.xml’s <application> tag.

也就是说，这个类就是AndroidManifest.xml里面的这个标签下面的信息；

这个AndroidManifest.xml无疑是一个标准的xml文件，因此我们完全可以自己使用parse来解析这个信息。

那么，系统是如何获取这个信息的呢？其实Framework就有一个这样的parser，也即PackageParser；

理论上，我们也可以借用系统的parser来解析AndroidMAnifest.xml从而得到ApplicationInfo的信息。

但遗憾的是，这个类的兼容性很差；Google几乎在每一个Android版本都对这个类动刀子，

如果坚持使用系统的解析方式，必须写一系列兼容行代码！！DroidPlugin就选择了这种方式。

我们决定使用PackageParser类来提取ApplicationInfo信息, 看起来有我们需要的方法 generateApplication；

确实如此，依靠这个方法我们可以成功地拿到ApplicationInfo。

由于PackageParser是@hide的，因此我们需要通过反射进行调用。我们根据这个generateApplicationInfo方法的签名：

public static ApplicationInfo generateApplicationInfo(Package p, int flags,
   PackageUserState state)

可以写出调用generateApplicationInfo的反射代码：

Class<?> packageParserClass = Class.forName("android.content.pm.PackageParser");
// 首先拿到我们得终极目标: generateApplicationInfo方法
// API 23 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// public static ApplicationInfo generateApplicationInfo(Package p, int flags,
//    PackageUserState state) {
// 其他Android版本不保证也是如此.
Class<?> packageParser$PackageClass = Class.forName("android.content.pm.PackageParser$Package");
Class<?> packageUserStateClass = Class.forName("android.content.pm.PackageUserState");
Method generateApplicationInfoMethod = packageParserClass.getDeclaredMethod("generateApplicationInfo",
        packageParser$PackageClass,int.class, packageUserStateClass);

要成功调用这个方法，还需要三个参数；因此接下来我们需要一步一步构建调用此函数的参数信息。

5.3 构建PackageParser.Package

generateApplicationInfo方法需要的第一个参数是PackageParser.Package；

从名字上看这个类代表某个apk包的信息，我们看看文档怎么解释：

Representation of a full package parsed fromAPK files on disk. A package consists of a single base APK, and zero or moresplit APKs.

果然，这个类代表从PackageParser中解析得到的某个apk包的信息，是磁盘上apk文件在内存中的数据结构表示；

因此，要获取这个类，肯定需要解析整个apk文件。PackageParser中解析apk的核心方法是parsePackage，

这个方法返回的就是一个Package类型的实例，因此我们调用这个方法即可；使用反射代码如下：

// 首先, 我们得创建出一个Package对象出来供这个方法调用
// 而这个需要得对象可以通过 android.content.pm.PackageParser#parsePackage 这个方法返回得 Package对象得字段获取得到
// 创建出一个PackageParser对象供使用
Object packageParser = packageParserClass.newInstance();
// 调用 PackageParser.parsePackage 解析apk的信息
Method parsePackageMethod = packageParserClass.getDeclaredMethod("parsePackage", File.class, int.class);

// 实际上是一个 android.content.pm.PackageParser.Package 对象
Object packageObj = parsePackageMethod.invoke(packageParser, apkFile, 0);

这样，我们就得到了generateApplicationInfo的第一个参数；第二个参数是解析包使用的flag，我们直接选择解析全部信息，也就是0；

5.4 构建PackageUserState

第三个参数是PackageUserState，代表不同用户中包的信息。由于Android是一个多任务多用户系统，

因此不同的用户同一个包可能有不同的状态；这里我们只需要获取包的信息，因此直接使用默认的即可；

至此，generateApplicaionInfo的参数我们已经全部构造完成，直接调用此方法即可得到我们需要的applicationInfo对象；

在返回之前我们需要做一点小小的修改：使用系统系统的这个方法解析得到的ApplicationInfo对象

中并没有apk文件本身的信息，所以我们把解析的apk文件的路径设置一下（ClassLoa der依赖dex文件以及apk的路径）：

// 第三个参数 mDefaultPackageUserState 我们直接使用默认构造函数构造一个出来即可
Object defaultPackageUserState = packageUserStateClass.newInstance();

// 万事具备!!!!!!!!!!!!!!
ApplicationInfo applicationInfo = (ApplicationInfo) generateApplicationInfoMethod.invoke(packageParser,
        packageObj, 0, defaultPackageUserState);
String apkPath = apkFile.getPath();
applicationInfo.sourceDir = apkPath;
applicationInfo.publicSourceDir = apkPath;

5.5 替换ClassLoader

5.5.1 获取LoadedApk信息

方才为了获取ApplicationInfo我们费了好大一番精力；回顾一下我们的初衷：

我们最终的目的是调用getPackageInfoNoCheck得到LoadedApk的信息，

并替换其中的mClassLoader然后把把添加到ActivityThread的mPackages缓存中；

从而达到我们使用自己的ClassLoader加载插件中的类的目的。

现在我们已经拿到了getPackageInfoNoCheck这个方法中至关重要的第一个参数applicationInfo；

上文提到第二个参数CompatibilityInfo代表设备兼容性信息，直接使用默认的值即可；

因此，两个参数都已经构造出来，我们可以调用getPackageInfoNoCheck获取LoadedApk：

// android.content.res.CompatibilityInfo
Class<?> compatibilityInfoClass = Class.forName("android.content.res.CompatibilityInfo");
Method getPackageInfoNoCheckMethod = activityThreadClass.getDeclaredMethod("getPackageInfoNoCheck", ApplicationInfo.class, compatibilityInfoClass);

Field defaultCompatibilityInfoField = compatibilityInfoClass.getDeclaredField("DEFAULT_COMPATIBILITY_INFO");
defaultCompatibilityInfoField.setAccessible(true);

Object defaultCompatibilityInfo = defaultCompatibilityInfoField.get(null);
ApplicationInfo applicationInfo = generateApplicationInfo(apkFile);

Object loadedApk = getPackageInfoNoCheckMethod.invoke(currentActivityThread, applicationInfo, defaultCompatibilityInfo);

我们成功地构造出了LoadedAPK, 接下来我们需要替换其中的ClassLoader，然后把它添加进ActivityThread的mPackages中：

String odexPath = Utils.getPluginOptDexDir(applicationInfo.packageName).getPath();
String libDir = Utils.getPluginLibDir(applicationInfo.packageName).getPath();
ClassLoader classLoader = new CustomClassLoader(apkFile.getPath(), odexPath, libDir, ClassLoader.getSystemClassLoader());
Field mClassLoaderField = loadedApk.getClass().getDeclaredField("mClassLoader");
mClassLoaderField.setAccessible(true);
mClassLoaderField.set(loadedApk, classLoader);

// 由于是弱引用, 因此我们必须在某个地方存一份, 不然容易被GC; 那么就前功尽弃了.
sLoadedApk.put(applicationInfo.packageName, loadedApk);

WeakReference weakReference = new WeakReference(loadedApk);
mPackages.put(applicationInfo.packageName, weakReference);

我们的这个CustomClassLoader非常简单，直接继承了DexClassLoader，什么都没有做；

当然这里可以直接使用DexClassLoader，这里重新创建一个类是为了更有区分度；

以后也可以通过修改这个类实现对于类加载的控制：

public class CustomClassLoader extends DexClassLoader {

    public CustomClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent) {
        super(dexPath, optimizedDirectory, libraryPath, parent);
    }
}

到这里，我们已经成功地把把插件的信息放入ActivityThread中，这样我们插件中的类能够成功地被加载；

因此插件中的Activity实例能被成功第创建；由于整个流程较为复杂，我们简单梳理一下：

1,在ActivityThread接收到IApplication的scheduleLaunchActivity远程调用之后，将消息转发给H

2,H类在handleMessage的时候，调用了getPackageInfoNoCheck方法来获取待启动的组件信息。

在这个方法中会优先查找mPackages中的缓存信息，而我们已经手动把插件信息添加进去；

因此能够成功命中缓存，获取到独立存在的插件信息。

3,H类然后调用handleLaunchActivity最终转发到performLaunchActivity方法；

这个方法使用从getPackageInfoNoCheck中拿到LoadedApk中的mClassLoader来加载Activity类，

进而使用反射创建Activity实例；接着创建Application，Context等完成Activity组件的启动。

看起来好像已经天衣无缝万事大吉了；但是运行一下会出现一个异常。

错误提示说是无法实例化 Application，而Application的创建也是在performLaunchActivity中进行的，这里有些蹊跷，我们仔细查看一下。

5.5.2 绕过系统检查

通过ActivityThread的performLaunchActivity方法可以得知，Application通过LoadedApk的makeApplication方法创建，

我们查看这个方法，在源码中发现了上文异常抛出的位置：

try {
    java.lang.ClassLoader cl = getClassLoader();
    if (!mPackageName.equals("android")) {
        initializeJavaContextClassLoader();
    }
    ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
    app = mActivityThread.mInstrumentation.newApplication(
            cl, appClass, appContext);
    appContext.setOuterContext(app);
} catch (Exception e) {
    if (!mActivityThread.mInstrumentation.onException(app, e)) {
        throw new RuntimeException(
            "Unable to instantiate application " + appClass
            + ": " + e.toString(), e);
    }
}

木有办法，我们只有一行一行地查看到底是哪里抛出这个异常的了；

所幸代码不多。（所以说，缩小异常范围是一件多么重要的事情！！！）

第一句 getClassLoader() 没什么可疑的，虽然方法很长，但是它木有抛出任何异常

（当然，它调用的代码可能抛出异常，万一找不到只能进一步深搜了；所以我觉得这里应该使用受检异常）。

然后我们看第二句，如果包名不是android开头，那么调用了一个叫做initializeJavaContextClassLoader的方法；我们查阅这个方法：

private void initializeJavaContextClassLoader() {
    IPackageManager pm = ActivityThread.getPackageManager();
    android.content.pm.PackageInfo pi;
    try {
        pi = pm.getPackageInfo(mPackageName, 0, UserHandle.myUserId());
    } catch (RemoteException e) {
        throw new IllegalStateException("Unable to get package info for "
                + mPackageName + "; is system dying?", e);
    }
    if (pi == null) {
        throw new IllegalStateException("Unable to get package info for "
                + mPackageName + "; is package not installed?");
    }

    boolean sharedUserIdSet = (pi.sharedUserId != null);
    boolean processNameNotDefault =
        (pi.applicationInfo != null &&
         !mPackageName.equals(pi.applicationInfo.processName));
    boolean sharable = (sharedUserIdSet || processNameNotDefault);
    ClassLoader contextClassLoader =
        (sharable)
        ? new WarningContextClassLoader()
        : mClassLoader;
    Thread.currentThread().setContextClassLoader(contextClassLoader);
}

这里，我们找出了这个异常的来源：原来这里调用了getPackageInfo方法获取包的信息；

而我们的插件并没有安装在系统上，因此系统肯定认为插件没有安装，这个方法肯定返回null。

所以，我们还要欺骗一下PMS，让系统觉得插件已经安装在系统上了；

至于如何欺骗 PMS，Hook机制之AMS&PMS 有详细解释，这里直接给出代码，不赘述了：

private static void hookPackageManager() throws Exception {

    // 这一步是因为 initializeJavaContextClassLoader 这个方法内部无意中检查了这个包是否在系统安装
    // 如果没有安装, 直接抛出异常, 这里需要临时Hook掉 PMS, 绕过这个检查.

    Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
    Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
    currentActivityThreadMethod.setAccessible(true);
    Object currentActivityThread = currentActivityThreadMethod.invoke(null);

    // 获取ActivityThread里面原始的 sPackageManager
    Field sPackageManagerField = activityThreadClass.getDeclaredField("sPackageManager");
    sPackageManagerField.setAccessible(true);
    Object sPackageManager = sPackageManagerField.get(currentActivityThread);

    // 准备好代理对象, 用来替换原始的对象
    Class<?> iPackageManagerInterface = Class.forName("android.content.pm.IPackageManager");
    Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(),
            new Class<?>[] { iPackageManagerInterface },
            new IPackageManagerHookHandler(sPackageManager));

    // 1. 替换掉ActivityThread里面的 sPackageManager 字段
    sPackageManagerField.set(currentActivityThread, proxy);
}

OK到这里，我们已经能够成功地加载简单的独立的存在于外部文件系统中的apk了。

至此 关于DroidPlugin 对于Activity生命周期的管理已经完全讲解完毕了；

这是一种极其复杂的Activity管理方案，我们仅仅写一个用来理解的demo就Hook了相当多的东西，

在Framework层来回牵扯；这其中的来龙去脉要完全把握清楚还请读者亲自翻阅源码。

上文给出的方案中，我们全盘接管了插件中类的加载过程，这是一种相对暴力的解决方案。

6.小结

本文中我们采用两种方案成功完成了『启动没有在AndroidManifest.xml中显示声明，并且存在于外部插件中的Activity』的任务。

『激进方案』中我们自定义了插件的ClassLoader，并且绕开了Framework的检测；

利用ActivityThread对于LoadedApk的缓存机制，我们把携带这个自定义的ClassLoader的插件信息添加进mPackages中，进而完成了类的加载过程。

『保守方案』中我们深入探究了系统使用ClassLoaderfindClass的过程，

发现应用程序使用的非系统类都是通过同一个PathClassLoader加载的；

而这个类的最终父类BaseDexClassLoader通过DexPathList完成类的查找过程；我们hack了这个查找过程，从而完成了插件类的加载。

这两种方案孰优孰劣呢？

很显然，『激进方案』比较麻烦，从代码量和分析过程就可以看出来，这种机制异常复杂；

而且在解析apk的时候我们使用的PackageParser的兼容性非常差，我们不得不手动处理每一个版本的apk解析api；

另外，它Hook的地方也有点多：不仅需要Hook AMS和H，还需要Hook ActivityThread的mPackages和PackageManager！

『保守方案』则简单得多（虽然原理也不简单），不仅代码很少，而且Hook的地方也不多；

有一点正本清源的意思，从最最上层Hook住了整个类的加载过程。

但是，我们不能简单地说『保守方案』比『激进方案』好。从根本上说，这两种方案的差异在哪呢？

『激进方案』是多ClassLoader构架，每一个插件都有一个自己的ClassLoader，

因此类的隔离性非常好——如果不同的插件使用了同一个库的不同版本，它们相安无事！

『保守方案』是单ClassLoader方案，插件和宿主程序的类全部都通过宿主的ClasLoader加载，

虽然代码简单，但是鲁棒性很差；一旦插件之间甚至插件与宿主之间使用的类库有冲突，那么直接GG。

多ClassLoader还有一个优点：可以真正完成代码的热加载！如果插件需要升级，

直接重新创建一个自定的ClassLoader加载新的插件，然后替换掉原来的版本即可

（Java中，不同ClassLoader加载的同一个类被认为是不同的类）；

单ClassLoader的话实现非常麻烦，有可能需要重启进程。

在J2EE领域中广泛使用ClasLoader的地方均采用多ClassLoader架构，比如Tomcat服务器，

Java模块化事实标准的OSGi技术；所以，我们有足够的理由认为选择多ClassLoader架构在大多数情况下是明智之举。

目前开源的插件方案中，DroidPlugin采用的『激进方案』，Small采用的『保守方案』那么，有没有两种优点兼顾的方案呢？？

答案自然是有的。

DroidPlugin和Small的共同点是两者都是非侵入式的插件框架；

什么是『非侵入式』呢？打个比方，你启动一个插件Activity，直接使用startActivity即可，

就跟开发普通的apk一样，开发插件和普通的程序对于开发者来说没有什么区别。

如果我们一定程度上放弃这种『侵入性』，那么我们就能实现一个两者优点兼而有之的插件框架！

OK，本文的内容就到这里了；关于『插件机制对于Activity的处理方式』也就此完结。

要说明的是，在本文的『保守方案』其实只处理了代码的加载过程，它并不能加载有资源的apk！

所以目前我这个实现基本没什么暖用；当然我这里只是就『代码加载』进行举例.