Android插件化实践(2)

作者: 小吵闹123 | 来源:发表于2017-08-26 16:22 被阅读272次

    悟已往之不谏,知来者之可追

    背景

    在上一篇文章如何启动一个没有在AndroidManifest中注册的activity中简单介绍了如何绕开ActivityManagerSerivce(AMS)的校验启动一个没有在AndroidManifest.xml中声明的activity。然而启动这么一个写在应用内部的activity是没有多大意义的,想实现动态下发新的activity,就一定要想办法从外部获取activity并启动它。

    ClassLoader简单介绍

    了解Java的同学一定都知道,Java通过是ClassLoader去加载类的,首先看一下CLassLoader初始化的时候做了什么。初始化的时候会createSystemClassLoader()生成一个ClassLoader。

    static private class SystemClassLoader {
        public static ClassLoader loader = ClassLoader.createSystemClassLoader();
    }
    

    在createSystemClassLoader()方法中返回了一个PathClassLoader()的实例,从构造方法里可以看到PathClassLoader对象传入的parent是BootClassLoader的实例。

    private static ClassLoader createSystemClassLoader() {
        String classPath = System.getProperty("java.class.path", ".");
        String librarySearchPath = System.getProperty("java.library.path", "");
        return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
    }
    

    pathClassLoader的实现很简单,继承BaseDexClassLoader,代码如下

    public class PathClassLoader extends BaseDexClassLoader {
        public PathClassLoader(String dexPath, ClassLoader parent) {
            super(dexPath, null, null, parent);
        }
        
        public PathClassLoader(String dexPath, String libraryPath,
                ClassLoader parent) {
            super(dexPath, null, libraryPath, parent);
        }
    }
    

    这里的PathClassLoader就是用来加载安装后的apk文件的。在android中还有另一类ClassLoader——DexClassLoader,它主要用来加载外部apk或者jar文件的。DexClassLoader实现很简单,代码如下。

    public class DexClassLoader extends BaseDexClassLoader {
      
        public DexClassLoader(String dexPath, String optimizedDirectory,
                String libraryPath, ClassLoader parent) {
            super(dexPath, new File(optimizedDirectory), libraryPath, parent);
        }
    }
    

    可以看到PathClassLoader和DexClassLoader都继承BaseDexClassLoader,BaseDexClassLoader主要代码如下。

    public class BaseDexClassLoader extends ClassLoader {
        
        ...
        
        public BaseDexClassLoader(String dexPath, File optimizedDirectory,
                String libraryPath, ClassLoader parent) {
            super(parent);
            this.originalPath = dexPath;
            this.pathList =
                new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
        }
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            Class clazz = pathList.findClass(name);
            if (clazz == null) {
                throw new ClassNotFoundException(name);
            }
            return clazz;
        }
        
        ...
    }
    

    在构造方法中会将dex的ClassLoader、路径等存到DexPathList中。findClass时先从pathList查找类。
    了解了这几个ClassLoader之后,我们再来看看ClassLoader是如何工作的。loadClass方法代码如下

    protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
        Class<?> clazz = findLoadedClass(className);
        if (clazz == null) {
            try {
                clazz = parent.loadClass(className, false);
            } catch (ClassNotFoundException e) {
                
            }
            if (clazz == null) {
                clazz = findClass(className);
            }
        }
        return clazz;
    }
    

    从代码中可以看到loadClass会先从BootClassLoader中查找,如果没有找到再从parent的ClassLoader中查找,如果还没有再从当前的ClassLoader中查找。过程如下图所示

    我们再来看一下上面几个ClassLoader的依赖关系,从代码中可以看到PathClassLoader的parent是BootClassLoader,下面通过一段代码来验证一下。

    ClassLoader classLoader = getClassLoader();
            Log.d(TAG, "ClassLoader: " + (classLoader == null ? " null" : classLoader.toString()));
    
    ClassLoader parentClassLoader = classLoader.getParent();
    Log.d(TAG, "parentClassLoader: " +  (parentClassLoader == null ? "null" : parentClassLoader.toString()));
    
    ClassLoader pParentClassLoader = parentClassLoader.getParent();
    Log.d(TAG, "parent's parentClassLoader: " +  (pParentClassLoader == null ? "null" : pParentClassLoader.toString()));
        
    

    运行这段代码之后结果如下

    ClassLoader: dalvik.system.PathClassLoader
    
    parentClassLoader: java.lang.BootClassLoader@de975c2
    
    parent's parentClassLoader: null
    

    当前的classLoader是PathClassLoader,parent的ClassLoader是BootClassLoader,而BootClassLoader没有parent的ClassLoader,和验证了之前代码的结论。这就是Java中的父委托机制,Java在查找类的时候会先从parent的ClassLoader查找,是从上到下的过程。比如我们写了一个类java.lang.String,这个类和Java中的String包名类名都一样,虚拟机在调用String对象的时候并不会调用我们自定义的类,而是会优先使用Java中的String,有兴趣的同学可以自己写段代码试验一下。

    那么问题来了,上面说到要加载外部apk的类需要DexClassLoader,而从上面的结果可以看出app运行的过程中跟DexClassLoader并没有什么联系,父委托机制也和DexClassLoader没有关联,那么如何去加载外部apk的类呢?接着往下看。

    如何加载外部apk的类

    上面提到父委托机制,再联想一下ClassLoader的构造方法中有一个参数是parent,那么是不是有办法把PathClassLoader的parent替换成我们想要的DexClassLoader,在把DexClassLoader的parent设置成BootClassLoader,再加上父委托的机制,查找类的过程就变成BootClassLoader->DexClassLoader->PathClassLoader,这样是不是就可以加载外部apk的类了呢?下面我们来试验一下

    public static void loadApk(Context context, String apkPath) {
        File dexFile = context.getDir("dex", Context.MODE_PRIVATE);
    
        File apkFile = new File(apkPath);
    
        ClassLoader classLoader = context.getClassLoader();
        DexClassLoader dexClassLoader = new DexClassLoader(apkFile.getAbsolutePath(),
                dexFile.getAbsolutePath(), null, classLoader.getParent());
    
        try {
            Field fieldClassLoader = ClassLoader.class.getDeclaredField("parent");
            if (fieldClassLoader != null) {
                fieldClassLoader.setAccessible(true);
                fieldClassLoader.set(classLoader, dexClassLoader);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    

    首先获取当前的ClassLoader,然后新建一个DexClassLoader,把ClassLoader的parent设置为DexClassLoader的parent,这个parent就是BootClassLoader,这样就完成了第一步,将DexClassLoader的parent设置成BootCLassLoader。第二部,通过反射取出当前ClassLoader中的parent,当前的ClassLoader就是PathClassLoader,取出parent之后将上一步新建的DexClassLoader设置为parent,这样就可以轻松的在类加载的时候插入DexCLassLoader查找类的过程,下面通过一段代码试验一下。我们自定义一个Application,在比较早的时机加载一个外部apk,这个apk中只有一个activity,用来实验。

    public class HookApplication extends Application {
    
        @Override
        protected void attachBaseContext(Context base) {
            super.attachBaseContext(base);
            LoadApkUtils.loadApk(base, Environment.getExternalStorageDirectory().getPath()
                    + File.separator + "lib.apk");
            HookUtils.hookActivityManagerService(getClassLoader());
            HookUtils.hookActivityThreadHandler();
        }
    }
    

    再次启动应用,结果如下

    ClassLoader: dalvik.system.PathClassLoader
    
    parentClassLoader: dalvik.system.DexClassLoader
    
    parent's parentClassLoader: java.lang.BootClassLoader@4546fd3
    

    从这里可以看到,已经成功的将DexClassLoader插到了PathCLassLoader和BootClassLoader之间。再通过上一篇文章中介绍的启动没有在AndroidManifest.xml注册的activity的方法,就可以加载一个外部apk的activity。

    小结

    通过以上方法,就可以从外部apk动态加载一个activity了,可以为应用动态的下发apk,实现新功能。但是目前为止外部的activity中不能包含资源,因为资源文件在编译的时候会生成一个id,而加载外部的activity是找不到id的。在后面会的文章会一步一步介绍如何通过hook AssetManager获取外部资源,实现完整的activity的加载。

    小结之后

    上面的代码在android 8.0上运行之后,在hook ActivityManagerNative的时候找不到gDefault的单例了,不了解gDefault可以看一看前一篇文章,通过查看源码发现,ActivityManagerNative不在承载相关单例,而是将IActivityManager的单例放在了ActivityManager中,这样hook点也要发生相应的变化,这就暴露了动态代理hook方法的一个缺点,需要为各个版本去适配。上面的代码只在android5.1和6.0上测试通过。附上android8.0相关改动源码地址

    相关文章

      网友评论

      本文标题:Android插件化实践(2)

      本文链接:https://www.haomeiwen.com/subject/thxvdxtx.html