首先声明,《Android插件化开发指南》这本书所介绍的Android底层是基于Android6.0(API level 23)的,而本书介绍的各种插件化解决方案,以及配套的70多个例子,在Android7.0(API level 24)手机上测试都是能正常工作的。

如果读者您的手机是Android 26、27,甚至28(也就是Android P),那么会有30个插件化的例子不能正常工作,这是因为Android系统底层的源码改动导致的。

本篇文章,专门介绍Android O的改动对插件化产生的影响,以及相应的插件化解决方案。

(一)从ActivityManagerNative的重构谈起

首先是ActivityManagerNative这个类的gDefault字段,这个字段在API 25以及之前的版本,定义如下:

public abstract class ActivityManagerNative extends Binder implements IActivityManager {
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
}

所以,我们可以通过反射获取ActivityManagerNative的gDefault字段,执行它的create方法,得到IActivityManager接口类型的对象。

看到这个接口类型,我们眼前一亮,可以通过Proxy.newProxyInstance方法,hook掉这个IActivityManager对象,拦截它的startActivity方法,把要启动的、没有在Manifest中声明的Activity,替换成占坑StubActivity,代码如下所示:

    public static void hookAMN() throws ClassNotFoundException,
NoSuchMethodException, InvocationTargetException,
IllegalAccessException, NoSuchFieldException { //获取AMN的gDefault单例gDefault,gDefault是final静态的
Object gDefault = RefInvoke.getStaticFieldObject("android.app.ActivityManagerNative", "gDefault");
// gDefault是一个 android.util.Singleton<T>对象; 我们取出这个单例里面的mInstance字段
Object mInstance = RefInvoke.getFieldObject("android.util.Singleton", gDefault, "mInstance"); // 创建一个这个对象的代理对象MockClass1, 然后替换这个字段, 让我们的代理对象帮忙干活
Class<?> classB2Interface = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(
Thread.currentThread().getContextClassLoader(),
new Class<?>[] { classB2Interface },
new MockClass1(mInstance)); //把gDefault的mInstance字段,修改为proxy
Class class1 = gDefault.getClass();
RefInvoke.setFieldObject("android.util.Singleton", gDefault, "mInstance", proxy);
}

我们在书中的第5章详细讲解过上述这些代码。但不幸的是,这些代码在Android O(API level 26)以上的系统版本中就不能运行了,在运行到这句话的时候,gDefault的值为空:

Object gDefault = RefInvoke.getStaticFieldObject("android.app.ActivityManagerNative", "gDefault");

这是因为Google在Android O中,把ActivityManagerNative中的这个gDefault字段删除了,转移到了ActivityManager类中,但此时,这个字段改名为IActivityManagerSingleton,所以在Android P中,要把这句话改为:

Object gDefault = RefInvoke.getStaticFieldObject("android.app.ActivityManager", "IActivityManagerSingleton");

但这又不兼容于Android O以下的版本了,所以写一个if-else条件语句,根据Android系统的版本,来做不同的处理,如下所示:

        Object gDefault = null;
if (android.os.Build.VERSION.SDK_INT <= 25) {
//获取AMN的gDefault单例gDefault,gDefault是静态的
gDefault = RefInvoke.getStaticFieldObject("android.app.ActivityManagerNative", "gDefault");
} else {
//获取ActivityManager的单例IActivityManagerSingleton,他其实就是之前的gDefault
gDefault = RefInvoke.getStaticFieldObject("android.app.ActivityManager", "IActivityManagerSingleton");
}

(二)Element和DexFile的兴衰史

接下来我们把目光转移到插件类的加载。我们在书中介绍了3种加载方式:

1. 为每一个插件创建一个ClassLoader,用插件ClassLoader去加载插件中的类。

2. 把所有插件中的dex,都合并到宿主App的dex数组中。

3. 把宿主App所使用的ClassLoader,替换成我们自己创建的ClassLoader,在这个新的ClassLoader中,有一个容器变量,承载所有插件的ClassLoader,用来加载插件中的类。

这其中,第2种方式的实现是最简单的,也就是合并所有插件的dex到一个数组中,具体代码实现如下所示:

public final class BaseDexClassLoaderHookHelper {

    public static void patchClassLoader(ClassLoader cl, File apkFile, File optDexFile)
throws IllegalAccessException, NoSuchMethodException, IOException, InvocationTargetException, InstantiationException, NoSuchFieldException {
// 获取 BaseDexClassLoader : pathList
Object pathListObj = RefInvoke.getFieldObject(DexClassLoader.class.getSuperclass(), cl, "pathList"); // 获取 PathList: Element[] dexElements
Object[] dexElements = (Object[]) RefInvoke.getFieldObject(pathListObj, "dexElements"); // Element 类型
Class<?> elementClass = dexElements.getClass().getComponentType(); // 创建一个数组, 用来替换原始的数组
Object[] newElements = (Object[]) Array.newInstance(elementClass, dexElements.length + 1); // 构造插件Element(File file, boolean isDirectory, File zip, DexFile dexFile) 这个构造函数
Class[] p1 = {File.class, boolean.class, File.class, DexFile.class};
Object[] v1 = {apkFile, false, apkFile, DexFile.loadDex(apkFile.getCanonicalPath(), optDexFile.getAbsolutePath(), 0)};
Object o = RefInvoke.createObject(elementClass, p1, v1); Object[] toAddElementArray = new Object[] { o };
// 把原始的elements复制进去
System.arraycopy(dexElements, 0, newElements, 0, dexElements.length);
// 插件的那个element复制进去
System.arraycopy(toAddElementArray, 0, newElements, dexElements.length, toAddElementArray.length); // 替换
RefInvoke.setFieldObject(pathListObj, "dexElements", newElements);
}
}

这个思路没问题。注意其中的这么几句话:

Class[] p1 = {File.class, boolean.class, File.class, DexFile.class};
Object[] v1 = {apkFile, false, apkFile, DexFile.loadDex(apkFile.getCanonicalPath(), optDexFile.getAbsolutePath(), 0)};
Object o = RefInvoke.createObject(elementClass, p1, v1);
Object[] toAddElementArray = new Object[] { o };

这几句话中,通过反射执行了Element的带有4个参数的构造函数,但不幸的是,在Android O以及之后的版本,这个带有4个参数的构造函数就被废弃了。

此外,在这个构造函数中使用到的DexFile这个类,也被废弃了,对此Google给出的解释是,只有Android系统可以使用DexFile,App层面不能使用它。

于是,我们不得不另辟蹊径,通过执行DexPathList类的makeDexElements方法,来生成插件中的dex:

List<File> legalFiles = new ArrayList<>();
legalFiles.add(apkFile); List<IOException> suppressedExceptions = new ArrayList<IOException>(); Class[] p1 = {List.class, File.class, List.class, ClassLoader.class};
Object[] v1 = {legalFiles, optDexFile, suppressedExceptions, cl};
Object[] toAddElementArray = (Object[])
RefInvoke.invokeStaticMethod("dalvik.system.DexPathList", "makeDexElements", p1, v1);

这段代码,在Android O之前的版本也是适用的。所以,我们找到了比DexFile更好用的makeDexElements方法,进行Hook。

Android插件化的兼容性(上):Android O的适配的更多相关文章

  1. Android插件化的兼容性(中):Android P的适配

    Android系统的每次版本升级,都会对原有代码进行重构,这就为插件化带来了麻烦. Android P对插件化的影响,主要体现在两方面,一是它重构了H类中Activity相关的逻辑,另一个是它重构了I ...

  2. Android插件化的兼容性(下):突破Android P中灰黑名单的限制

    在Android P系统中,加入了访问私有API接口的限制.

  3. 《Android插件化开发指南》勘误

    一些常识: 1)全书70个代码例子中,涉及到插件的例子,请先assemble插件的项目,这会在HostApp项目中生成assets目录,并在该目录下plugin1.apk.这样,HostApp才能正常 ...

  4. 自己动手写Android插件化框架,让老板对你刮目相看

    欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由达文西发表于云+社区专栏 最近在工作中接触到了Android插件内的开发,发现自己这种技术还缺乏最基本的了解,以至于在一些基本问题上浪 ...

  5. 自己动手写Android插件化框架

    自己动手写Android插件化框架 转 http://www.imooc.com/article/details/id/252238   最近在工作中接触到了Android插件内的开发,发现自己这种技 ...

  6. Android插件化(三)载入插件apk中的Resource资源

    Android载入插件apk中的Resource资源 简单介绍 怎样载入未安装apk中的资源文件呢?我们从android.content.res.AssetManager.java的源代码中发现,它有 ...

  7. 有关Android插件化思考

    最近几年移动开发业界兴起了「 插件化技术 」的旋风,各个大厂都推出了自己的插件化框架,各种开源框架都评价自身功能优越性,令人目不暇接.随着公司业务快速发展,项目增多,开发资源却有限,如何能在有限资源内 ...

  8. Android 插件化和热修复知识梳理

    概述 在Android开发中,插件化和热修复的话题越来越多的被大家提及,同时随着技术的迭代,各种框架的发展更新,插件化和热修复的框架似乎已经日趋成熟,许多开发者也把这两项技术运用到实际开发协作和正式的 ...

  9. Android插件化技术——原理篇

    <Android插件化技术——原理篇>     转载:https://mp.weixin.qq.com/s/Uwr6Rimc7Gpnq4wMFZSAag?utm_source=androi ...

随机推荐

  1. Python学习笔记5程序的控制结构

    1.分支结构 (1)单分支结构 (2)二分支结构 (3)多分支结构 条件判断 (4)程序的异常处理 2.实例:身体质量指数BMI 思路一(国内,稍作修改就是国际): 思路二: height,weigh ...

  2. (4)Linux常用基本操作

    1.ping和traceroute 指定源IP ping:ping -I 源 目的    #I为大写的i 带源地址路由tracert:traceroute -d <目标地址> -s < ...

  3. 阿里巴巴开源 Spring Cloud Alibaba,加码微服务生态建设

    本周,Spring Cloud联合创始人Spencer Gibb在Spring官网的博客页面宣布:阿里巴巴开源 Spring Cloud Alibaba,并发布了首个预览版本.随后,Spring Cl ...

  4. 1-蓝桥杯套路-java

    决定参加蓝桥杯用java了,当然得重新刷点题目,熟悉一下,以后要是考研失败了,可能回去找java的工作!!! 经验贴: 1. https://blog.csdn.net/wqy20140101/art ...

  5. python requests库爬取网页小实例:爬取网页图片

    爬取网页图片: #网络图片爬取 import requests import os root="C://Users//Lenovo//Desktop//" #以原文件名作为保存的文 ...

  6. VSCode的使用

    前后端分离的,先打开vs,打开你的项目,在项目根目录中找到.vs文件加,找到.vs\config\applicationhost.config,然后打开找到你项目的IIS Express配置,例如:& ...

  7. Vue element 分页

    Vue单页面,有一个带分页的表格,表格内数据关联页码,套路如下: 代码如下: <div class="c-table-list auth-list m-bottom-20"& ...

  8. jQuery基础方法:each(),map(),index(),is()

    jQuery的each()方法和forEach()的区别: each()返回调用自身的jQuery对象,可用于链式调用 $('div').each(function(idx){ //找到所有div元素 ...

  9. 部落划分Group[JSOI2010]

    --BZOJ1821 Description 聪聪研究发现,荒岛野人总是过着群居的生活,但是,并不是整个荒岛上的所有野人都属于同一个部落,野人们总是拉帮结派形成属于自己的部落,不同的部落之间则经常发生 ...

  10. 设计模式学习心得<外观模式 Facade>

    外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口.这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性. 这种模式涉及 ...