Android ServiceManager启动

许久就想写篇关于servicemanager的文章，之前对服务启动顺序诸如zygote，systemserver。等启动顺序理解有点混乱，现做例如以下理解分析：

事实上init进程启动后，ServiceManager进程的启动。远比zygote要早。由于在启动zygote进程时须要用到ServiceManager进程的服务。

ServiceManager是一个守护进程，它维护着系统服务和client的binder通信。

在Android系统中用到最多的通信机制就是Binder，Binder主要由Client、Server、ServiceManager和Binder驱动程序组成。当中Client、Service和ServiceManager执行在用户空间，而Binder驱动程序执行在内核空间。核心组件就是 Binder驱动程序了。而ServiceManager提供辅助管理的功能。不管是Client还是Service进行通信前首先要和ServiceManager取得联系。而ServiceManager是一个守护进程，负责管理Server并向Client提供查询Server的功能。

init.rc中的声明

在init.rc中servicemanager是作为服务启动的。

service servicemanager /system/bin/servicemanager

  class core

  user system

  group system

  critical

  onrestart restart zygote

  onrestart restart media

  onrestart restart surfaceflinger

  onrestart restart drm

注意当中的“critical”字段，该字段非常重要。google官方文档对该字段的解释为：假设被该字段标识的service在4分钟内重新启动了4次，则系统会进入recovery界面。看其restart导致其它service的restart可见一斑。

servicemanager的main函数

源代码位置在frameworks/base/cmds/servicemanager/service_manager.c。android4.4源代码位于frameworks/native/cmds/servicemanager/service_manager.c, 它的main函数例如以下：

int main(int argc, char **argv)

{

  struct binder_state *bs;

  //宏：#define BINDER_SERVICE_MANAGER ((void*)0)。表示ServiceManager相应的句柄为0，表面自己是服务器管理者。

其它的Server进程句柄值都是大于0的。

  void *svcmgr = BINDER_SERVICE_MANAGER;

  //打开Binder设备。映射128K的内存地址空间

  bs = binder_open(128*1024);

  //告诉Binder驱动程序自己是Binder上下文管理者

  if (binder_become_context_manager(bs)) {

    ALOGE("cannot become context manager (%s)\n", strerror(errno));

    return -1;

  }

  //ServiceManager相应的句柄赋值

  svcmgr_handle = svcmgr;

  //进入一个无线循环，充当server角色，等待Client的请求

  binder_loop(bs, svcmgr_handler);

  return 0;

}

binder_open函数

binder_open(unsigned mapsize)函数源代码位置在frameworks/base/cmds/servicemanager/Binder.c

binder_open(unsigned mapsize)函数终于返回的类型为binder_state*，里面记录着刚刚打开的binder驱动文件句柄以及mmap()映射到的终于目标地址。

struct binder_state

 {

         int fd;   // 文件描写叙述符，打开的/dev/binder设备

         void* mapped;  // 把设备文件/dev/binder映射到进程空间的起始地址

         unsigned mapsize; // 映射内存空间的大小

 };

这个结构体也是在Binder.c中定义的。binder_open(unsigned mapsize)函数代码例如以下：

struct binder_state *binder_open(unsigned mapsize)

{

  struct binder_state *bs;

  bs = malloc(sizeof(*bs));

  if (!bs) {

    errno = ENOMEM;

    return 0;

  }

  //打开/dev/binder驱动文件

  bs->fd = open("/dev/binder", O_RDWR);

  if (bs->fd < 0) {

    fprintf(stderr,"binder: cannot open device (%s)\n",

        strerror(errno));

    goto fail_open;

  }

  //设置要映射的空间大小128*1024

  bs->mapsize = mapsize;

  //開始映射

  bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);

  if (bs->mapped == MAP_FAILED) {

    fprintf(stderr,"binder: cannot map device (%s)\n",

        strerror(errno));

    goto fail_map;

  }

    /* TODO: check version */

  return bs;

fail_map:

  close(bs->fd);

fail_open:

  free(bs);

  return 0;

}

參数mapsize表示它希望把binder驱动文件的多少字节映射到本地空间。能够看到。Service Manager Service和普通进程所映射的binder大小并不同样。它把binder驱动文件的128K字节映射到内存空间，而普通进程则会映射binder文件里的BINDER_VM_SIZE（即1M减去8K）字节。详细的映射动作由mmap()一句完毕。该函数将binder驱动文件的一部分映射到进程空间。

mmap()的函数原型例如以下：

void* mmap ( void * addr , size_t len , int prot , int flags , int fd , off_t offset );

參数addr用于指出文件应被映射到进程空间的起始地址，一般指定为空指针，此时会由内核来决定起始地址。

參数len为映射的字节长度。

參数prot表明对这段映射空间的訪问权限。能够是PROT_READ（可读）、PROT_WRITE（可写）、PROT_EXEC（可运行）、PROT_NONE（不可訪问）。

參数fd要被映射的binder驱动文件。

參数offset是偏移量的起始位置。

binder_become_context_manager函数

binder_become_context_manager(struct binder_state
*bs)函数源代码位置在frameworks/base/cmds/servicemanager/Binder.c

此函数作用是让当前进程成为整个系统中唯一的上下文管理器，即 service管理器。其代码很easy，不过把BINDER_SET_CONTEXT_MGR发送到binder驱动而已。源代码例如以下：

int binder_become_context_manager(struct binder_state *bs)

{

    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);

}

binder_loop(struct binder_state *bs, binder_handler func)函数

binder_loop(struct binder_state *bs, binder_handler func)函数源代码位置在frameworks/base/cmds/servicemanager/Binder.c。

此时已经正式进入循环，转正为一个server。注意这个函数的參数：bs是文件/dev/binder的描写叙述符。func是函数svcmgr_handler。

void binder_loop(struct binder_state *bs, binder_handler func)

{

  int res;

  struct binder_write_read bwr;

  unsigned readbuf[32];

  bwr.write_size = 0;

  bwr.write_consumed = 0;

  bwr.write_buffer = 0;

  readbuf[0] = BC_ENTER_LOOPER;

  binder_write(bs, readbuf, sizeof(unsigned));

  for (;;) {

    bwr.read_size = sizeof(readbuf);

    bwr.read_consumed = 0;

    bwr.read_buffer = (unsigned) readbuf;

  //通过设备描写叙述符。将数据发给binder驱动

    res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);

    if (res < 0) {

      ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));

      break;

    }

     //解析驱动的数据，调用回调函数func

    res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);

    if (res == 0) {

      ALOGE("binder_loop: unexpected reply?

!\n");

      break;

    }

    if (res < 0) {

      ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));

      break;

    }

  }

}

binder_parse函数

这个函数源代码位置在frameworks/base/cmds/servicemanager/Binder.c

这个函数主要是对binder文件解析并运行对应的指令。

这个函数的大头事实上就是那个一路传过来的svcmgr_handler函数，就是那个參数func。

int binder_parse(struct binder_state *bs, struct binder_io *bio,

         uint32_t *ptr, uint32_t size, binder_handler func)

{

  int r = 1;

  uint32_t *end = ptr + (size / 4);

  while (ptr < end) {

    uint32_t cmd = *ptr++;

    ...

    //注意这个BR_TRANSACTION

    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 -1;

      }

      binder_dump_txn(txn);

      if (func) {

        unsigned rdata[256/4];

        struct binder_io msg;

        struct binder_io reply;

        int res;

        bio_init(&reply, rdata, sizeof(rdata), 4);

        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;

    }

   ...

  }

  return r;

}

svcmgr_handler函数

这个函数源代码位置在frameworks/base/cmds/servicemanager/service_manager.c

int svcmgr_handler(struct binder_state *bs,

           struct binder_txn *txn,

           struct binder_io *msg,

           struct binder_io *reply)

{

 ...

  switch(txn->code) {

  //client获取服务的请求

  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 0;

  //服务端请求加入服务

  case SVC_MGR_ADD_SERVICE:

    s = bio_get_string16(msg, &len);

    ptr = bio_get_ref(msg);

    allow_isolated = bio_get_uint32(msg) ?

1 : 0;

    if (do_add_service(bs, s, len, ptr, txn->sender_euid, allow_isolated))

      return -1;

    break;

...

  }

  bio_put_uint32(reply, 0);

  return 0;

}

svclist链表

service_manager.c中声明了一个链表svclist

struct svcinfo *svclist = 0;

svclist记录着全部加入进系统的“service代理”信息。这些信息被组织成一条单向链表。svclist链表节点类型为svcinfo，例如以下：

struct svcinfo

{

  struct svcinfo *next;

  void *ptr;//记录的就是系统service相应的 binder句柄值

  struct binder_death death;

  int allow_isolated;

  unsigned len;

  uint16_t name[0];//系统服务的名称

};

当应用调用getService()获取系统服务的代理接口时，servicemanager就会搜索这张svclist链表，以下就要介绍。

do_add_service函数

这个函数源代码位置在frameworks/base/cmds/servicemanager/service_manager.c

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 == 0) || (len > 127))

     return -1;

    //查看该服务是否有注冊权限

    if (!svc_can_register(uid, s)) {

     ALOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",

       str8(s), ptr, uid);

     return -1;

    }

    //在服务列表中查找服务

    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 {

    //假设没有注冊。则创建一个，并加入到svclist服务列表的表首。

si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));

     if (!si) {

      ALOGE("add_service('%s',%p) uid=%d - OUT OF MEMORY\n",

        str8(s), ptr, uid);

      return -1;

     }

     si->ptr = ptr;

     si->len = len;

     memcpy(si->name, s, (len + 1) * 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设备有一个service注冊进来。

    binder_acquire(bs, ptr);

    binder_link_to_death(bs, ptr, &si->death);

    return 0;

}

do_find_service函数

这个函数源代码位置在frameworks/base/cmds/servicemanager/service_manager.c

void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len, unsigned uid)

{

  struct svcinfo *si;

  //上一个函数也调用了这个函数

  si = find_svc(s, len);

//	ALOGI("check_service('%s') ptr = %p\n", str8(s), si ? si->ptr : 0);

  if (si && si->ptr) {

    if (!si->allow_isolated) {

      // If this service doesn't allow access from isolated processes,

      // then check the uid to see if it is isolated.

      unsigned appid = uid % AID_USER;

      if (appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END) {

        return 0;

      }

    }

    return si->ptr;

  } else {

    return 0;

  }

find_svc函数

这个函数源代码位置在frameworks/base/cmds/servicemanager/service_manager.c

struct svcinfo *find_svc(uint16_t *s16, unsigned len)

{

  struct svcinfo *si;

  //遍历svclist，查找服务

  for (si = svclist; si; si = si->next) {

    if ((len == si->len) &&

      !memcmp(s16, si->name, len * sizeof(uint16_t))) {

      return si;

    }

  }

  return 0;

}

总结

一，android系统的service相对重要的几个比方：uevent，healthd，zygote等都是由init直接启动的，兴许一些常规的service都是在zygote fork完systemserver进程后，逐一通过servicemanager加入的。

二，守护进程servicemanager循环从binder设备文件读取数据。然后解析并响应请求，包含服务端的加入服务请求和client的查询，获取服务的请求。

巴特西

Android ServiceManager启动

init.rc中的声明

servicemanager的main函数

binder_open函数

binder_become_context_manager函数

binder_parse函数

svcmgr_handler函数

svclist链表

do_add_service函数

do_find_service函数

find_svc函数

总结

最新文章

热门文章