Merge pull request DroidPluginTeam#281 from AlanCheen/master

修改错别字 去除无用文字

Author: cmzy

DOC/hejunlin/插件占坑，四大组件动态注册前奏（三） 系统BroadCast的注册发送流程.md

@@ -1,4 +1,4 @@
-前言：为什么要了解系统Activity，Service,BroadCastReceiver,ContentProvider的启动流程，这是一个对于即将理解插件中的四大组件动态注册，占坑的前提，如果不了解的话，那么很难了解插件hook哪此东西，又是如何骗过AMS来启动Activity,Service,BroadCastReceiver，ContentProvider？
+前言：为什么要了解系统Activity，Service,BroadCastReceiver,ContentProvider的启动流程，这是一个对于即将理解插件中的四大组件动态注册，占坑的前提，如果不了解的话，那么很难了解插件hook哪些东西，又是如何骗过AMS来启动Activity,Service,BroadCastReceiver，ContentProvider？
 
 本节主要记录系统BroadCastReceiver的注册，发送流程： 
 

DOC/hejunlin/插件占坑，四大组件动态注册前奏（二） 系统Service的启动流程.md

@@ -1,5 +1,5 @@
 
-前言：为什么要了解系统Activity，Service,BroadCastReceiver,ContentProvider的启动流程，这是一个对于即将理解插件中的四大组件动态注册，占坑的前提，如果不了解的话，那么很难了解插件hook哪此东西，又是如何骗过AMS来启动Activity,Service,BroadCastReceiver，ContentProvider？
+前言：为什么要了解系统Activity，Service,BroadCastReceiver,ContentProvider的启动流程，这是一个对于即将理解插件中的四大组件动态注册，占坑的前提，如果不了解的话，那么很难了解插件hook哪些东西，又是如何骗过AMS来启动Activity,Service,BroadCastReceiver，ContentProvider？
 
 本节主要记录系统Service的启动流程： 
 先看时序图：

DOC/hejunlin/插件开发之360 DroidPlugin源码分析（一）初识.md

@@ -10,7 +10,7 @@
 
    - b.安全性担忧（可以修改，hook一些重要信息）
 
-   - c.机型适配（不是所有机器上都能行，因为大量用反射相关，如果rom厂商深度定制了framework层，反射的方法或者类不在，容易插件运用失败） 
+   - c.机型适配（不是所有机器上都能行，因为大量用反射相关，如果rom厂商深度定制了framework层，反射的方法或者类不在，容易插件运用失败）
 
    - d. 需要预先注册权限（在Library中申请了原生系统所有的权限）
 
@@ -55,7 +55,7 @@
 
  - a.共享进程：为android提供一个进程运行多个apk的机制，通过API欺骗机制瞒过系统
 
- - b.占坑：通过预先占坑的方式实现不用在mainfest注册，通过一带多的方式实现服务管理
+ - b.占坑：通过预先占坑的方式实现不用在manifest注册，通过一带多的方式实现服务管理
 
  - c.Hook机制：动态代理实现函数hook，Binder代理绕过部分系统服务限制，IO重定向（先获取原始Object-->Read,然后动态代理Hook Object后-->Write回去，达到瞒天过海的目的）
 
@@ -66,9 +66,3 @@
 下一篇开始分析基本原理中的Hook机制
 
 ---
-
-在此输入正文
-
-
-
-

DOC/hejunlin/插件开发之360 DroidPlugin源码分析（五）Service预注册占坑.md

@@ -1,6 +1,6 @@
 在了解系统的activity，service，broadcastReceiver的启动过程后，今天将分析下360 DroidPlugin是如何预注册占坑的？本篇文章主要分析Service预注册占坑，Service占了坑后又是什么时候开始瞒天过海欺骗AMS的？先看下Agenda：
 
-- **AndroidMainfest.xml中概览**
+- **AndroidManifest.xml中概览**
 - **Service中关键方法被hook时机**
 - **startService被hook**
 - **瞒天过海流程图**
@@ -30,19 +30,19 @@ replaceFirstServiceIntentOfArgs()
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025241211)
 
-stopService,bindService,unbindService，setServiceForeground都是类似逻辑，可从源码中证实。 
-在前一篇[《插件开发之360 DroidPlugin源码分析（四）Activity预注册占坑》](http://blog.csdn.net/hejjunlin/article/details/52258434)，我们曾了解到，8个进程中的service在预注册占坑，在AndroidManifest.xml中只有一个，那如果插件要启动多个service怎么办？这是第一个问题，而我们知道所有和服务相关的都要在系统的systemServer进程中进行注册，难道DroidPlugin要逆天的本事？这是第二个问题 
-我们从代码中发现有一个ServceManager，这和android系统中大管家ServiceManager相差一个i，难道要改大管家的职责？又多了一个疑惑 
+stopService,bindService,unbindService，setServiceForeground都是类似逻辑，可从源码中证实。
+在前一篇[《插件开发之360 DroidPlugin源码分析（四）Activity预注册占坑》](http://blog.csdn.net/hejjunlin/article/details/52258434)，我们曾了解到，8个进程中的service在预注册占坑，在AndroidManifest.xml中只有一个，那如果插件要启动多个service怎么办？这是第一个问题，而我们知道所有和服务相关的都要在系统的systemServer进程中进行注册，难道DroidPlugin要逆天的本事？这是第二个问题
+我们从代码中发现有一个ServceManager，这和android系统中大管家ServiceManager相差一个i，难道要改大管家的职责？又多了一个疑惑
 仔细看了下ServceManager中的代码：
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025303415)
 ![这里写图片描述](http://img.blog.csdn.net/20160821025323853)
 ![这里写图片描述](http://img.blog.csdn.net/20160821025349024)
 
-以上代码可总结为：（以虚线分上下两部分） 
-1.上部分主要是ServceManager单例及有一个handleXXX相关的方法，下部分主要是Service的一些生命周期方法。 
-2.我们基本可以确定之前问题2和问题3的答案了，没有那么逆天的本事来操作ServiceManager，也不能修改大管家ServiceManager的职责 
-3.那问题又来了，这个类到底是做啥的？还起一个叫ServceManager的名字， 
+以上代码可总结为：（以虚线分上下两部分）
+1.上部分主要是ServceManager单例及有一个handleXXX相关的方法，下部分主要是Service的一些生命周期方法。
+2.我们基本可以确定之前问题2和问题3的答案了，没有那么逆天的本事来操作ServiceManager，也不能修改大管家ServiceManager的职责
+3.那问题又来了，这个类到底是做啥的？还起一个叫ServceManager的名字，
 以hanldeOnTaskRemoveOne方法为例看看：
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025410931)
@@ -72,18 +72,18 @@ Android系统Binder机制的总管是ServiceManager，所有的Server（System S
 
 这里以Java层加入ServiceManager及getService为数据流分析一下。
 
-复习一下典型的Binder模式,有利于后面的理解： 
-1、客户端通过某种方式得到服务器端的代理对象。从客户端角度看来代理对象和他的本地对象没有什么差别。它可以像其他本地对象一样调用其方法，访问其变量。 
-2、客户端通过调用服务器代理对象的方法向服务器端发送请求。 
-3、代理对象把用户请求通过Android内核（Linux内核）的Binder驱动发送到服务器进程。 
-4、服务器进程处理用户请求，并通过Android内核（Linux内核）的Binder驱动返回处理结果给客户端的服务器代理对象。 
+复习一下典型的Binder模式,有利于后面的理解：
+1、客户端通过某种方式得到服务器端的代理对象。从客户端角度看来代理对象和他的本地对象没有什么差别。它可以像其他本地对象一样调用其方法，访问其变量。
+2、客户端通过调用服务器代理对象的方法向服务器端发送请求。
+3、代理对象把用户请求通过Android内核（Linux内核）的Binder驱动发送到服务器进程。
+4、服务器进程处理用户请求，并通过Android内核（Linux内核）的Binder驱动返回处理结果给客户端的服务器代理对象。
 5、客户端收到服务器端的返回结果。
 
-JAVA层代码分析： 
+JAVA层代码分析：
 ServiceManager.java (frameworks\base\core\java\android\os)
 
-对于xxxManager获取服务端service基本如此用法： 
-举例： 
+对于xxxManager获取服务端service基本如此用法：
+举例：
 利用ContextImpl.java中的 public Object getSystemService(String name)
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025616886)
@@ -98,20 +98,20 @@ ServiceManager.java (frameworks\base\core\java\android\os)
 
 BinderInternal.getContextObject() @ BinderInternal.java 是一个native 函数：
 
-android_os_BinderInternal_getContextObject @ android_util_Binder.cpp 
+android_os_BinderInternal_getContextObject @ android_util_Binder.cpp
 返回一个 BinderProxy对象保存到类成员mRemote(ServiceManagerProxy类成员)
 
-public abstract class ServiceManagerNative extends Binder implements IServiceManager 
+public abstract class ServiceManagerNative extends Binder implements IServiceManager
 ServiceManagerNative 继承自 Binder 并实现了 IServiceManager 接口，利用 asInterface()则提供一个 ServiceManagerProxy 代理对象使用
 
-class ServiceManagerProxy implements IServiceManager 
+class ServiceManagerProxy implements IServiceManager
 定义了类ServiceManagerProxy（代理），ServiceManagerProxy继承自IServiceManager，并实现了其声明的操作函数，只会被ServiceManagerNative创建，它实现了IServiceManager的接口，IServiceManager提供了getService和addService两个成员函数来管理系统中的Service。
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025721230)
 
 上面代码总结如下：Java层先利用Parcel对象将数据进行序列化，然后利用transact将数据传给binder驱动，就是上面mRemote.transact，mRemote在JNI层是一个叫BpBinder的对象：
 
-JNI层代码分析： 
+JNI层代码分析：
 android_util_Binder.cpp
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025737074)
@@ -120,7 +120,6 @@ android_util_Binder.cpp
 
 ![这里写图片描述](http://img.blog.csdn.net/20160821025803184)
 
-到此，不再向下深究，具体想了解可以看Binder机制及IPC相关内容。 
-所以，到这把第2个问题彻底弄明白了，ServceManager和ServiceManager根本不是一回事。到次，Service的瞒天过海得以实现，接着，就是介绍时候说的那样无需修改源码，多进程，多service等功能。另外ContentProvider及BroadCast原理是类似，不再进行分析。 
+到此，不再向下深究，具体想了解可以看Binder机制及IPC相关内容。
+所以，到这把第2个问题彻底弄明白了，ServiceManager和ServiceManager根本不是一回事。到次，Service的瞒天过海得以实现，接着，就是介绍时候说的那样无需修改源码，多进程，多service等功能。另外ContentProvider及BroadCast原理是类似，不再进行分析。
 下篇将开始分析包管理(宿主插件和插件包名有什么规则)，APK解析（为什么可以免安装），进程管理（能确保隐藏起来，不会在process轻易被kill）
-