插件开发之360 DroidPlugin源码分析(三)Binder代理
2016-10-11 15:02
459 查看
Hook机制中Binder代理类关系图
Hook机制中Binder代理时序图
MyServiceManager
ServiceManagerCacheBinderHook
ServiceManagerBinderHook
BinderHook
mOriginServiceCache:这里存储的是原始的service cache。每个ActivityThread在bindApplication()的时候,会从ServiceManager那边获得一个service cache(可以减少和Binder代理之间通信,系统Binder是一个专门的BinderProxy和把上层的service和Binder driver进行IPC),每次要和某个service通信时,会先检查这个cache里有没有代理对象,如果有的话就直接用,不需要再和ServiceManager进行一次binder交互了。
mProxiedServiceCache:这里存储的就是service cache的代理对象了,因为我们要hook这些binder和上层(serviceConnection时会转成IBinder接口)调用,所以必须把service cache也替换成我们的代理对象,每次调用都会走进ServiceManagerCacheBinderHook对象的invoke()方法。
mProxiedObjCache:这里存储的是所有的proxyservice Object,那原始的service对象放在哪里呢?其实是在BinderHook的mOldObj里。
前面把service cache存起来,下次如果要真正和service进行通信,通过getOriginService()把原始的service cache拿出来用就行了。
这个类继承自ProxyHook,主要是用来hook住getService()和checkService()这两个API。如果这两个API被调用,并且在mProxiedObjCache发现有对应的代理对象,则直接返回这个代理对象。
先调用ServiceManagerCacheBinderHook的onInstall()方法更新一下service cache,然后生成一个新的代理对象放到mProxiedObjCache里。这样下次不管是从cache里取,还是直接通过binder调用,就都会返回我们的代理对象。
Binder代理其实在android 系统中也是一个十分重要的角色。
这部分可以从网上搜下相关资料。360 plugin 的Binder代理就是借鉴了系统的Binder相关。
Hook机制中Binder代理时序图
MyServiceManager
ServiceManagerCacheBinderHook
ServiceManagerBinderHook
BinderHook
Hook机制中Binder代理类关系图
Hook机制中Binder代理时序图
MyServiceManager
mOriginServiceCache:这里存储的是原始的service cache。每个ActivityThread在bindApplication()的时候,会从ServiceManager那边获得一个service cache(可以减少和Binder代理之间通信,系统Binder是一个专门的BinderProxy和把上层的service和Binder driver进行IPC),每次要和某个service通信时,会先检查这个cache里有没有代理对象,如果有的话就直接用,不需要再和ServiceManager进行一次binder交互了。
mProxiedServiceCache:这里存储的就是service cache的代理对象了,因为我们要hook这些binder和上层(serviceConnection时会转成IBinder接口)调用,所以必须把service cache也替换成我们的代理对象,每次调用都会走进ServiceManagerCacheBinderHook对象的invoke()方法。
mProxiedObjCache:这里存储的是所有的proxyservice Object,那原始的service对象放在哪里呢?其实是在BinderHook的mOldObj里。
ServiceManagerCacheBinderHook
前面把service cache存起来,下次如果要真正和service进行通信,通过getOriginService()把原始的service cache拿出来用就行了。
ServiceManagerBinderHook
这个类继承自ProxyHook,主要是用来hook住getService()和checkService()这两个API。如果这两个API被调用,并且在mProxiedObjCache发现有对应的代理对象,则直接返回这个代理对象。
BinderHook
先调用ServiceManagerCacheBinderHook的onInstall()方法更新一下service cache,然后生成一个新的代理对象放到mProxiedObjCache里。这样下次不管是从cache里取,还是直接通过binder调用,就都会返回我们的代理对象。
Binder代理其实在android 系统中也是一个十分重要的角色。
这部分可以从网上搜下相关资料。360 plugin 的Binder代理就是借鉴了系统的Binder相关。
相关文章推荐
- 插件开发之360 DroidPlugin源码分析(四)Activity预注册占坑
- 插件开发之360 DroidPlugin源码分析(二)Hook机制
- 插件开发之360 DroidPlugin源码分析(四)Activity预注册占坑
- 插件开发之360 DroidPlugin源码分析(三)Binder代理
- 插件开发之360 DroidPlugin源码分析(五)Service预注册占坑
- 插件开发之360 DroidPlugin源码分析(一)初识
- 插件开发之360 DroidPlugin源码分析(三)Binder代理
- 插件开发之360 DroidPlugin源码分析(四)Activity预注册占坑
- 插件开发之360 DroidPlugin源码分析(二)Hook机制
- 插件开发之360 DroidPlugin源码分析(五)Service预注册占坑
- 插件开发之360 DroidPlugin源码分析(二)Hook机制
- 插件开发之360 DroidPlugin源码分析(五)Service预注册占坑
- 插件开发之360 DroidPlugin源码分析(一)初识
- 插件开发之360 DroidPlugin源码分析(一)初识
- 360 Android 插件开发 DroidPlugin 代码分析 -随笔
- DroidPlugin源码分析插件进程管理以及预注册Activity,Service,ContentProvide的选择
- DroidPlugin源码分析插件运行环境初始化
- Android插件化开发 第五篇 [360 Droid Plugin]
- Jenkins插件开发(6.1)—— 分析JenkinsJOB的CRUD源码
- Android插件化开发 第五篇 [360 Droid Plugin]