androidmalin / Androidcomponentplugin
Programming Languages
Projects that are alternatives of or similar to Androidcomponentplugin
Android上简单实现四大组件的插件化
说明:
此项目仅用于学习插件化基本的实现思路,在此基础上学习理解四大组件的运行机制。
实现插件化的重点在于对Android四大组件和资源加载流程的分析和解读。
插件化代码的编写,涉及到的知识点主要有java中的反射,动态代理,静态代理以及android中的AIDL跨进程通信,binder机制,ClassLoader加载机制,四大组件的运行原理等等。
本项目代码主要参考维术插件化系列博客和示例代码。在此基础上做了大量的版本适配(android4.0 ~ android10,android R),以及对代码增加了大量的注释。 维术插件化系列博客和示例代码,写的特别好,值得反复学习和思考,在此特别感谢。
万事开头难,学习的过程是辛苦的,对遇到的知识点采用各个击破的方法,对四大组件流程分析文章进行反复的阅读和理解,日积月累,会有所收获。
示例代码适配情况如下:
版本\组件 | api | Activity | Service | BroadcastReceiver | ContentProvider |
---|---|---|---|---|---|
androidR | R | ✅ | ✅ | ✅ | ✅ |
android29 | 10.0 | ✅ | ✅ | ✅ | ✅ |
android28 | 9.0 | ✅ | ✅ | ✅ | ✅ |
android27 | 8.1 | ✅ | ✅ | ✅ | ✅ |
android26 | 8.0 | ✅ | ✅ | ✅ | ✅ |
android25 | 7.1.1 | ✅ | ✅ | ✅ | ✅ |
android24 | 7.0 | ✅ | ✅ | ✅ | ✅ |
android23 | 6.0 | ✅ | ✅ | ✅ | ✅ |
android22 | 5.1 | ✅ | ✅ | ✅ | ✅ |
android21 | 5.0 | ✅ | ✅ | ✅ | ✅ |
android19 | 4.4 | ✅ | ✅ | ✅ | ✅ |
android18 | 4.3 | ✅ | ✅ | ✅ | ✅ |
android17 | 4.2 | ✅ | ✅ | ✅ | ✅ |
android16 | 4.1 | ✅ | ✅ | ✅ | ✅ |
android15 | 4.0.3 | ✅ | ✅ | ✅ | ✅ |
✅表示测试通过.
本项目特色:
- Activity的插件化,提供了2种方式:Hook IActivityManager和Hook Instrumentation
- 加载插件中的类,提供了2种方式去Hook BaseDexClassLoader
- 示例代码均提供详尽的注释,提供插件化入门的基础知识点
- 提供方便的调试脚本
- 提供了通用的项目gradle配置和混淆配置
要彻底搞清楚代码,需要提前掌握的知识点如下:
问题思考
- 如何确保我们启动的未注册的Activity,有正常的Activity生命周期?
源码探索系列29---插件化基础之启动插件的Activity
-
从整体宏观的角度看,我们到底做了什么?
-
对PackageManager的hook,为什么要hook两个地方
@Override
public PackageManager getPackageManager() {
if (mPackageManager != null) {
return mPackageManager;
}
IPackageManager pm = ActivityThread.getPackageManager();
if (pm != null) {
return (mPackageManager = new ApplicationPackageManager(this, pm));
}
return null;
}
由于系统的执行肯定在我们代码之前,所以系统先生成了一个pm,这个是原生的pm,然后保存在ApplicationPackageManager中, 使得以后使用ContextImp.getPackageManager()都返回这个IPackageManager 对象。 就算我们后来替换了ActivityThread.getPackageManager(),但是也不影响mPackageManager 里面之前包装好的。 所以我们还需要改变mPackageManager 里面的原来的pm对象。
-
Hook AMS和Hook Instrumentation两种方式的区别?
-
为什么偶尔出现pre-verified异常? 这个问题属于dex热修复范畴。首先出现这个问题的充分条件: (1) 一个“独善其身”的A.dex(所有的类引用都在本dex内,没有跨dex调用) (2) 另一个B.dex包含(1)中的某个类XiaoMing (3) 一个类加载器同时加载了(1)跟(2),查找时(2)优先于(1) 当程序试图调用XiaoMing时,在B中发现了,但是回头一看XiaoMing早已被A包养了。遂崩溃。 通常我们并不满足(1)。插件并非独立的,或多或少依赖于宿主包或者公共库,难以“独善其身”,无法被打上CLASS_ISPREVERIFIED标签。 当出现这个问题时,请确认在不同的插件中是否引用了同一个第三方库或者其不同版本。
参考文章列表
- Android:学习AIDL,这一篇文章就够了(上)
- Android:学习AIDL,这一篇文章就够了(下)
- 大白话说Java反射:入门、使用、原理
- Hook机制之动态代理
- Android插件化原理解析——Hook机制之Binder Hook
- Android 插件化原理解析——Activity生命周期管理
- Android 插件化原理解析——插件加载机制
- Android插件化原理解析——广播的管理
- Android 插件化原理解析——Service的插件化
- Android插件化原理解析——ContentProvider的插件化
- Android 插件化原理解析——Hook机制之AMS&PMS
- Android系统篇之----Hook系统的AMS服务实现应用启动的拦截功能
- Android插件化的兼容性(中):Android P的适配
- Android Hook Activity 的几种姿势
License
AndroidComponentPlugin is Apache License 2.0.