Android Framework 之启动 ServiceManager

最新推荐文章于 2023-08-10 14:40:37 发布

小陈乱敲代码

最新推荐文章于 2023-08-10 14:40:37 发布

阅读量229

点赞数

分类专栏： Android framework 文章标签： android

本文链接：https://blog.csdn.net/zzz777qqq/article/details/128643577

版权

Android framework 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

阅读须知

本文源码基于 Android 10，涉及相关源码如下。

system/core/
    - init/init.cpp
    - rootdir/init.rc
    
frameworks/native/cmds/servicemanager/
    - Android.bp
    - binder.c
    - service_manager.c
    - servicemanager.rc

概述

ServiceManagaer 是 Binder 的守护进程，在 Binder 机制中起着重要的作用。本文将从源码的角度对其进行分析，整体流程如下：

ServiceManager 的启动；
打开 Binder 驱动；
设置上下文管理者；
进入循环。

image.png

时序图如下。

image.png

1. ServiceManager 的启动

先来看看 ServiceManager 是如何启动的：

init 进程解析 init.rc，触发 trigger init；
执行 start servicemanager 启动 ServiceManager。

image.png

1.1 触发 trigger init

在 Zygote 一文中说过，init 进程启动的第二阶段会解析 init.rc 文件。

在这之后会触发 trigger init。

// system/core/init/init.cpp

int SecondStageMain(int argc, char** argv) {
    // 解析 init.rc 文件
    LoadBootScripts(am, sm);
    // 触发 trigger init
    am.QueueEventTrigger("init");
}

结合 init.rc 看看 action init 做了什么。

# system/core/rootdir/init.rc

on init
    # 启动 service servicemanager 
    start servicemanager

1.2 启动 ServiceManager

当触发 trigger init 后，会启动 servicemanager 服务，其声明如下。

# frameworks/native/cmds/servicemanager/servicemanager.rc

# 对应执行的文件为 /system/bin/servicemanager
service servicemanager /system/bin/servicemanager
    class core animation
    user system
    group system readproc
    critical
    # 当 servicemanager 重启的时候会重启下列服务
    onrestart restart healthd
    onrestart restart zygote
    onrestart restart audioserver
    onrestart restart media
    onrestart restart surfaceflinger
    onrestart restart inputflinger
    onrestart restart drm
    onrestart restart cameraserver
    onrestart restart keystore
    onrestart restart gatekeeperd
    onrestart restart thermalservice
    writepid /dev/cpuset/system-background/tasks
    shutdown critical

对应的执行文件为 /system/bin/servicemanager，在编译前位于 frameworks/native/cmds/servicemanager 下，来看看 Android.bp。

// frameworks/native/cmds/servicemanager/Android.bp

cc_binary {
    name: "servicemanager",
    srcs: [
        "service_manager.c",
        "binder.c",
    ],
    init_rc: ["servicemanager.rc"],
}

其对应的源码为 service_manager.c 和 binder.c，入口函数 main() 位于 servicemanager.c。

2. 打开 Binder 驱动

启动完 ServiceManager 后会打开 Binder 驱动。

image.png

在 main() 中首先调用 binder_open()。

// frameworks/native/cmds/servicemanager/service_manager.c

int main(int argc, char** argv)
{
    char *driver;
    driver = "/dev/binder";
    // 调用 binder_open() 打开 binder 驱动，并申请 128 kb 内存
    bs = binder_open(driver, 128*1024);
}

```java

`binder_open()` 主要做了如下事情：

1.  初始化结构体 `binder_state`；
2.  系统调用 `open()` 打开 `/dev/binder`，获得文件描述符 `fd`；
3.  系统调用 `ioctl()` 获取 `binder` 版本并做版本比对；
4.  系统调用 `mmap()` 内存映射 128kb 的空间供 `ServiceManager` 使用。

2.1 初始化 binder\_state
---------------------

给结构体 `binder_state` 分配内存。

```java
// frameworks/native/cmds/servicemanager/binder.c

struct binder_state
{
    // 打开 binder 驱动获取的文件描述符
    int fd;
    // 指向 mmap() 内存映射地址
    void *mapped;
    // 映射内存大小
    size_t mapsize;
};

struct binder_state *binder_open(const char* driver, size_t mapsize)
{
    struct binder_state *bs;
    // 给 bs 分配内存
    bs = malloc(sizeof(*bs));
    if (!bs) {
        return NULL;
    }
}

2.2 打开 Binder 驱动

系统调用 open() 打开 /dev/binder，如果打开驱动失败，则执行 fail_open 释放内存。

// frameworks/native/cmds/servicemanager/binder.c

struct binder_state *binder_open(const char* driver, size_t mapsize)
{
    // 调用 open() 打开 binder 驱动
    bs->fd = open(driver, O_RDWR | O_CLOEXEC);
    if (bs->fd < 0) {
        goto fail_open;
    }
    
fail_open:
    // 释放 bs 内存
    free(bs);
    return NULL;
}

简单的解释一下什么是系统调用？

由于需要限制不同的程序之间的访问能力，防止程序获取别的程序的内存数据，CPU 划分出两个权限等级，用户态 和 内核态。

用户态 只能受限的访问内存，不允许访问外围设备，占用 CPU 的能力被剥削，CPU 资源可以被其他程序获取
内核态 可以访问内存所有数据，包括外围设备，CPU 可以将自己从一个程序切换到另外一个程序

所有的用户程序都是运行在用户态，但有时需要做一些内核态的事情，而唯一可以做这些事情的就是操作系统，所以程序需要向操作系统发起请求，以程序的名字来执行这些操作。这时就需要一个从用户态切换到内核态但不能控制内核态中执行的机制，这种机制就是 系统调用。

2.3 检查 Binder 版本

系统调用 ioctl() 传入 BINDER_VERSION 命令获取 Binder 驱动版本，对比版本是否一致，不一致则执行 fail_open 释放内存。

// frameworks/native/cmds/servicemanager/binder.c

struct binder_state *binder_open(const char* driver, size_t mapsize)
{
    struct binder_version vers;
    // 调用 ioctl() 获取 Binder 版本
    if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
        (vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
        goto fail_open;
    }
fail_open:
    // 释放 bs 内存
    free(bs);
    return NULL;
}

2.4 内存映射

系统调用 mmap() 映射 128kb 的内存空间，即把 Binder 驱动文件的 128kb 映射到内存空间供 ServiceManager 使用，内存映射失败则执行 fail_map，关闭 fd 并释放内存。

// frameworks/native/cmds/servicemanager/binder.c

struct binder_state *binder_open(const char* driver, size_t mapsize)
{
    bs->mapsize = mapsize;
    // 调用 mmap() 做内存映射
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
    if (bs->mapped == MAP_FAILED) {
        goto fail_map;
    }
    return bs;
fail_map:
    // 关闭 fd
    close(bs->fd);
fail_open:
    // 释放 bs 内存
    free(bs);
    return NULL;
}

ServiceManager 进程 mmap 的内存大小可以通过 adb shell 命令查看。

$ ps -eT | grep servicemanager
$ cat /proc/1653/maps

image.png

可以看到内存映射地址为 0xf10f8000 ~ 0xf1118000，差为 0x20000 即十进制的 128kb。

3. 设置上下文管理者

打开 Binder 驱动后会将 ServiceManager 设置为上下文管理者。

image.png

调用 binder_become_context_manager()。

// frameworks/native/cmds/servicemanager/service_manager.c

int main(int argc, char** argv)
{
    // 成为 context manager
    if (binder_become_context_manager(bs)) {
        return -1;
    }
}

// frameworks/native/cmds/servicemanager/binder.c

int binder_become_context_manager(struct binder_state *bs)
{
    struct flat_binder_object obj;
    memset(&obj, 0, sizeof(obj));
    obj.flags = FLAT_BINDER_FLAG_TXN_SECURITY_CTX;
    // 系统调用 ioctl() 传入 BINDER_SET_CONTEXT_MGR_EXT 设置安全的上下文管理者
    int result = ioctl(bs->fd, BINDER_SET_CONTEXT_MGR_EXT, &obj);

    if (result != 0) {
        // 失败则传入 BINDER_SET_CONTEXT_MGR 设置上下文管理者
        result = ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
    }
    return result;
}

android 10 新增 BINDER_SET_CONTEXT_MGR_EXT 命令来设置安全的上下文管理者，如果设置失败，则使用原有的 BINDER_SET_CONTEXT_MGR 命令来设置上下文管理者，两者区别在于是否携带参数。

4. 进入循环

最后会进入循环，从 Binder 驱动读取和解析数据。

image.png

调用 binder_loop() 进入循环，不断地通过系统调用 ioctl() 从 Binder 驱动读取数据，并通过 binder_parse() 进行数据解析。

// frameworks/native/cmds/servicemanager/service_manager.c

int main(int argc, char** argv)
{
    // 调用 binder_loop() 进入循环，注意这里的
    binder_loop(bs, svcmgr_handler);
}

// frameworks/native/cmds/servicemanager/binder.c

void binder_loop(struct binder_state *bs, binder_handler func)
{
    int res;
    struct binder_write_read bwr;
    // 128kb 的缓存区
    uint32_t readbuf[32];
    
    // 写入 BC_ENTER_LOOPER 命令通知 binder 驱动即将进入循环
    readbuf[0] = BC_ENTER_LOOPER;
    binder_write(bs, readbuf, sizeof(uint32_t));

    for (;;) {
        bwr.read_size = sizeof(readbuf);
        bwr.read_consumed = 0;
        bwr.read_buffer = (uintptr_t) readbuf;
        // 系统调用 ioctl() 读取 binder 驱动传递的数据放到 readbuf
        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
        // 调用 binder_parse() 解析数据
        res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
    }
}

注意这里调用 binder_loop() 传入的 svcmgr_handler()，后面会使用到。

4.1 binder_write()

binder_write() 会封装 struct binder_write_read，并通过系统调用 ioctl() 将对应的命令传递给 Binder 驱动。

// frameworks/native/cmds/servicemanager/binder.c

int binder_write(struct binder_state *bs, void *data, size_t len)
{
    struct binder_write_read bwr;
    int res;
    // 封装写入数据
    bwr.write_size = len;
    bwr.write_consumed = 0;
    bwr.write_buffer = (uintptr_t) data;
    // 清除读取数据
    bwr.read_size = 0;
    bwr.read_consumed = 0;
    bwr.read_buffer = 0;
    // 系统调用 ioctl() 传入 BINDER_WRITE_READ 命令表示进行读写操作
    res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    return res;
}

4.2 binder_parse()

binder_parse() 用来解析从 Binder 驱动读取到的数据，然后根据不同的命令执行对应的操作。

// frameworks/native/cmds/servicemanager/binder.c

int binder_parse(struct binder_state *bs, struct binder_io *bio,
                 uintptr_t ptr, size_t size, binder_handler func)
{
    int r = 1;
    uintptr_t end = ptr + (uintptr_t) size;
    // whilte 循环读取处理命令，可能存在多个命令
    while (ptr < end) {
        // 读取命令，命令占用 readbuf 的 4 个字节
        uint32_t cmd = *(uint32_t *) ptr;
        ptr += sizeof(uint32_t);
        // 根据命令做对应的操作
        switch(cmd) {
        case BR_NOOP:
            break;
        case BR_TRANSACTION_COMPLETE:
            break;
        case BR_INCREFS:
        case BR_ACQUIRE:
        case BR_RELEASE:
        case BR_DECREFS:
            break;
        case BR_TRANSACTION_SEC_CTX:
        case BR_TRANSACTION:
            break;
        case BR_REPLY: 
            break;
        case BR_DEAD_BINDER:
            break;
        case BR_FAILED_REPLY:
            break;
        case BR_DEAD_REPLY:
            break;
        default:
            return -1;
        }
    }

    return r;
}

因为 cmd 命令可能有多个，所以通过 while 循环每次处理一个 cmd 命令，多 cmd 的结构大致如下图所示。

image.png

这里重点看下 BR_TRANSACTION 命令。

4.2.1 BR_TRANSACTION

BR_TRANSACTION 是 Binder 驱动向 Server 端发送请求数据。

// frameworks/native/cmds/servicemanager/binder.c

int binder_parse(struct binder_state *bs, struct binder_io *bio,
                 uintptr_t ptr, size_t size, binder_handler func)
{
    switch(cmd) {
    case BR_TRANSACTION_SEC_CTX:
    case BR_TRANSACTION: {
        struct binder_transaction_data_secctx txn;
        // BR_TRANSACTION_SEC_CTX
        if (cmd == BR_TRANSACTION_SEC_CTX) {
            // 拷贝 binder_transaction_data_secctx 到 transaction_data
            memcpy(&txn, (void*) ptr, sizeof(struct binder_transaction_data_secctx));
            ptr += sizeof(struct binder_transaction_data_secctx);
        } else /* BR_TRANSACTION */ {
            // 拷贝 binder_transaction_data 到 transaction_data
            memcpy(&txn.transaction_data, (void*) ptr, sizeof(struct binder_transaction_data));
            ptr += sizeof(struct binder_transaction_data);
            txn.secctx = 0;
        }

        if (func) {
            unsigned rdata[256/4];
            struct binder_io msg;
            struct binder_io reply;
            int res;

            // reply 初始化
            bio_init(&reply, rdata, sizeof(rdata), 4);
            // 从 txn.transaction_data 解析出 binder_io 的信息，存入 msg
            bio_init_from_txn(&msg, &txn.transaction_data);
            // svcmgr_handler() 处理对应的操作
            res = func(bs, &txn, &msg, &reply);
            if (txn.transaction_data.flags & TF_ONE_WAY) {
                // 如果是 TF_ONE_WAY 处理，则释放数据
                binder_free_buffer(bs, txn.transaction_data.data.ptr.buffer);
            } else {
                // 如果不是 TF_ONE_WAY 处理，给 binder 驱动回复数据
                binder_send_reply(bs, &reply, txn.transaction_data.data.ptr.buffer, res);
            }
        }
        break;
    }
    }
}

binder_transaction_data 的结构如下，其表明了 transcation 传输的具体语义，语义码记录在 code 中，不同语义码携带的数据是不同的，这些数据由 data 指定。

struct binder_transaction_data {
    union {
        // binder_ref 该成员指明发送方的 Binder 实体引用
        __u32 handle;
        // binder_node 的内存地址，当数据到达接收方时，驱动已将该成员修改成 Binder 实体
        binder_uintptr_t ptr;
    } target;
    // BBinder 指针, 发送方忽略该成员；接收方收到数据包时，该成员存放的是创建 Binder 实体时由该接收方自定义的任意数值，做为与 Binder 指针相关的额外信息存放在驱动中
    binder_uintptr_t cookie;
    // RPC 代码，代表 Client 与 Server 双方约定的命令码，比如 ADD_SERVICE_TRANSACTION
    __u32 code;
    // 标志位，比如 TF_ONE_WAY 代表异步，即不等待 Server 端回复
    __u32 flags;
    // 发送端进程的 pid
    pid_t sender_pid;   
    // 发送端进程的 uid
    uid_t sender_euid;  
    // data 数据的总大小
    binder_size_t data_size;    
    // IPC 对象的大小
    binder_size_t offsets_size; 
    // RPC数据
    union {
        struct {
            // 数据区起始地址
            binder_uintptr_t buffer;
            // 数据区 IPC 对象偏移量
            binder_uintptr_t offsets;
        } ptr;
        __u8 buf[8]; 
    } data;
}

在解析完 binder_transaction_data 的具体语义后，会调用前面传给 binder_loop() 的 svcmgr_handler()，其实就是 switch case 语义码做不同的事情。

// frameworks/native/cmds/servicemanager/service_manager.c

int svcmgr_handler(struct binder_state *bs,
                   struct binder_transaction_data_secctx *txn_secctx,
                   struct binder_io *msg,
                   struct binder_io *reply)
{
    struct svcinfo *si;
    uint16_t *s;
    size_t len;
    uint32_t handle;
    uint32_t strict_policy;
    int allow_isolated;
    uint32_t dumpsys_priority;
    // 获取 transaction_data
    struct binder_transaction_data *txn = &txn_secctx->transaction_data;

    strict_policy = bio_get_uint32(msg);
    bio_get_uint32(msg);  // Ignore worksource header.
    s = bio_get_string16(msg, &len);

    if ((len != (sizeof(svcmgr_id) / 2)) ||
        memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
        fprintf(stderr,"invalid id %s\n", str8(s, len));
        return -1;
    }
    // 根据不同的 code 做不同的事情
    switch(txn->code) {
    // 查询服务
    case SVC_MGR_GET_SERVICE:
    case SVC_MGR_CHECK_SERVICE:
        s = bio_get_string16(msg, &len);
        handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid,
                                 (const char*) txn_secctx->secctx);
        if (!handle)
            break;
        bio_put_ref(reply, handle);
        return 0;
    // 注册服务
    case SVC_MGR_ADD_SERVICE:
        s = bio_get_string16(msg, &len);
        if (s == NULL) {
            return -1;
        }
        handle = bio_get_ref(msg);
        allow_isolated = bio_get_uint32(msg) ? 1 : 0;
        dumpsys_priority = bio_get_uint32(msg);
        if (do_add_service(bs, s, len, handle, txn->sender_euid, allow_isolated, dumpsys_priority,
                           txn->sender_pid, (const char*) txn_secctx->secctx))
            return -1;
        break;
    // 获取服务列表
    case SVC_MGR_LIST_SERVICES: {
        uint32_t n = bio_get_uint32(msg);
        uint32_t req_dumpsys_priority = bio_get_uint32(msg);

        if (!svc_can_list(txn->sender_pid, (const char*) txn_secctx->secctx, txn->sender_euid)) {
            ALOGE("list_service() uid=%d - PERMISSION DENIED\n",
                    txn->sender_euid);
            return -1;
        }
        si = svclist;
        while (si) {
            if (si->dumpsys_priority & req_dumpsys_priority) {
                if (n == 0) break;
                n--;
            }
            si = si->next;
        }
        if (si) {
            bio_put_string16(reply, si->name);
            return 0;
        }
        return -1;
    }
    default:
        ALOGE("unknown code %d\n", txn->code);
        return -1;
    }

    bio_put_uint32(reply, 0);
    return 0;
}

ServiceManager 的功能其实很简单：

接收到 SVC_MGR_GET_SERVICE 或 SVC_MGR_CHECK_SERVICE 时调用 do_find_service() 查找服务
接收到 SVC_MGR_ADD_SERVICE 时调用 do_add_service() 注册服务
接收到 SVC_MGR_LIST_SERVICES 时获取所有服务名称

至此 ServiceManager 就分析完了。

链接：https://www.jianshu.com/p/ffb803265cbf
作者：你怕是很皮哦

如果你想要深入系统的学习Android Framework框架，这里可以分享一份《Android Framework源码开发揭秘》，其中记录了从系统启动流程到WMS全部源码解析，相信你能优秀地学习整个Framework框架。

因文章篇幅原因，只放了部分内容，完整版文末卡片领取

第一章系统启动流程分析

第一节 Android启动概览
第二节 init.rc解析
第三节 Zygote
第四节面试题

在这里插入图片描述

第二章跨进程通信IPC解析

第一节 Sercice 还可以这么理解
第二节 Binder基础
第三节 Binder应用
第四节 AIDL应用（上）
第五节 AIDL应用（下）
第六节 Messenger原理及应用
第七节服务端回调
第八节获取服务（IBinder）
第九节 Binder面试题全解析

在这里插入图片描述

第三章 Handler源码解析

第一节源码分析
第二节难点问题
第三节 Handler常问面试题

第四章 AMS源码解析

第一节引言
第二节 Android架构
第三节通信方式
第四节系统启动系列
第五节 AMS
第六节 AMS 面试题解析

在这里插入图片描述

第五章 WMS源码解析

第一节 WMS与activity启动流程
第二节 WMS绘制原理
第三节 WMS角色与实例化过程
第四节 WMS工作原理

在这里插入图片描述

第六章 Surface源码解析

第一节创建流程及软硬件绘制
第二节双缓冲及SurfaceView解析
第三节 Android图形系统综述

第七章基于Android12.0的SurfaceFlinger源码解析

第一节应用建立和SurfaceFlinger的沟通的桥梁
第二节 SurfaceFlinger的启动和消息队列处理机制
第三节 SurfaceFlinger 之 VSync（上）
第四节 SurfaceFlinger之VSync（中）
第五节 SurfaceFlinger之VSync（下）

第八章 PKMS源码解析

第一节 PKMS调用方式
第二节 PKMS启动过程分析
第三节 APK的扫描
第四节 APK的安装
第五节 PKMS之权限扫描
第六节静默安装
第七节 requestPermissions源码流程解析

在这里插入图片描述

第九章 InputManagerService源码解析

第一节 Android Input输入事件处理流程（1）
第二节 Android Input输入事件处理流程（2）
第三节 Android Input输入事件处理流程（3）

在这里插入图片描述

第十章 DisplayManagerService源码解析

第一节 DisplayManagerService启动
第二节 DisplayAdapter和DisplayDevice的创建
第三节 DMS部分亮灭屏流程
第四节亮度调节
第五节 Proximity Sensor灭屏原理
第六节 Logical Display和Physical Display配置的更新

在这里插入图片描述

各位小伙伴们如果有需要这份《Android Framework源码开发揭秘》资料，点击下方卡片即可【免费领取】！！

小陈乱敲代码

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Android Framework 之启动 ServiceManager

是Binder的守护进程，在Binder机制中起着重要的作用。的启动；打开Binder驱动；设置上下文管理者；进入循环。image.png时序图如下。image.png。
复制链接

扫一扫