Android深入浅出之Binder机制
安卓binder原理
安卓binder原理安卓Binder原理一、引言在安卓系统中,进程间通信(IPC)是非常重要的,而Binder作为安卓系统中的进程间通信机制,扮演着关键的角色。
本文将介绍安卓Binder的原理及其相关概念,以便更好地理解安卓系统的工作原理。
二、安卓Binder的概述Binder是安卓系统中一种轻量级的IPC机制,其设计目标是为了提供高效的进程间通信能力。
Binder主要由Binder驱动、Binder服务和Binder代理组成。
1. Binder驱动Binder驱动是位于内核空间的模块,负责处理进程间通信的底层操作。
它提供了一组接口供用户空间进程使用,用于创建Binder节点、发送和接收Binder消息等操作。
2. Binder服务Binder服务是安卓系统中的后台服务,它可以通过Binder驱动与其他进程进行通信。
每个Binder服务都有一个唯一的标识符,称为Binder引用。
通过Binder引用,其他进程可以找到并与该服务通信。
3. Binder代理Binder代理是位于用户空间的模块,负责将进程间通信的请求转发给相应的Binder服务。
它通过Binder驱动与Binder服务进行交互,并将结果返回给请求方。
三、Binder的工作原理Binder的工作原理可以分为三个步骤:注册服务、获取引用和发起调用。
1. 注册服务Binder服务首先需要在系统中注册自己,以便其他进程可以找到并与之通信。
注册服务时,Binder服务会创建一个Binder节点,并向Binder驱动注册该节点。
注册成功后,Binder服务会获得一个唯一的Binder引用。
2. 获取引用其他进程想要与已注册的Binder服务通信,就需要获取该服务的Binder引用。
获取引用的过程是通过Binder代理完成的。
Binder 代理首先通过Binder驱动找到对应的Binder节点,然后获取该节点的引用,并将引用返回给请求方。
3. 发起调用一旦获取到Binder引用,请求方可以通过Binder代理向对应的Binder服务发起调用。
android binder stub. 的理解
在Android 操作系统中,Binder 是一种用于进程间通信(IPC)的机制。
Binder 机制允许一个进程的代码调用另一个进程中的代码,通常在Android 中用于实现不同应用程序组件(例如服务)之间的通信。
在Binder 机制中,有两个主要的角色:Binder 服务和Binder 客户端。
Binder 服务通常运行在一个独立的进程中,而Binder 客户端则希望与服务进行通信。
为了进行通信,服务需要提供一个Binder 接口,而客户端需要获取到该接口以调用服务提供的方法。
这就涉及到Binder Stub。
Binder Stub:Binder Stub 是一个在客户端进程中的代理对象,用于代表服务端的实际对象。
在Android 中,Stub 通常是由系统自动生成的,并负责处理客户端发起的远程调用请求。
当客户端调用Binder 接口中的方法时,实际的工作是由Stub 完成的。
具体而言,Binder Stub 的工作包括:1. 接收远程调用请求:当客户端调用Binder 接口的方法时,实际上是通过Binder Stub 发送远程调用请求到服务端的对应Binder 对象。
2. 序列化和反序列化参数:Binder Stub 负责将客户端传递的参数序列化为二进制数据,并将服务端返回的结果反序列化为适当的数据类型。
3. 将请求发送到服务端:Binder Stub 将序列化后的请求发送到服务端,并等待服务端的响应。
4. 接收并处理服务端的响应:一旦服务端处理完请求,它将结果序列化并通过Binder Stub 发送回客户端。
5. 通知客户端调用完成:Binder Stub 负责通知客户端,使其能够继续执行。
在整个过程中,Binder Stub 充当了客户端和服务端之间的桥梁,隐藏了底层IPC 细节,使得远程调用就像本地调用一样。
这样,客户端不需要了解服务端的实际实现,而只需要通过Binder 接口与Stub 进行交互。
android 进程之间的通信binder原理
Android进程间的通信(IPC)机制的原理基于Linux内核提供的进程间通信机制(IPC)实现。
在Android系统中,Binder是其中的一种跨进程通信机制。
Binder机制中,每个进程都有一个Binder驱动程序,负责管理该进程中的所有Binder对象。
每个Binder对象都有一个唯一的标识符,称为Binder标识符(Binder identity),可以用于在进程之间传递Binder 引用。
在Binder机制中,客户端和服务端进程之间可以建立一个通信通道(communication channel)。
客户端可以通过这个通道向服务端发送请求,服务端可以处理请求并返回结果。
Binder机制中的主要组件包括以下几个部分:1. Binder驱动程序:负责管理Binder对象,以及为客户端进程和服务进程之间建立通信通道。
2. Binder对象:具有唯一标识符的对象,用于在进程之间传递引用。
3. Binder接口:定义了客户端可以调用的方法,以及服务端可以实现的方法。
4. Binder代理(Proxy):客户端进程中的对象,用于与服务端进程通信,并代表客户端调用服务端的方法。
5. Binder Stub:服务端进程中的对象,用于实现Binder接口,并处理客户端发送的请求。
使用Binder机制可以实现跨进程通信,例如在Android应用程序中,可以使用AIDL(Android Interface Definition Language)定义接口和方法,并使用Binder机制在客户端进程和服务端进程之间进行通信。
这样可以提高应用程序的性能和响应速度。
需要注意的是,使用Binder进行进程间通信需要在应用程序开发中进行特殊设计和配置,而且Binder通信也可能存在性能和安全性的问题。
因此,在实际开发中需要谨慎考虑使用场景和限制条件。
androidbinder机制原理
androidbinder机制原理Android Binder 机制原理什么是 Android Binder 机制?Android Binder 机制是 Android 系统中用于进行进程间通信(IPC)的核心机制之一。
它负责在不同的 Android 组件之间传递数据和进行远程方法调用。
为什么 Android 需要 Binder 机制?Android 系统的设计中,每个应用程序运行在独立的进程中,它们之间需要进行信息交换和协作。
而 Binder 机制提供了一种高效、安全和可靠的方式来实现进程间通信。
Binder 机制的关键组件Binder 机制主要由以下几个关键组件组成:1. 服务端(Server)服务端是提供服务的组件,它通过继承Binder类并实现对应的接口,将服务提供给客户端使用。
2. 客户端(Client)客户端是使用服务的组件,它通过 Binder 机制与服务端进行通信,获取所需的数据或调用对应的方法。
3. Binder 驱动(Binder Driver)Binder 驱动是位于 Linux 内核中的模块,负责处理进程间通信的底层操作,如进程注册、线程管理、进程间通信等。
4. Binder 通信线程(Binder Communication Thread)Binder 通信线程是运行在客户端和服务端进程中的线程,负责处理进程间通信的具体细节,如数据传输、对象序列化等。
5. Binder 编译器(Binder Compiler)Binder 编译器是将服务端定义的接口文件生成对应的 Java 接口和代理类,用于客户端与服务端的通信。
Binder 机制的工作流程Android Binder 机制的工作流程可以简要描述如下:1.客户端通过绑定机制连接到服务端,获取服务的引用。
2.客户端通过服务的引用调用远程方法,并传递相应的参数。
3.客户端的请求通过 Binder 通信线程封装成消息并发送给服务端。
binder机制原理
binder机制原理Binder机制原理。
Binder机制是Android系统中的一种进程间通信(IPC)方式,它允许不同进程之间进行数据交换和通信。
在Android系统中,各个应用程序运行在自己的进程中,它们需要进行数据共享和通信,而Binder机制就是为了解决这个问题而设计的。
Binder机制的原理可以简单概括为,Binder驱动程序、Binder通信线程和Binder通信的数据结构。
在Android系统中,Binder驱动程序负责管理Binder通信,它将用户空间的Binder通信请求转发到内核空间,并在内核空间中完成通信操作。
Binder通信线程则是在用户空间和内核空间之间进行通信的桥梁,它负责将用户空间的通信请求传递给Binder驱动程序,并将内核空间的通信结果返回给用户空间。
而Binder通信的数据结构则是用来传递和存储通信数据的,它包括Binder引用、Binder节点和Binder死亡通知等。
在Android系统中,每个进程都有一个Binder驱动程序和一个Binder通信线程,它们负责处理进程内部的Binder通信。
当一个进程需要和另一个进程进行通信时,它会通过Binder驱动程序向目标进程发送一个Binder引用,目标进程接收到Binder引用后,就可以通过Binder通信线程和目标进程进行通信。
这样,就实现了不同进程之间的数据共享和通信。
Binder机制的原理虽然看起来比较复杂,但在实际使用中,开发者只需要使用Android提供的Binder API就可以轻松实现进程间通信。
Android系统已经封装了Binder机制的底层实现,开发者只需要关注业务逻辑即可。
在Android开发中,常用的Binder通信方式包括AIDL(Android Interface Definition Language)和Messenger等,它们都是基于Binder机制实现的。
总的来说,Binder机制是Android系统中非常重要的一部分,它为不同进程之间的数据共享和通信提供了良好的解决方案。
binder 原理
binder 原理Binder是Android系统中的一种进程间通信(IPC)机制,用于不同进程间的对象调用和数据传输。
Binder的原理主要包括以下几个部分:1. Binder驱动:Binder驱动是Linux内核中的一部分,它提供了底层的IPC支持。
每个进程都可以通过特殊文件/dev/binder与驱动进行通信。
2. Binder机制:Binder机制通过三个重要的组件来实现进程间通信,分别是ServiceManager、Binder驱动和Binder通信框架。
- ServiceManager:ServiceManager是Binder的管理服务。
它保持对每个注册的“服务”对象的引用,并通过指定的接口名称提供对这些服务对象的访问。
- Binder驱动:Binder驱动负责处理底层的IPC通信,包括进程间的消息传递和对象的引用传递。
Binder驱动通过Binder节点(Binder Node)维护了一个全局的对象引用表,每个Binder对象都有一个唯一的Binder引用。
- Binder通信框架:Binder通信框架运行在用户态,负责进程间的通信,包括进程之间的消息传递、对象的引用传递等。
它提供了一些基本的类,如Binder、IBinder、BinderProxy等,用于实现跨进程调用、远程对象引用等功能。
3. Binder对象:在Binder机制中,对象是通过Binder对象来实现的。
每个Binder对象都实现了IBinder接口,IBinder接口定义了一些基本的操作,如查询Binder引用、跨进程调用等。
4. 跨进程调用过程:当一个进程需要调用另一个进程中的对象时,它首先从ServiceManager查询目标对象的引用。
然后,它将调用请求以消息的形式发送给目标进程。
在目标进程中,Binder驱动接收到消息后,将消息交给Binder通信框架处理。
Binder通信框架通过查询全局的对象引用表,找到目标对象并调用相应的方法。
binder线程池工作原理
binder线程池工作原理Binder线程池是Android中用于处理跨进程通信(IPC)的一种机制,它的工作原理是通过维护一个线程池来处理跨进程通信的请求。
在本文中,我们将深入探讨Binder线程池的工作原理以及它在Android系统中的应用。
我们需要了解Binder的基本概念。
Binder是Android中的一种IPC 机制,它允许不同进程间进行通信。
在Android系统中,每个进程都有一个Binder驱动,它负责处理进程间通信的请求。
当一个进程需要与另一个进程进行通信时,它会通过Binder驱动发送请求,并等待对方进程的响应。
在Android系统中,每个进程都有一个Binder线程池,它用于处理进程间通信的请求。
当一个进程接收到一个跨进程通信的请求时,它会将该请求放入自己的Binder线程池中,并由线程池中的一个线程来处理该请求。
Binder线程池的工作原理如下:当一个进程接收到一个跨进程通信的请求时,它首先会判断当前是否有空闲的线程可以处理该请求。
如果有空闲的线程,则将该请求交给空闲线程处理;如果没有空闲的线程,则会根据一定的策略创建一个新的线程来处理该请求。
在处理请求时,Binder线程池会先检查请求的类型。
如果是一个耗时的操作,比如读取大量数据,线程池会将该请求放入一个专门处理耗时操作的线程中。
这样可以避免耗时操作对其他请求的影响。
如果是一个简单的操作,线程池会将该请求放入一个普通的线程中处理。
Binder线程池还会维护一个请求队列,用于存放等待处理的请求。
当所有线程都在处理其他请求时,新的请求会被放入请求队列中,等待线程池有空闲的线程时再进行处理。
需要注意的是,Binder线程池的大小是有限的。
在Android系统中,默认情况下,每个进程的Binder线程池大小为16。
这是因为线程的创建和销毁都需要消耗一定的系统资源,如果线程池过大,会导致系统资源的浪费。
因此,Android系统为每个进程设置了一个适当的线程池大小,以确保系统资源的合理利用。
Android深入浅出之Binder机制
Android深⼊浅出之Binder机制Android深⼊浅出之Binder机制⼀说明Android系统最常见也是初学者最难搞明⽩的就是Binder了,很多很多的Service就是通过Binder机制来和客户端通讯交互的。
所以搞明⽩Binder的话,在很⼤程度上就能理解程序运⾏的流程。
我们这⾥将以MediaService的例⼦来分析Binder的使⽤:l ServiceManager,这是Android OS的整个服务的管理程序l MediaService,这个程序⾥边注册了提供媒体播放的服务程序MediaPlayerService,我们最后只分析这个l MediaPlayerClient,这个是与MediaPlayerService交互的客户端程序下⾯先讲讲MediaService应⽤程序。
⼆ MediaService的诞⽣MediaService是⼀个应⽤程序,虽然Android搞了七七⼋⼋的JAVA之类的东西,但是在本质上,它还是⼀个完整的Linux操作系统,也还没有⽜到什么应⽤程序都是JAVA写。
所以,MS(MediaService)就是⼀个和普通的C++应⽤程序⼀样的东西。
MediaService的源码⽂件在:framework\base\Media\MediaServer\Main_mediaserver.cpp中。
让我们看看到底是个什么玩意⼉!int main(int argc, char** argv){//FT,就这么简单??//获得⼀个ProcessState实例sp<ProcessState> proc(ProcessState::self());//得到⼀个ServiceManager对象sp<IServiceManager> sm = defaultServiceManager();MediaPlayerService::instantiate();//初始化MediaPlayerService服务ProcessState::self()->startThreadPool();//看名字,启动Process的线程池?IPCThreadState::self()->joinThreadPool();//将⾃⼰加⼊到刚才的线程池?}其中,我们只分析MediaPlayerService。
android binder 原理
android binder 原理AndroidBinder是一种IPC机制,是 Android 系统中非常重要的一部分。
它使得不同进程之间可以通过接口来进行通信,实现了进程间的数据传输,从而让应用程序之间可以互相协作。
Android Binder 主要由以下两个部分组成:Binder 驱动和Binder 服务。
Binder 驱动是位于内核空间的模块,它负责管理进程间通信的核心逻辑。
Binder 服务则是位于用户空间的进程,它负责提供接口,允许其他进程通过 Binder 驱动来进行通信。
Android Binder 采用面向对象的方式来实现进程间通信。
每个Binder 服务都有一个唯一的标识符,称为 Binder ID。
其他进程可以通过 Binder ID 来访问对应的 Binder 服务。
在 Binder 服务中,会定义一些接口,用于提供数据传输和方法调用的功能。
Binder 服务通过 Binder 驱动来进行注册和管理,当其他进程需要访问该服务时,Binder 驱动会将请求传递给对应的 Binder 服务。
Android Binder 采用了一些特殊的机制来实现进程间通信的安全性和效率。
例如,Binder 驱动会对传输的数据进行序列化和反序列化,以确保数据的正确性和一致性。
此外,Binder 驱动还实现了优化机制,能够对频繁的数据传输进行加速,提高传输效率。
总的来说,Android Binder 是 Android 系统中非常重要的一部分。
它实现了进程间通信的功能,让应用程序之间可以互相协作。
对于 Android 开发者来说,理解 Android Binder 的原理,能够更好地进行应用程序的开发和优化。
初探Android中的binder机制
初探Android中的binder机制Binder机制是Android系统中最主要的进程间通信机制。
虽然Android底层使用的是linux内核,但是除了匿名管道,socket外,Android并没有使用linux 中的命名管道,信号量,消息队列等传统的IPC通信方式。
Binder犹如一张大网,将Android整个系统中的组件,跨进程的组织在一起。
淡化进程,强化组件是Android的一个设计理念。
在这个过程中,Binder发挥了巨大作用。
binder 的作用binder的作用可以概括为两点:IPC:是一种跨进程通信手段,但是传输数据的大小受限制,不建议传输较大数据。
RPC:是一种远程过程调用手段,即一个进程中可以透明的调用另外一个进程中的方法。
两者经常相互伴随,例如跨进程调用的时候,参数的传递以及结果的传递等。
binder机制简述binder实体对象:就是binder服务的提供者,一个提供binder服务的类必须继承BBinder类(native层),因此binder实体对象又叫做BBinder对象。
binder引用对象:是binder服务提供者在客户端进程的代表,每个引用对象类型必须继承BpBinder类(native层),因此binder引用对象有叫做BpBinder对象。
binder代理对象:代理对象简单理解为内聚了一个binder引用对象,因此可以通过这个内聚的引用对象发起RPC调用。
可以有多个不同的代理对象,但却内聚了同一个引用对象。
IBinder对象:BBinder和BpBinder都是继承自IBinder.因此binder实体对象和binder引用对象都可以称为IBinder对象。
可以通过IBinder.queryLocalInterface()方法来判断到底是binder实体对象还是binder引用对象。
binder跨进程传输的数据类型是Parcel。
以RPC为例的示意图如下:android_binder-1.png通过一个运行在内核空间的binder驱动进程,将两个用户空间的进程联系了起来。
binder原理和实现机制
binder原理和实现机制Binder是Android系统中的一个重要组件,它不仅用于进程间通信,同时还承担了Android系统中各种管理任务,如权限管理、服务管理等。
本文将围绕Binder原理和实现机制进行详细讲解。
一、Binder原理Binder原理主要由Binder驱动、Binder进程间通信机制和Binder对象管理系统三部分组成。
1. Binder驱动Binder驱动作为Android系统内核的一部分,它是Binder通信的核心组成部分。
其主要作用是与内核中的线程调度器以及内存管理器无缝协作,将进程间通信的数据从一个进程传递到另外一个进程。
被称为Binder通信的进程被称为Server端(或者binder服务进程),负责处理来自其他客户端进程的请求。
被称为Client端(或者binder客户端进程),则通过Binder接口来调用Server端的服务。
2. Binder进程间通信机制Binder进程间通信机制基于C/S(Client/Server)架构,具有一下特点:① Client进程向Server进程请求Binder服务;② Server进程响应Client进程请求;③ Server进程提供一个或者多个Binder对象,Client进程通过Binder对象来访问服务;④ Client进程通过ServiceManager来获取Binder对象,ServiceManger在Server进程中需要提供相关的服务注册操作。
3. Binder对象管理系统每个Binder对象在系统中都有一个唯一的标识符,称之为Binder引用。
Binder对象管理系统负责管理Binder引用,每个Binder引用对应一个Binder对象,并保存在进程的Binder引用表中。
Client进程向ServiceManager请求获取Binder对象时,实际上是请求ServiceManager返回Binder引用。
Client进程获取到Binder引用后,可以通过Binder引用从Binder对象管理系统中获取到Server端提供的Binder对象。
binder机制原理
binder机制原理
一、binder机制原理
1.什么是binder机制
Binder机制是Android系统中方便实现进程间通信的一种机制,它使得进程之间可以通过内核层实现远程方法调用。
它是服务管理器Service Manager的基础,可以实现在Android系统中各个应用进程之间进行通信。
2.binder机制的主要作用
(1)实现Android内部多进程间的通信,也可以实现跨进程的数据交换和消息传递。
(2)实现Android内部进程之间的远程方法调用,可以实现一个进程使用另外一个进程的服务和功能。
(3)实现Android系统的服务管理,比如实现服务的启动、停止和管理等功能。
3.binder机制的工作流程
(1)先绑定:首先是两个应用间实现绑定,也就是通过Service Manager完成的提供应用传递参数进行绑定,即Client向Service Manager发送信息,将Service和Client进行绑定。
(2)再调用:绑定完成之后,Client可以直接调用Service内部的函数,进行多进程间的通信。
(3)再解绑:最后,Client可以对这个Service关闭或者解绑,也就是关闭进程之间的连接,释放资源。
android binder机制原理
android binder机制原理Android Binder机制原理在Android系统中,不同进程间的通信是非常常见的,例如应用程序之间或系统服务之间的通信。
为了保证通信的稳定和效率,Android系统采用了一种名为Binder机制的进程间通信(IPC)方案。
本文将介绍Android Binder机制的原理以及它的工作模式。
一、Android Binder机制的原理Android Binder机制是基于C++语言和Linux内核的,在Binder 机制中最重要的概念是“Binder对象”。
Binder对象是一个可以跨进程使用的对象,它通过进程间共享内存的方式进行通信,以提高性能和效率。
Binder机制通过Binder驱动程序在内核空间和用户空间之间建立虚拟连接。
具体来说,Binder机制的原理是:当一个进程请求访问另一个进程中的对象时,它会通过Binder驱动程序向目标进程发送一个请求消息。
进程B在收到请求消息后,将生成一个Binder对象,并将其返回给进程A。
之后,进程A通过这个Binder对象与进程B进行通信,这样就完成了进程间的通信。
二、Android Binder机制的工作模式1. Binder通信基本框架Android Binder机制的基本框架可以描述如下:(1) Binder驱动程序在内核空间中负责处理进程A和进程B之间的通信。
(2) 进程A通过Binder通信建立一个客户端,与进程B建立连接。
(3) 进程B在客户端连接上创建一个Binder服务对象,以提供服务。
(4) 进程A和进程B基于客户端与服务对象进行通信。
2. Binder服务Binder服务是Android Binder机制的核心,它是一种用于提供跨进程通信服务的对象。
在Binder服务中,最为重要的是“Binder对象”。
每个Binder服务都会生成一个唯一的Binder对象,这个对象代表了这个服务的身份标识。
安卓binder工作原理
安卓binder工作原理【实用版】目录1.Binder 的产生背景2.Binder 的定义和作用3.Binder 的工作原理4.Binder 的优势和应用场景5.总结正文一、Binder 的产生背景在 Android 系统中,由于应用程序需要实现各种各样的 IPC(进程间通信)需求,例如启动一个 Activity、与 System Services 交互等,因此亟需一种可靠的 IPC 解决方案。
在 Android 系统中,Binder 应运而生,它成为了 Android 系统中进程间通信的主要方式。
二、Binder 的定义和作用Binder 是一种实现了 IBinder 接口的类,主要用来实现跨进程通信。
从 Android 框架角度来说,Binder 是 ServerManager 连接各种Manager 和 ManagerService 的桥梁。
简而言之,Binder 是一种在Android 设备上进行 IPC 的主要方式,它主要用于实现跨进程通信。
三、Binder 的工作原理1.Binder 的创建:当一个进程需要与另一个进程通信时,会创建一个 Binder 对象。
在创建过程中,会通过 IPC 机制将请求发送到目标进程,目标进程收到请求后,会创建一个对应的 Binder 对象。
2.Binder 的通信:Binder 对象之间通过消息传递进行通信。
发送方将消息封装成一个 Parcel 对象,然后将 Parcel 对象发送给接收方。
接收方收到 Parcel 对象后,会将其解析为消息,然后进行相应的处理。
3.Binder 的安全性:Binder 通信过程中,会受到 Android 权限系统的监控。
只有在权限允许的情况下,Binder 通信才能进行。
这保证了Binder 通信的安全可靠。
四、Binder 的优势和应用场景Binder 的优势主要体现在其安全性和易用性。
由于 Binder 通信过程受到权限系统的监控,因此可以确保通信的安全性。
[IT计算机]androidbinder机制
Android进程间通信-Binder机制目录一.简要介绍和学习计划二.Service Manager成为Binder守护进程之路三.Server和Client获得Service Manager接口之路四.Server启动过程源代码分析五.Client获得Server远程接口过程源代码分析六.应用程序框架层的Java接口源代码分析一、Android进程间通信(IPC)机制Binder 简要介绍和学习计划我们知道,在Android系统中,每一个应用程序都是由一些Activity和Service组成的,一般Service 运行在独立的进程中,而 不同的Activity有可能运行在同一个进程中,也可能运行在不同的进程中。
这很自然地想到,不在同一个进程的Activity和Service是如何 通信的呢?毕竟它们要协作在一起来完成一个完整的应用程序功能。
这就是本文中要介绍的Android系统进程间通信机制Binder了。
我们知道,Android系统是基于Linux内核的,而Linux内核继承和兼容了丰富的Unix系统进程间通信(IPC)机制。
有传统的管道 (Pipe)、信号(Signal)和跟踪(Trace),这三项通信手段只能用于父进程与子进程之间,或者兄弟进程之间;后来又增加了命令管道 (Named Pipe),使得进程间通信不再局限于父子进程或者兄弟进程之间;为了更好地支持商业应用中的事务处理,在AT&T的Unix 系统V中,又增加了 三种称为“System V IPC”的进程间通信机制,分别是报文队列(Message)、共享内存(Share Memory)和信号量(Semaphore);后来BSD Unix对“System V IPC”机制进行了重要的扩充,提供了一种称为插口(Socket)的进程间通信机制。
若想进一步详细了解这些进程间通信机制,建议参考Android学习启动篇一文中提到《Linux内核源代码情景分析》一书。
浅谈Android下binder的调用与拦截
交流E XPERIENCEOCCUPATION952013 04浅谈Android下b i nder的调用与拦截李佳琳摘 要:Binder是Android系统进程间通信方式之一。
Linux已经拥有管道system V IPC、socket等IPC手段,却还要倚赖Binder来实现进程间通信,说明Binder具有无可比拟的优势。
本文通过对Binder的详细介绍以及与其他IPC通信方式的调用,使大家对Binder的优势和使用Binder作为Android主要IPC方式的原因有所了解。
关键词:Android system_server binder本文内容包含使用在拥有root权限的Android2.3平台上针对system_server中binder通信的拦截。
一、动态链接机制及Binder拦截选址要拦截模块甲对乙的调用,一般思路是通过ptrace远程注入并加载一新拦截模块至模块甲,并搜索模块甲的GOT 表,找到对模块乙的调用地址,改成新模块内的某函数地址,然后新模块内的这个函数在进行了自己的处理后,再跳到模块乙中。
这里用户进程空间所加载的libbinder.so和system_server端加载的libbinder.so在逻辑上不是同一个东西。
正因为不是同一个东西,我们才能针对system_server进程中加载的libbinder.so动手,拦截其GOT表中对ioctl的调用,从而提前知道Service要返回的内容。
这个ioctl就是拦截的选址所在。
二、具体实现在这个常驻system_server进程内的共享库里,只实现了简单几个函数,其中do_hook函数在注入后通过外界调用,它不做具体的hook动作,仅仅只是把所需的两个函数地址写入Android的Property供外界使用:[cpp] view plaincopy01.//将新旧ioctl地址写入Andorid的Property供外界使用;02.int do_hook(void * param) 03.{04.old_ioctl = ioctl;05.printf("Ioctl addr: %p. New addr %p\n", ioctl, new_ioctl);06.07.char value[PROPERTY_VALUE_MAX] = {'\0'};08.snprintf(value, PROPERTY_VALUE_MAX, "%u", ioctl);09.property_set(PROP_OLD_IOCTL_ADDR, value);10.11.snprintf(value, PROPERTY_VALUE_MAX, "%u",new_ioctl);12.property_set(PROP_NEW_IOCTL_ADDR, value);13.14.return 0;15.}16.17.//全局变量用以保存旧的ioctl地址,其实也可直接使用ioctl;18.int (*old_ioctl) (int __fd,unsigned long int __request, void * arg) = 0;19.int res = (*old_ioctl)(__fd,__request, arg);20.return res;21.}.三、小结第一,每个被加载的模块,无论是可执行程序还是共享库,均有自己独立的PLT和GOT表。
Binder的工作机制浅析
Binder的⼯作机制浅析在Android开发中,Binder主要⽤于Service中,包括AIDL和Messenger,其中Messenger的底层实现就是AIDL,所以我们这⾥通过AIDL来分析⼀下Binder的⼯作机制。
⼀、在Android Studio中建⽴AIDL⾸先,我们需要建⽴⼀个AIDL1.在建⽴了对应的实现Parcelable接⼝的实体类和AIDL接⼝后,⽂件结构如下:2.点击clean Project/reBuild Project,出现如下错误:提⽰⽆法找到Book实体类。
3.解决⽅案这个问题的出现是因为我还没有在build.gradle中对默认的sourceSets进⾏修改,默认情况下他指定的源码⽬录不包括aidl。
加⼊下⾯语句后同步build.gradle,再重建⼯程即可。
在app下的build.gradle添加:系统⾃动⽣成的IBookManager⼆、Binder原理分析通过Structure我们可以看到这个系统⽣成这个接⼝⽂件包括⼀个静态抽象类Stub和两个⽅法getBookList()和addBook(),这两个⽅法很显然就是我们之前在IBookManager.aidl中声明的⽅法,此外它还为这两个⽅法⽤两个int来标⽰,从⽽在onTransact()⽅法中起到标⽰作⽤,如下所⽰:⽽内部类Stub继承⾃Binder,在这个类内部⼜有⼀个代理类Proxy。
接下来看这⼀段代码:这⾥判断了客户端和服务端是否处于同⼀个进程中,如果处于同⼀个进程中,则⽅法调⽤不会⾛跨进程的transact⽅法,⽽如果处于不同的进程中,则需要通过其中的代理⾥proxy来完成。
下⾯展现代理类在这个代理类中的getBookList和addBook⽅法中调⽤transact⽅法来发起RPC(远程过程调⽤)请求,并将当前线程挂起,然后服务端的onTransact⽅法响应并执⾏,当RPC过程返回后,当前线程继续执⾏。
AndroidBinder机制(超级详尽)
AndroidBinder机制(超级详尽)1.binder通信概述binder通信是⼀种client-server的通信结构,1.从表⾯上来看,是client通过获得⼀个server的代理接⼝,对server进⾏直接调⽤;2.实际上,代理接⼝中定义的⽅法与server中定义的⽅法是⼀⼀对应的;3.client调⽤某个代理接⼝中的⽅法时,代理接⼝的⽅法会将client传递的参数打包成为Parcel 对象;4.代理接⼝将该Parcel发送给内核中的binder driver.5.server会读取binder driver中的请求数据,如果是发送给⾃⼰的,解包Parcel对象,处理并将结果返回;6.整个的调⽤过程是⼀个同步过程,在server处理的时候,client会block住。
2.service managerService Manager是⼀个linux级的进程,顾名思义,就是service的管理器。
这⾥的service是什么概念呢?这⾥的service的概念和init过程中init.rc中的service是不同,init.rc中的service是都是linux进程,但是这⾥的service它并不⼀定是⼀个进程,也就是说可能⼀个或多个service属于同⼀个linux进程。
在这篇⽂章中不加特殊说明均指android native端的service。
任何service在被使⽤之前,均要向SM(Service Manager)注册,同时客户端需要访问某个service时,应该⾸先向SM查询是否存在该服务。
如果SM存在这个service,那么会将该service 的handle返回给client,handle是每个service的唯⼀标识符。
SM的⼊⼝函数在service_manager.c中,下⾯是SM的代码部分int main(int argc, char **argv){struct binder_state *bs;void *svcmgr = BINDER_SERVICE_MANAGER;bs = binder_open(128*1024);if (binder_become_context_manager(bs)) {LOGE("cannot become context manager (%s)/n", strerror(errno));return -1;}svcmgr_handle = svcmgr;binder_loop(bs, svcmgr_handler);return 0;}这个进程的主要⼯作如下:1.初始化binder,打开/dev/binder设备;在内存中为binder映射128K字节空间;2.指定SM对应的代理binder的handle为0,当client尝试与SM通信时,需要创建⼀个handle为0的代理binder,这⾥的代理binder其实就是第⼀节中描述的那个代理接⼝;3.通知binder driver(BD)使SM成为BD的context manager;4.维护⼀个死循环,在这个死循环中,不停地去读内核中binder driver,查看是否有可读的内容;即是否有对service的操作要求, 如果有,则调⽤svcmgr_handler回调来处理请求的操作。
AndroidFramework学习(四):Binder机制与代理模式
AndroidFramework学习(四):Binder机制与代理模式Binder是Android的进程间通信核⼼,Android的各种核⼼服务都是通过Binder机制进⾏相互通信的。
熟悉Binder机制话就会知道,Binder的client部分就是通过代理模式来访问Server端的。
本⽂我们就结合代理模式来详细讲解⼀下Java层Binder机制。
⼀、代理模式介绍相信⼤家对设计模式都有⼀定的了解,这⾥我就不对代理模式进⾏过多的赘述了。
这⾥我们只在阐释⼀下代理模式的使⽤场景:远程代理(Remote Proxy):如果某个对象⽆法实例化,不在同⼀个地址空间,需要通过编码来进⾏通信。
⽐如需要访问⽹络服务器上⾯的⼀个对象操作,⽐如Binder。
虚代理(Virtual Proxy):在需要的时候创建⼤对象,⽐如超⼤图⽚,我们可以使⽤⼀个虚代理代理图像,在真正需要的时候再去将图像完全加载出来,在这之前只需要在代理⾥⾯保存图像的⼤⼩,让它有个占位就好了。
保护代理(Protect Proxy):需要对对象的某些操作进⾏隐藏,那么就可以使⽤代理对它的接⼝进⾏隐藏。
智能指引(Smart Reference):当需要对对象的引⽤进⾏计数的时候,可以使⽤智能指引的代理模式。
⼆、Binder机制Binder是⼀个接⼝形式的IPC。
这⾥以Android开发过程中使⽤的.aidl⽂件声明⽣成的接⼝为例。
例如,我们在Client端声明了⼀个IUserVerifyInterface.aidl,⽤于向服务端发起⽤户校验:// IUserVerifyInterface.aidlpackage com.renhui.aidl;import er;// Declare any non-default types here with import statementsinterface IUserVerifyInterface {boolean verifyUser(in User user);}在编译运⾏之前,编辑器会⾃动⽣成相关的类 IUserVerifyInterface.Stub 和 IUserVerifyInterface.Proxy,通过调⽤bindService就可以得到Binder的代理。
深入浅出binder机制
{ if (gProcess != NULL) return gProcess;---->第一次进来肯定不走这儿 AutoMutex _l(gProcessMutex);--->锁保护 if (gProcess == NULL) gProcess = new ProcessState;--->创建一个 ProcessState
2.1 ProcessState
第一个调用的函数是 ProcessState::self(),然后赋值给了 proc 变量,程序运行完,proc 会 自动 delete 内部的内容,所以就自动释放了先前分配的资源。 ProcessState 位置在 framework\base\libs\binder\ProcessState.cpp
, mVMStart(MAP_FAILED)//映射内存的起始地址 , mManagesContexts(false) , mBinderContextCheckFunc(NULL) , mBinderContextUserData(NULL) , mThreadPoolStarted(false) , mThreadPoolSeq(1) { if (mDriverFD >= 0) { //BIDNER_VM_SIZE 定义为(1*1024*1024) - (4096 *2) 1M-8K
二 MediaService 的诞生 MediaService 是一个应用程序,虽然 Android 搞了七七八八的 JAVA 之类的东西,但是在本 质上,它还是一个完整的 Linux 操作系统,也还没有牛到什么应用程序都是 JAVA 写。所以, MS(MediaService)就是一个和普通的 C++应用程序一样的东西。 MediaService 的源码文件在: framework\base\Media\MediaServer\Main_mediaserver.cpp 中。让我们看看到底是个 什么玩意儿!
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Android深入浅出之Binder机制一说明Android系统最常见也是初学者最难搞明白的就是Binder了,很多很多的Service就是通过Binder机制来和客户端通讯交互的。
所以搞明白Binder的话,在很大程度上就能理解程序运行的流程。
我们这里将以MediaService的例子来分析Binder的使用:●ServiceManager,这是Android OS的整个服务的管理程序●MediaService,这个程序里边注册了提供媒体播放的服务程序MediaPlayerService,我们最后只分析这个●MediaPlayerClient,这个是与MediaPlayerService交互的客户端程序下面先讲讲MediaService应用程序。
二 MediaService的诞生MediaService是一个应用程序,虽然Android搞了七七八八的JAVA之类的东西,但是在本质上,它还是一个完整的Linux操作系统,也还没有牛到什么应用程序都是JAVA写。
所以,MS(MediaService)就是一个和普通的C++应用程序一样的东西。
MediaService的源码文件在:framework\base\Media\MediaServer\Main_mediaserver.cpp中。
让我们看看到底是个什么玩意儿!int main(int argc, char** argv){//FT,就这么简单??//获得一个ProcessState实例sp<ProcessState> proc(ProcessState::self());//得到一个ServiceManager对象sp<IServiceManager> sm = defaultServiceManager();MediaPlayerService::instantiate();//初始化MediaPlayerService服务ProcessState::self()->startThreadPool();//看名字,启动Process的线程池?IPCThreadState::self()->joinThreadPool();//将自己加入到刚才的线程池?}其中,我们只分析MediaPlayerService。
这么多疑问,看来我们只有一个个函数深入分析了。
不过,这里先简单介绍下sp这个东西。
sp,究竟是smart pointer还是strong pointer呢?其实我后来发现不用太关注这个,就把它当做一个普通的指针看待,即sp<IServiceManager>======》IServiceManager*吧。
sp是google搞出来的为了方便C/C++程序员管理指针的分配和释放的一套方法,类似JAVA 的什么WeakReference之类的。
我个人觉得,要是自己写程序的话,不用这个东西也成。
好了,以后的分析中,sp<XXX>就看成是XXX*就可以了。
2.1 ProcessState第一个调用的函数是ProcessState::self(),然后赋值给了proc变量,程序运行完,proc会自动delete内部的内容,所以就自动释放了先前分配的资源。
ProcessState位置在framework\base\libs\binder\ProcessState.cppsp<ProcessState> ProcessState::self(){if (gProcess != NULL) return gProcess;---->第一次进来肯定不走这儿AutoMutex _l(gProcessMutex);--->锁保护if (gProcess == NULL) gProcess = new ProcessState;--->创建一个ProcessState 对象return gProcess;--->看见没,这里返回的是指针,但是函数返回的是sp<xxx>,所以//把sp<xxx>看成是XXX*是可以的}再来看看ProcessState构造函数//这个构造函数看来很重要ProcessState::ProcessState(): mDriverFD(open_driver())----->Android很多代码都是这么写的,稍不留神就没看见这里调用了一个很重要的函数, mVMStart(MAP_FAILED)//映射内存的起始地址, mManagesContexts(false), mBinderContextCheckFunc(NULL), mBinderContextUserData(NULL), mThreadPoolStarted(false), mThreadPoolSeq(1){if (mDriverFD >= 0) {//BIDNER_VM_SIZE定义为(1*1024*1024) - (4096 *2) 1M-8KmVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE,mDriverFD, 0);//这个需要你自己去man mmap的用法了,不过大概意思就是//将fd映射为内存,这样内存的memcpy等操作就相当于write/read(fd)了}...}最讨厌这种在构造list中添加函数的写法了,常常疏忽某个变量的初始化是一个函数调用的结果。
open_driver,就是打开/dev/binder这个设备,这个是android在内核中搞的一个专门用于完成进程间通讯而设置的一个虚拟的设备。
BTW,说白了就是内核的提供的一个机制,这个和我们用socket加NET_LINK方式和内核通讯是一个道理。
static int open_driver(){int fd = open("/dev/binder", O_RDWR);//打开/dev/binderif (fd >= 0) {....size_t maxThreads = 15;//通过ioctl方式告诉内核,这个fd支持最大线程数是15个。
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads); } return fd;好了,到这里Process::self就分析完了,到底干什么了呢?●打开/dev/binder设备,这样的话就相当于和内核binder机制有了交互的通道●映射fd到内存,设备的fd传进去后,估计这块内存是和binder设备共享的接下来,就到调用defaultServiceManager()地方了。
2.2 defaultServiceManagerdefaultServiceManager位置在framework\base\libs\binder\IServiceManager.cpp中sp<IServiceManager> defaultServiceManager(){if (gDefaultServiceManager != NULL) return gDefaultServiceManager;//又是一个单例,设计模式中叫 singleton。
{AutoMutex _l(gDefaultServiceManagerLock);if (gDefaultServiceManager == NULL) {//真正的gDefaultServiceManager是在这里创建的喔gDefaultServiceManager = interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL));}}return gDefaultServiceManager;}-----》gDefaultServiceManager = interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL));ProcessState::self,肯定返回的是刚才创建的gProcess,然后调用它的getContextObject,注意,传进去的是NULL,即0//回到ProcessState类,sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller){if (supportsProcesses()) {//该函数根据打开设备是否成功来判断是否支持process,//在真机上肯定走这个return getStrongProxyForHandle(0);//注意,这里传入0}}----》进入到getStrongProxyForHandle,函数名字怪怪的,经常严重阻碍大脑运转//注意这个参数的命名,handle。
搞过windows的应该比较熟悉这个名字,这是对//资源的一种标示,其实说白了就是某个数据结构,保存在数组中,然后handle是它在这个数组中的索引。
--->就是这么一个玩意儿sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle){sp<IBinder> result;AutoMutex _l(mLock);handle_entry* e = lookupHandleLocked(handle);--》哈哈,果然,从数组中查找对应索引的资源,lookupHandleLocked这个就不说了,内部会返回一个handle_entry下面是 handle_entry 的结构/*struct handle_entry {IBinder* binder;--->BinderRefBase::weakref_type* refs;-->不知道是什么,不影响.};*/if (e != NULL) {IBinder* b = e->binder; -->第一次进来,肯定为空if (b == NULL || !e->refs->attemptIncWeak(this)) {b = new BpBinder(handle); --->看见了吧,创建了一个新的BpBindere->binder = b;result = b;}....}return result; 返回刚才创建的BpBinder。