GithubStar/DroidPlugin
1
0
Fork 0
mirror of https://github.com/DroidPluginTeam/DroidPlugin.git synced 2026-10-16 20:20:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

统一更新文章内部的链接

Browse Source
This commit is contained in:
tiann
2016-09-02 16:45:31 +08:00
parent 2142c759fb
commit e1a0c48df5
9 changed files with 53 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DOC/tianweishu/Activity生命周期管理.md
+7 -14
View File
@@ -1,11 +1,4 @@
title: "Android 插件化原理解析——Activity生命周期管理"
date: 2016-03-21 19:43:32
tags:
- android
- plugin framework
- droidplugin
---
# Activity生命周期管理
之前的 [Android插件化原理解析][1] 系列文章揭开了Hook机制的神秘面纱，现在我们手握倚天屠龙，那么如何通过这种技术完成插件化方案呢？具体来说，插件中的Activity，Service等组件如何在Android系统上运行起来？
@@ -240,9 +233,9 @@ startActivity(new Intent(MainActivity.this, TargetActivity.class));
由于`AMS`进程会对Activity做显式声明验证，因此在
启动Activity的控制权转移到`AMS`进程之前，我们需要想办法**临时**把TargetActivity替换成替身StubActivity；在这之间有很长的一段调用链，我们可以轻松Hook掉；选择什么地方Hook是一个很自由的事情，但是Hook的步骤越后越可靠——Hook得越早，后面的调用就越复杂，越容易出错。
我们可以选择在进入`AMS`进程的入口进行Hook，具体来说也就是Hook `AMS`在本进程的代理对象ActivityManagerNative。如果你不知道如何Hook掉这个AMS的代理对象，请查阅我之前的文章 [Hook机制之AMS&PMS][5]
我们可以选择在进入`AMS`进程的入口进行Hook，具体来说也就是Hook `AMS`在本进程的代理对象ActivityManagerNative。如果你不知道如何Hook掉这个AMS的代理对象，请查阅我之前的文章 [Hook机制之AMS&PMS][5]
我们Hook掉ActivityManagerNative对于startActivity方法的调用，替换掉交给AMS的intent对象，将里面的TargetActivity的暂时替换成已经声明好的替身StubActivity；这种Hook方式 [前文][5] 讲述的很详细，不赘述；替换的关键代码如下：
我们Hook掉ActivityManagerNative对于startActivity方法的调用，替换掉交给AMS的intent对象，将里面的TargetActivity的暂时替换成已经声明好的替身StubActivity；这种Hook方式 [前文][5] 讲述的很详细，不赘述；替换的关键代码如下：
```java
if ("startActivity".equals(method.getName())) {
@@ -503,9 +496,9 @@ mInstrumentation.callActivityOnDestroy(r.activity);
喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][2]和我的 [博客](http://weishu.me)!
[1]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[1]: 概述.md
[2]: https://github.com/tiann/understand-plugin-framework
[3]: http://weishu.me/2016/01/28/understand-plugin-framework-proxy-hook/
[4]: http://weishu.me/2016/02/16/understand-plugin-framework-binder-hook/
[5]: http://weishu.me/2016/03/07/understand-plugin-framework-ams-pms-hook/
[3]: Hook机制之代理Hook.md
[4]: Hook机制之Binder-Hook.md
[5]: Hook机制之AMS&PMS.md
[6]: http://blog.csdn.net/luoshengyang/article/details/6685853
DOC/tianweishu/BroadcastReceiver插件化.md
+7 -14
View File
@@ -1,11 +1,4 @@
title: "Android插件化原理解析——广播的管理"
date: 2016-04-12 19:08:16
tags:
- android
- plugin framework
- droidplugin
- broadcastreceiver
---
# BroadcastReceiver插件化
在[Activity生命周期管理][1] 以及 [插件加载机制][2] 中我们详细讲述了插件化过程中对于Activity组件的处理方式，为了实现Activity的插件化我们付出了相当多的努力；那么Android系统的其他组件，比如BroadcastReceiver，Service还有ContentProvider，它们又该如何处理呢？
@@ -184,7 +177,7 @@ public void run() {
final IActivityManager mgr = ActivityManagerNative.getDefault();
final Intent intent = mCurIntent;
mCurIntent = null;
if (receiver == null || mForgotten) {
if (mRegistered && ordered) {
sendFinished(mgr);
@@ -209,7 +202,7 @@ public void run() {
+ " in " + mReceiver, e);
}
}
if (receiver.getPendingResult() != null) {
finish();
}
@@ -323,9 +316,9 @@ for (ActivityInfo activityInfo : ReceiverHelper.sCache.keySet()) {
接下来为文章会讲述四大组件中的另外两个——Service和ContentProvider的插件化方案；喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][2] 和我的 [博客](http://weishu.me) ! 如果你觉得能从文中学到皮毛，还请支持一下 :)
[1]: http://weishu.me/2016/03/21/understand-plugin-framework-activity-management/
[2]: http://weishu.me/2016/04/05/understand-plugin-framework-classloader/
[1]: Activity生命周期管理.md
[2]: ClassLoader管理.md
[3]: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.0.1_r1/android/content/IIntentReceiver.java?av=f
[4]: http://weishu.me/2016/03/21/understand-plugin-framework-activity-management/
[4]: Activity生命周期管理.md
[5]: https://github.com/tiann/understand-plugin-framework
[6]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[6]: 概述.md
DOC/tianweishu/ClassLoader管理.md
+8 -17
View File
@@ -1,12 +1,4 @@
title: 'Android 插件化原理解析——插件加载机制'
date: 2016-04-05 20:13:01
tags:
- android
- plugin framework
- droidplugin
- binder
- classloader
---
# 插件加载机制
上文 [Activity生命周期管理][3] 中我们地完成了『启动没有在AndroidManifest.xml中显式声明的Activity』的任务；通过Hook `AMS`和拦截ActivityThread中`H`类对于组件调度我们成功地绕过了AndroidMAnifest.xml的限制。
@@ -188,7 +180,7 @@ public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
我们首先看看ApplicationInfo代表什么，这个类的文档说的很清楚：
> Information you can retrieve about a particular application. This corresponds to information collected from the AndroidManifest.xml's <application> tag.
也就是说，这个类就是AndroidManifest.xml里面的<application> 这个标签下面的信息；这个AndroidManifest.xml无疑是一个标准的xml文件，因此我们完全可以自己使用parse来解析这个信息。
那么，系统是如何获取这个信息的呢？其实Framework就有一个这样的parser，也即PackageParser；理论上，我们也可以借用系统的parser来解析AndroidMAnifest.xml从而得到ApplicationInfo的信息。但遗憾的是，**这个类的兼容性很差**；Google几乎在每一个Android版本都对这个类动刀子，如果坚持使用系统的解析方式，必须写一系列兼容行代码！！DroidPlugin就选择了这种方式，相关类如下：
@@ -208,7 +200,7 @@ OK回到正题，我们决定使用PackageParser类来提取ApplicationInfo信
```java
public static ApplicationInfo generateApplicationInfo(Package p, int flags,
PackageUserState state)
PackageUserState state)
```
可以写出调用generateApplicationInfo的反射代码：
@@ -691,15 +683,14 @@ DroidPlugin和Small的共同点是**两者都是非侵入式的插件框架**；
OK，本文的内容就到这里了；关于『插件机制对于Activity的处理方式』也就此完结。要说明的是，在本文的『保守方案』其实只处理了代码的加载过程，它并不能加载有资源的apk！所以目前我这个实现基本没什么暖用；当然我这里只是就『代码加载』进行举例；至于资源，那牵扯到另外一个问题——**插件系统的资源管理机制**这个在后续文章的合适机会我会单独讲解。
接下来的文章，会讲述Android四大组件的另外三个`Service`，`BroadCastReceiver`, `ContentProvider`的处理方式。喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][2]和我的 [博客](http://weishu.me)! 这文章我前前后后准备了快两个星期，如果你看到了这里，还请支持一下 :)
接下来的文章，会讲述Android四大组件的另外三个`Service`，`BroadCastReceiver`, `ContentProvider`的处理方式。喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][2]和我的 [博客](http://weishu.me)! 这文章我前前后后准备了快两个星期，如果你看到了这里，还请支持一下 :)
[1]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[1]: 概述.md
[2]: https://github.com/tiann/understand-plugin-framework
[3]: http://weishu.me/2016/03/21/understand-plugin-framework-activity-management/
[4]: http://weishu.me/2016/03/07/understand-plugin-framework-ams-pms-hook/
[3]: Activity生命周期管理.md
[4]: Hook机制之AMS&PMS.md
[5]: http://androidxref.com/6.0.1_r10/xref/libcore/dalvik/src/main/java/dalvik/system/PathClassLoader.java
[6]: http://androidxref.com/6.0.1_r10/xref/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
[7]: http://weishu.me/2016/02/16/understand-plugin-framework-binder-hook/
[7]: Hook机制之Binder-Hook.md
DOC/tianweishu/ContentProvider插件化.md
+4 -11
View File
@@ -1,11 +1,4 @@
title: "Android插件化原理解析——ContentProvider的插件化"
date: 2016-07-12 19:18:07
tags:
- android
- plugin framework
- droidplugin
- ContentProvider
---
# ContentProvider插件化
目前为止我们已经完成了Android四大组件中Activity，Service以及BroadcastReceiver的插件化，这几个组件各不相同，我们根据它们的特点定制了不同的插件化方案；那么对于ContentProvider，它又有什么特点？应该如何实现它的插件化？
@@ -299,7 +292,7 @@ synchronized (cpr) {
}
```
你没看错，一个死循环就是糊在上面：AMS进程会通过一个死循环等到进程B完成ContentProvider的安装，等待完成之后会把ContentProvider的信息返回给进程A。那么，我们现在的疑惑是，**进程B在启动之后，在哪个时间点会完成ContentProvider的安装呢？**
你没看错，一个死循环就是糊在上面：AMS进程会通过一个死循环等到进程B完成ContentProvider的安装，等待完成之后会把ContentProvider的信息返回给进程A。那么，我们现在的疑惑是，**进程B在启动之后，在哪个时间点会完成ContentProvider的安装呢？**
我们接着看ActivityThread的main函数，顺便寻找我们上面那个问题的答案；这个分析实际上就是Android App的启动过程，更详细的过程可以参阅老罗的文章 [Android应用程序启动过程源代码分析][4]，这里只给出简要调用流程：
@@ -579,7 +572,7 @@ private Uri getRealUri(Uri raw) {
喜欢就点个赞吧，兜里有一块钱的童鞋可以点击下面的打赏然后扫一下二维码哦～持续更新，请关注github项目 [understand-plugin-framework][1] 和我的 [博客][3]! 另外很抱歉一个多月没有更新博客了，每天看到各位的来访记录深感惭愧，实在是业务繁忙，身不由已！不出意外接下来会以正常速度更新内容，谢谢支持 ^_^
[1]: https://github.com/tiann/understand-plugin-framework
[2]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[2]: 概述.md
[3]: http://weishu.me
[4]: http://blog.csdn.net/luoshengyang/article/details/6689748
[5]: http://blog.csdn.net/luoshengyang/article/details/6967204
[5]: http://blog.csdn.net/luoshengyang/article/details/6967204
DOC/tianweishu/Hook机制之AMS & PMS.md → DOC/tianweishu/Hook机制之AMS&PMS.md
+5 -11
View File
@@ -1,10 +1,4 @@
title: 'Android 插件化原理解析——Hook机制之AMS&PMS'
date: 2016-03-07 16:35:46
tags:
- android
- plugin framework
- droidplugin
---
# Hook机制之AMS&PMS
在前面的文章中我们介绍了DroidPlugin的Hook机制，也就是**代理方式**和**Binder Hook**；插件框架通过AOP实现了插件使用和开发的透明性。在讲述DroidPlugin如何实现四大组件的插件化之前，有必要说明一下它对ActivityManagerServiche以及PackageManagerService的Hook方式（以下简称AMS，PMS）。
@@ -174,7 +168,7 @@ D/HookHelper﹕ method:startActivity called with args:[android.app.ActivityThrea
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityPaused called with args:[android.os.BinderProxy@9bc71b2]
```
可以看到，简单的几行代码，`AMS`已经被我们完全劫持了!! 至于劫持了能干什么，自己发挥想象吧~
可以看到，简单的几行代码，`AMS`已经被我们完全劫持了!! 至于劫持了能干什么，自己发挥想象吧~
DroidPlugin关于`AMS`的Hook，可以查看`IActivityManagerHook`这个类，它处理了我上述所说的兼容性问题，其他原理相同。另外，也许有童鞋有疑问了，你用`startActivity`为例怎么能确保Hook掉这个静态变量之后就能保证所有使用`AMS`的入口都被Hook了呢？
@@ -279,10 +273,10 @@ OK，我们又成功劫持了`PackageManager`！！DroidPlugin 处理PMS的代
喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][2]和我的 [博客](http://weishu.me)!
[1]: http://weishu.me/2016/02/16/understand-plugin-framework-binder-hook/
[1]: Hook机制之Binder-Hook.md
[2]: https://github.com/tiann/understand-plugin-framework
[3]: http://blog.csdn.net/luoshengyang/article/details/6689748
[4]: http://weishu.me/2016/01/12/binder-index-for-newer/
[5]: http://grepcode.com/file_/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/app/ActivityManagerNative.java/?v=diff&id2=2.3.3_r1
[6]: http://weishu.me/2016/01/28/understand-plugin-framework-proxy-hook/
[7]: https://segmentfault.com/a/1190000004077469
[6]: Hook机制之代理Hook.md
[7]: https://segmentfault.com/a/1190000004077469
DOC/tianweishu/Hook机制之Binder Hook.md → DOC/tianweishu/Hook机制之Binder-Hook.md
+4 -11
View File
@@ -1,11 +1,4 @@
title: "Android插件化原理解析——Hook机制之Binder Hook"
date: 2016-02-16 19:22:45
tags:
- android
- plugin framework
- droidplugin
- binder
---
# Hook机制之Binder-Hook
Android系统通过Binder机制给应用程序提供了一系列的系统服务，诸如`ActivityManagerService`，`ClipboardManager`， `AudioManager`等；这些广泛存在系统服务给应用程序提供了诸如任务管理，音频，视频等异常强大的功能。
@@ -84,7 +77,7 @@ IXXInterface in = IXXInterface.Stub.asInterface(b); // 转换为Service接口
```java
public static android.content.IClipboard asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); // Hook点
if (((iin != null) && (iin instanceof android.content.IClipboard))) {
@@ -292,7 +285,7 @@ cache.put(CLIPBOARD_SERVICE, hookedBinder);
喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][3] 和我的 [博客][5]!
[1]: http://weishu.me/2016/01/12/binder-index-for-newer/
[2]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[2]: 概述.md
[3]: https://github.com/tiann/understand-plugin-framework
[4]: http://weishu.me/2016/01/28/understand-plugin-framework-proxy-hook/
[4]: Hook机制之代理Hook.md
[5]: http://weishu.me/
DOC/tianweishu/Hook机制之代理Hook.md
+4 -10
View File
@@ -1,10 +1,4 @@
title: "Android插件化原理解析——Hook机制之动态代理"
date: 2016-01-28 20:27:13
tags:
- android
- plugin framework
- droidplugin
---
# Hook机制之动态代理
使用代理机制进行API Hook进而达到方法增强是框架的常用手段，比如J2EE框架Spring通过动态代理优雅地实现了AOP编程，极大地提升了Web开发效率；同样，插件框架也广泛使用了代理机制来增强系统API从而达到插件化的目的。本文将带你了解基于动态代理的Hook机制。
@@ -156,10 +150,10 @@ public class EvilInstrumentation extends Instrumentation {
try {
Method execStartActivity = Instrumentation.class.getDeclaredMethod(
"execStartActivity",
Context.class, IBinder.class, IBinder.class, Activity.class,
Context.class, IBinder.class, IBinder.class, Activity.class,
Intent.class, int.class, Bundle.class);
execStartActivity.setAccessible(true);
return (ActivityResult) execStartActivity.invoke(mBase, who,
return (ActivityResult) execStartActivity.invoke(mBase, who,
contextThread, token, target, intent, requestCode, options);
} catch (Exception e) {
// 某该死的rom修改了 需要手动适配
@@ -206,4 +200,4 @@ public static void attachContext() throws Exception{
喜欢就点个赞吧～持续更新，请关注github项目 [understand-plugin-framework][1]和我的 [博客](http://weishu.me)!
[1]: https://github.com/tiann/understand-plugin-framework
[1]: https://github.com/tiann/understand-plugin-framework
DOC/tianweishu/Service插件化.md
+11 -19
View File
@@ -1,11 +1,4 @@
title: "Android 插件化原理解析——Service的插件化"
date: 2016-05-11 21:02:50
tags:
- android
- plugin framework
- droidplugin
- service
---
# Service插件化
在 [Activity生命周期管理][1] 以及 [广播的管理][2] 中我们详细探讨了Android系统中的Activity、BroadcastReceiver组件的工作原理以及它们的插件化方案，相信读者已经对Android Framework和插件化技术有了一定的了解；本文将探讨Android四大组件之一——Service组件的插件化方式。
@@ -135,7 +128,7 @@ int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
```java
private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting) throws TransactionTooLargeException {
// 略。。
final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
@@ -186,7 +179,7 @@ private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, bool
```java
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
// 略。。
boolean created = false;
@@ -275,7 +268,7 @@ OK，现在ActivityThread里面的`handleCreateService`方法成功创建出了S
```java
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
// 略。。
boolean created = false;
@@ -529,7 +522,7 @@ if ("startService".equals(method.getName())) {
newIntent.setComponent(componentName);
// 把我们原始要启动的TargetService先存起来
newIntent.putExtra(AMSHookHelper.EXTRA_TARGET_INTENT, integerIntentPair.second);
// 替换掉Intent, 达到欺骗AMS的目的
args[integerIntentPair.first] = newIntent;
Log.v(TAG, "hook method startService success");
@@ -739,16 +732,15 @@ public void onStart(Intent proxyIntent, int startId) {
Service，Activity等不过就是一些普通的Java类，它们之所称为四大组件，是因为他们有生命周期；这也是简单地采用Java的动态加载技术无法实现插件化的原因——动态加载进来的Service等类如果没有它的生命周期，无异于一个没有灵魂的傀儡。对于Activity组件，由于他的生命周期受用户交互影响，只有系统本身才能对这种交互有全局掌控力，因此它的插件化方式是Hook AMS，但是生命周期依然交由系统管理；而Service以及BroadcastReceiver的生命周期没有额外的因素影响，因此我们选择了手动控制其生命周期的方式。不论是借尸还魂还是女娲造人，对这些组件的插件化终归结底是要赋予组件“生命”。
插件化系列的文章有整整一个月没有更新了，非常抱歉！这段时间发生了很多事情，我实在抽不出时间照顾博客；而写这种文章又需要足够的时间准备，要跟踪源码分析过程，要找联系DroidPlugin作者确认设计思路，还要亲自写demo验证。
喜欢就点个赞吧，兜里有一块钱的童鞋可以点击下面的打赏然后扫一下二维码哦～持续更新，请关注github项目 [understand-plugin-framework][3] 和我的 [博客][9]!
喜欢就点个赞吧，兜里有一块钱的童鞋可以点击下面的打赏然后扫一下二维码哦～持续更新，请关注github项目 [understand-plugin-framework][3] 和我的 [博客][9]!
[1]: http://weishu.me/2016/03/21/understand-plugin-framework-activity-management/
[2]: http://weishu.me/2016/04/12/understand-plugin-framework-receiver/
[1]: Activity生命周期管理.md
[2]: BroadcastReceiver插件化.md
[3]: https://github.com/tiann/understand-plugin-framework
[4]: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
[4]: 概述.md
[5]: http://developer.android.com/intl/zh-cn/guide/components/services.html
[6]: http://weishu.me/2016/03/07/understand-plugin-framework-ams-pms-hook/
[7]: http://weishu.me/2016/04/05/understand-plugin-framework-classloader/
[6]: Hook机制之AMS&PMS.md
[7]: ClassLoader管理.md
[8]: https://github.com/singwhatiwanna/dynamic-load-apk
[9]: http://weishu.me
DOC/tianweishu/概述.md
+3 -3
View File
@@ -1,4 +1,4 @@
# Android插件化原理解析——概要
# 概要
2015年是Android插件化技术突飞猛进的一年，随着业务的发展各大厂商都碰到了Android Native平台的瓶颈：
@@ -44,8 +44,8 @@ H5和Hybird可以解决这些问题，但是始终比不上native的用户体验
另外，对于每一章内容都会有详细的demo，具体见[understand-plugin-framework](https://github.com/tiann/understand-plugin-framework)；喜欢就点个关注吧～定期更新，敬请期待！
[1]: Hook机制之代理Hook.md
[2]: 'Hook机制之Binder Hook.md'
[3]: 'Hook机制之AMS & PMS.md'
[2]: Hook机制之Binder-Hook.md
[3]: Hook机制之AMS&PMS.md
[4]: Activity生命周期管理.md
[5]: ClassLoader管理.md
[6]: BroadcastReceiver插件化.md