完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
` 这一期我们来学习一下Android ServiceManager是如何来管理我们系统服务的。 ServiceManager服务是我们Android系统中的服务的一个程序,是Android系统中的核心服务之一。它主要有两个作用,第一是系统服务的管理,它用来管理系统和医用向系统添加的服务;第二个是处理查询获取服务的一个过程,比如我们的一个服务,要请求其他服务的话,那么这个ServiceManager就要响应我们一个client的请求,并且返回到client端所请求的相应服务。 下面我们再来看一下ServiceManager: 1.我们的ServiceManager是在init脚本中定义的启动的比较早的程序,如果我们这个程序连续几次异常退出的话,那么我们的系统就会重启,可见他也是一个很重要的服务 2.如果该服务重启,那么当重新启动ServiceManager的时候,我们需要重启我们的media服务、zygote服务、surfaceflinger服务。 3.如果系统中的某一个服务或者我们的应用需要调用其他的服务,那么我们必须使用ServiceManager它所提供的一种机制,才能真正的获取我们的服务。 下面我们来看一下我们init脚本中是如何来定义这个服务的,我们打开system/core/rootdir/init.rc,然后找到我们的ServiceManager服务 在这里定义了一个servicemanager的服务,他调用的其实是我们/system/bin/servicemanager这个程序,然后我们可以看到我们的class、user、group分别是core、system、system,还定义了一个关键字critical,这个的意思就是,如果说我们的服务连续挂掉几次,我们整个系统就会重启,如果我们的servicemanager出错了,需要重启的话,那么我们可以看到他会重新启动healthd、zygote、media等都要做一个重启,因为这些都是一个服务,他们都需要加载到servicemanager中,所以当servicemanager重启的时候,他们也会跟着重新启动。 下面我们来看一下servicemanager的启动过程,以及一个简单地实现原理 在这里会涉及到一个知识点,也就是我们的binder机制,binder机制是Android系统特有的一种进程间特有的通讯方式,我们在这里只需要知道这个servicemanager是基于binder机制的,当我们servicemanager启动的时候,首先他要去打开binder,然后映射了一段内存,这个内存是128*1024字节大小,然后通过一些设置,把他设置成context_manager,然后会进入到一个循环机制,去接收其他进程通过binder机制发送过来的消息,然后调用我们servicemanager的一个处理方式,也就是我们的svcmgr_handler,通过这个函数来处理其他进程发过来的binder消息,这些消息一般都是添加、查询、获取服务,在做这些的时候对我们的应用程序的一个权限做一个设置。 下面我们在代码中看一下,servicemanager是如何实现的,首先打开servicemanager的源代码,路径为:frameworks/native/cmds/servicemanager/servicemanager.c,找到他的main入口函数,进来之后首先打开binder机制,我们来看一下binder的实现。 他在这里直接打开dev/binder这个设备,然后做了一个映射,这个映射的内存就是我们刚才的128*1024,也就是128K,拿到句柄之后返回,然后做了一个binder_become_context_manager(bs)操作,这个操作就是将我们的binder设置为context_manager,这只碗之后就进入了一个binder_loop的函数,他就是不断接收其他binder机制发过来的消息,首先会读取消息,然后调用binder_parse来对我们的消息进行解析,我们来看一下这个函数 它所传进来的参数一个是我们的bs,一个是我们所读到的内容。进入这个函数之后他会根据我们的命令去做不同的操作,我们的命令是BR打头的一系列操作,最主要的是我们的BR_TRANSACTION,这个是我们主要处理的,处理之后他会调用一个回调函数,也就是我们刚才进binder_loop的时候传进来的那个函数,然后调用我们的回调函数做一些处理,处理完之后会调用binder_send_reply,也就是一个应用的请求一直到我们的servicemanager,servicemanager处理完之后再给他一个应答,这样就完成了一次进程间的交互。我们来看一下这个回调函数,看他是如何实现的 他首先会做一个处理,这个处理就是来看一下我们所传进来的svcmgr_id和我们传进来的s是否一致,如果不一致就直接返回了,svcmgr_id是一个字符串,内容是android.os.IServiceManager,如果和s一致的话,说明请求的是我们的servicemanager服务,在这里会处理下面几条主要的消息:第一个是get_service,第二个是check_service,第三个是add_service,第四个是list_service。在这里我们想要get或者check的话,首先会做一个do_find_service,我们先来看一下ADD_SERVICE 如果我们调用了这个函数,首先我们会发一个SVC_MGR_ADD_SERVICE我们进入do_add_service 在进入的时候首先会做一下判断,svc_can_register()就是看一下当前进程的uid是否有权限在这里做一些服务的注册,如果没有权限就直接返回了,如果有权限的话,那么就看一下当前的服务列表中有没有和我们名字一样的服务,如果有了就直接返回一个si,如果有这个si,那么就会把他重新置一下;如果没有的话他就会在我们的服务列表中重新添加一个服务。这就是servicemanager管理服务的一个过程。 接下来我们来看一下servicemanager处理消息的一个整个架构图 在这里主要涉及到三个部分,第一个是我们的应用程序包括其他的服务,这个主要是做getservice和addservice的一个操作。第二个就是我们的binder机制,我们中间的交互机制是通过我们的binder服务来实现的。第三个就是我们的service_manager,他用来管理和处理我们的请求。 如果我们要添加一个service,我们首先会向binder机制发送一个消息,在我们add过程中会添加一个相应的字段,这样我们binder就会找到我们相应的服务的进程,然后向我们相应的进程发送请求,这样我们的一个add消息就发送给我们的service_manager。,而service_manager拿到一个消息之后,首先会检查一下当前的请求的进程,他有没有我们添加服务的一个权限,如果有权限,他会继续检查列表中有没有这个服务,如果已经注册过了,就会把它重新添加过来,如果没有的话那么我们就会创建一个新的对象,新的结构,把这个对象添加进来,添加到我们服务列表中,这样我们服务列表中就会有一系列的服务,当我们添加完之后,如果说我们的一个应用程序,他需要请求这个服务,那么我们就发送一个getservice,这个消息之后还是找到我们的service_manager,然后调用我们getservice的处理方法,去我们服务列表中查询他所需要的服务,查找到这个服务之后,就会把相应的结构返回给我们的应用程序,这样我们的应用程序就会获取我们服务的一个操作权限,然后去调用这些服务的内容。我们这些服务的一些状态和信息也是实时更新的,这就是我们servicemanager管理服务的一个大概流程和大概的框架,以及他的一个实现原理。 ` |
|
相关推荐
1 个讨论
|
|
只有小组成员才能发言,加入小组>>
芯灵思SinlinxA33开发板Linux内核workqueue(附实测代码)
11864 浏览 0 评论
芯灵思SinlinxA33开发板Linux内核 tasklet 机制(附实测代码)
12521 浏览 0 评论
芯灵思Sinlinx A33开发板 Linux内核等待队列poll ---阻塞与非阻塞
34797 浏览 0 评论
芯灵思Sinlinx A33开发板Linux中断编程 3-应用程序
34728 浏览 0 评论
38813 浏览 0 评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-4 02:17 , Processed in 0.645193 second(s), Total 69, Slave 50 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号