Bind机制由4个部分组成。bind驱动,Client,ServiceManager &Service

1.Bind其实是一个基于linux系统的驱动,目的是为了实现内存共享。

bind驱动的东西,由于偏向内核,并且bind机制的内容非常庞大,所以我们暂时略去这个部分。

2.ServiceManager

Service Manager顾名思义,是一个“管家”。更确切的说,是所有系统service 的manager。

首先从service_manager.c开始\frameworks\native\cmds\servicemanager\service_manager.c

static struct {
unsigned uid;
const char *name;
} allowed[] = {
{ AID_MEDIA, "media.audio_flinger" },
{ AID_MEDIA, "media.log" },
{ AID_MEDIA, "media.player" },
{ AID_MEDIA, "media.camera" },
{ AID_MEDIA, "media.audio_policy" },
{ AID_DRM, "drm.drmManager" },
{ AID_NFC, "nfc" },
{ AID_BLUETOOTH, "bluetooth" },
{ AID_RADIO, "radio.phone" },
{ AID_RADIO, "radio.sms" },
{ AID_RADIO, "radio.phonesubinfo" },
{ AID_RADIO, "radio.simphonebook" },
/* TODO: remove after phone services are updated: */
{ AID_RADIO, "phone" },
{ AID_RADIO, "sip" },
{ AID_RADIO, "isms" },
{ AID_RADIO, "iphonesubinfo" },
{ AID_RADIO, "simphonebook" },
{ AID_MEDIA, "common_time.clock" },
{ AID_MEDIA, "common_time.config" },
{ AID_KEYSTORE, "android.security.keystore" },
};

以上就是系统服务的一个部分。这些都是注册在servicemanager来管理。

那service manager干那些事:

I.提供IBind对象,也就是各个service的引用,供每个进程使用,且对于每个进程来说,该Ibind对象是唯一的。

II.让各个系统service注册到servicemanager中。

这里binder驱动,不是我们通常操作系统结构里的驱动概念,可以理解为是client和ServiceManager交流的媒介。

binder驱动的本质是内存共享。

其实这是整个bind机制的前面部分,就是从client到servicemanager,这样client可以拿到Ibind对象,进而可以直接“操作servie”。

举个例子:

AlarmManager alarmManager = context.getSystemService(Context.ALARM_SERVICE);
alarmManager.setExact(AlarmManager.ELAPSED_REALTIME, elapsedRealtime,
pendingIntent);

拿到alaram service bind对象,进而操作service提供的“服务”。

而且这个操作是同步的!

就好象在操作同一个进程的东西。

下面我们看看service Manager究竟是如何做到上面说的几点的。

2.1 Service Manager的启动:

既然SM是管理员,那么它应该是最勤快的,也就是必须最“早”启动。

是的,它的启动是定义在init.rc里面的:\system\core\rootdir\init.rc

# adbd on at boot in emulator
on property:ro.kernel.qemu=
start adbd service servicemanager /system/bin/servicemanager
class core
user system
group system
critical
onrestart restart healthd
onrestart restart zygote
onrestart restart media
onrestart restart surfaceflinger
onrestart restart drm

Service Manager启动后,在干什么?

还是在service_manager.c中:

int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER; bs = binder_open(*); if (binder_become_context_manager(bs)) {
ALOGE("cannot become context manager (%s)\n", strerror(errno));
return -;
} svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return ;
}

binder_open打开bind驱动,并且分配128K大小。

binder_become_context_manager(bs):

int binder_become_context_manager(struct binder_state *bs)
{
return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, );
}

把自己注册为Service 大管家。

void binder_loop(struct binder_state *bs, binder_handler func)
{
int res;
struct binder_write_read bwr;
unsigned readbuf[]; bwr.write_size = ;
bwr.write_consumed = ;
bwr.write_buffer = ; readbuf[] = BC_ENTER_LOOPER;
binder_write(bs, readbuf, sizeof(unsigned)); for (;;) {
bwr.read_size = sizeof(readbuf);
bwr.read_consumed = ;
bwr.read_buffer = (unsigned) readbuf; res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); if (res < ) {
ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
break;
} res = binder_parse(bs, , readbuf, bwr.read_consumed, func);
if (res == ) {
ALOGE("binder_loop: unexpected reply?!\n");
break;
}
if (res < ) {
ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
break;
}
}
}

开始进入loop,和之前分析的andorid线程消息驱动机制非常相似。

读取消息队列,解析它们,知道出现异常。

接下来,看看bind_parse:

int binder_parse(struct binder_state *bs, struct binder_io *bio,
uint32_t *ptr, uint32_t size, binder_handler func)
{
int r = ;
uint32_t *end = ptr + (size / ); while (ptr < end) {
uint32_t cmd = *ptr++;
#if TRACE
fprintf(stderr,"%s:\n", cmd_name(cmd));
#endif
switch(cmd) {
case BR_NOOP:
break;
case BR_TRANSACTION_COMPLETE:
break;
case BR_INCREFS:
case BR_ACQUIRE:
case BR_RELEASE:
case BR_DECREFS:
#if TRACE
fprintf(stderr," %08x %08x\n", ptr[], ptr[]);
#endif
ptr += ;
break;
case BR_TRANSACTION: {
struct binder_txn *txn = (void *) ptr;
if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
ALOGE("parse: txn too small!\n");
return -;
}
binder_dump_txn(txn);
if (func) {
unsigned rdata[/];
struct binder_io msg;
struct binder_io reply;
int res; bio_init(&reply, rdata, sizeof(rdata), );
bio_init_from_txn(&msg, txn);
res = func(bs, txn, &msg, &reply);
binder_send_reply(bs, &reply, txn->data, res);
}
ptr += sizeof(*txn) / sizeof(uint32_t);
break;
}
case BR_REPLY: {
struct binder_txn *txn = (void*) ptr;
if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
ALOGE("parse: reply too small!\n");
return -;
}
binder_dump_txn(txn);
if (bio) {
bio_init_from_txn(bio, txn);
bio = ;
} else {
/* todo FREE BUFFER */
}
ptr += (sizeof(*txn) / sizeof(uint32_t));
r = ;
break;
}
case BR_DEAD_BINDER: {
struct binder_death *death = (void*) *ptr++;
death->func(bs, death->ptr);
break;
}
case BR_FAILED_REPLY:
r = -;
break;
case BR_DEAD_REPLY:
r = -;
break;
default:
ALOGE("parse: OOPS %d\n", cmd);
return -;
}
} return r;
}

关键是分析:BR_TRANSACTION,BR_REPLY。

BR_TRANSACTION中做了一些初始化,然后

res = func(bs, txn, &msg, &reply);
binder_send_reply(bs, &reply, txn->data, res);

func函数就是在service_manager.c中传入的

int svcmgr_handler(struct binder_state *bs,
struct binder_txn *txn,
struct binder_io *msg,
struct binder_io *reply)

所以bind_loop最终实现分析的函数是传入的函数!

至此整个service_manager的流程已经清楚。

事件驱动机制:

1.从bind驱动读取消息

2.处理消息

3.进入looper,永远不会主动退出,直到出现致命错误。

int svcmgr_handler(struct binder_state *bs,
struct binder_txn *txn,
struct binder_io *msg,
struct binder_io *reply)
{
struct svcinfo *si;
uint16_t *s;
unsigned len;
void *ptr;
uint32_t strict_policy;
int allow_isolated; // ALOGI("target=%p code=%d pid=%d uid=%d\n",
// txn->target, txn->code, txn->sender_pid, txn->sender_euid); if (txn->target != svcmgr_handle)
return -; // Equivalent to Parcel::enforceInterface(), reading the RPC
// header with the strict mode policy mask and the interface name.
// Note that we ignore the strict_policy and don't propagate it
// further (since we do no outbound RPCs anyway).
strict_policy = bio_get_uint32(msg);
s = bio_get_string16(msg, &len);
if ((len != (sizeof(svcmgr_id) / )) ||
memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
fprintf(stderr,"invalid id %s\n", str8(s));
return -;
} switch(txn->code) {
case SVC_MGR_GET_SERVICE:
case SVC_MGR_CHECK_SERVICE:
s = bio_get_string16(msg, &len);
ptr = do_find_service(bs, s, len, txn->sender_euid);
if (!ptr)
break;
bio_put_ref(reply, ptr);
return ; case SVC_MGR_ADD_SERVICE:
s = bio_get_string16(msg, &len);
ptr = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? : ;
if (do_add_service(bs, s, len, ptr, txn->sender_euid, allow_isolated))
return -;
break; case SVC_MGR_LIST_SERVICES: {
unsigned n = bio_get_uint32(msg); si = svclist;
while ((n-- > ) && si)
si = si->next;
if (si) {
bio_put_string16(reply, si->name);
return ;
}
return -;
}
default:
ALOGE("unknown code %d\n", txn->code);
return -;
} bio_put_uint32(reply, );
return ;
}

svcmgr_handler

switch语句,查询和获取service 或者注册。

查找svclist里面是否有相同name的服务。

svclist是链表的方式,与线程的消息队列一样!

struct svcinfo *find_svc(uint16_t *s16, unsigned len)
{
struct svcinfo *si; for (si = svclist; si; si = si->next) {
if ((len == si->len) &&
!memcmp(s16, si->name, len * sizeof(uint16_t))) {
return si;
}
}
return ;
}

接下来我们看看void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len, unsigned uid)

return的到底是什么?

注册服务:SVC_MGR_ADD_SERVICE:

int do_add_service(struct binder_state *bs,
uint16_t *s, unsigned len,
void *ptr, unsigned uid, int allow_isolated)
{
struct svcinfo *si;
//ALOGI("add_service('%s',%p,%s) uid=%d\n", str8(s), ptr,
// allow_isolated ? "allow_isolated" : "!allow_isolated", uid); if (!ptr || (len == ) || (len > ))
return -; if (!svc_can_register(uid, s)) {
ALOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",
str8(s), ptr, uid);
return -;
} si = find_svc(s, len);
if (si) {
if (si->ptr) {
ALOGE("add_service('%s',%p) uid=%d - ALREADY REGISTERED, OVERRIDE\n",
str8(s), ptr, uid);
svcinfo_death(bs, si);
}
si->ptr = ptr;
} else {
si = malloc(sizeof(*si) + (len + ) * sizeof(uint16_t));
if (!si) {
ALOGE("add_service('%s',%p) uid=%d - OUT OF MEMORY\n",
str8(s), ptr, uid);
return -;
}
si->ptr = ptr;
si->len = len;
memcpy(si->name, s, (len + ) * sizeof(uint16_t));
si->name[len] = '\0';
si->death.func = svcinfo_death;
si->death.ptr = si;
si->allow_isolated = allow_isolated;
si->next = svclist;
svclist = si;
} binder_acquire(bs, ptr);
binder_link_to_death(bs, ptr, &si->death);
return ;
}

do_add_service

int svc_can_register(unsigned uid, uint16_t *name)

判断是否在allowed表格里面。

先看看是否在列表里面?

si = find_svc(s, len);

如果不再的话,就注册一个新的si,到svclist。

至此service_manager就启动起来了。

android 进程间通信---Service Manager(1)的更多相关文章

  1. android 进程间通信---Service Manager(2)

    关于servicemanager的设计: 还是这张结构图,由于ProcessState & IPCThreadState是与binder deriver交互的, 所以对于client端来说Bp ...

  2. Android 进程间通信——Service、Messenger

    概述 介绍绑定服务端的三种方式:同一进程绑定服务.跨进程绑定服务(Messenger).跨进程绑定服务(aidl). 重点说一下通过Messenger.Service实现的进程间通信. 详细 代码下载 ...

  3. Service Manager流程,派BC_REPLY,唤醒FregServer流程,返回BR_TRANSACTION_COMPLETE,睡眠等待proc-&gt;wait

    本文參考<Android系统源代码情景分析>,作者罗升阳 一.service manager代码:        -/Android/frameworks/base/cmd/service ...

  4. 浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6627260 在前面一篇文章浅谈Service ...

  5. 浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6621566 上一篇文章Android进程间通信 ...

  6. Android 核心分析 之六 IPC框架分析 Binder,Service,Service manager

    IPC框架分析 Binder,Service,Service manager 我首先从宏观的角度观察Binder,Service,Service Manager,并阐述各自的概念.从Linux的概念空 ...

  7. android 进程间通信---bind的前世

    在分析bind机制之前,我发现已经有一篇文章讲解的非常清晰,并且提出了很多问题. 地址:http://my.oschina.net/keeponmoving/blog/64218 一.Linux系统进 ...

  8. Android进程间通信(IPC)机制Binder简要介绍和学习计划

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6618363 在Android系统中,每一个应用 ...

  9. Android进程间通信(IPC)机制Binder简介和学习计划

    在Android系统,每个应用程序是由多个Activity和Service部件,这些Activity和Service有可能在相同的处理被执行,此外,还可以在不同的过程中进行. 然后.不是在同一个过程A ...

随机推荐

  1. Breach - HTML5 时代,基于 JS 编写的浏览器

    Breach 是一款属于 HTML5 时代的开源浏览器项目,,完全用 Javascript 编写的.免费.模块化.易于扩展.这个浏览器中的一切都是模块,Web 应用程序在其自己的进程运行.通过选择合适 ...

  2. .Net魔法堂:史上最全的ActiveX开发教程——部署篇

    一.前言 接<.Net魔法堂:史上最全的ActiveX开发教程——发布篇>,后我们继续来部署吧! 二. 挽起衣袖来部署   ActiveX的部署其实就是客户端安装ActiveX组件,对未签 ...

  3. hive的内部表与外部表创建

    最近才接触Hive.学到了一些东西,就先记下来,免得以后忘了. 1.创建表的语句:Create [EXTERNAL] TABLE [IF NOT EXISTS] table_name [(col_na ...

  4. Sprint第三个冲刺(第三天)

    一.Sprint介绍 任务进度: 二.Sprint周期 看板: 燃尽图:

  5. eclipse中去掉Js/javsscript报错信息

    1.首先在problem>errors中删除所有js错误: 如下图 2.然后再勾选掉javascript Validator: 3.clean下项目吧,你会发现再也不出现js红叉叉了,哈哈.

  6. [C/C++][文件操作] 对比目录并列出同名较新文件、较旧文件 0.1

    主要是模仿robocopy的部分功能 (robocopy /L 参数可以列出本地目录和备份目录中的异同之处,主要是标记出:较新的.较旧的.多出的文件 ) 现在还不会写GUI,打算后面自己做目录树dif ...

  7. Use the PDFs below or the HTML contents to the left to install and configure P6 EPPM and its additional components.

    Welcome to Your Documentation   Use the PDFs below or the HTML contents to the left to install and c ...

  8. Sql发布订阅设置不初始化订阅库架构的设置

    参考:http://www.cnblogs.com/TeyGao/p/3521231.html

  9. Access数据库的常用数据类型和alter的用法

    一.Access比较常用的数据类型:文本.备注.数字.日期/时间.货币 意思          Sql                    Access 1)文本      nvarchar(30) ...

  10. 重新想象 Windows 8 Store Apps (35) - 通知: Toast 详解

    [源码下载] 重新想象 Windows 8 Store Apps (35) - 通知: Toast 详解 作者:webabcd 介绍重新想象 Windows 8 Store Apps 之 通知 Toa ...