一：概要

对android的binder通信机制，服务进程通过向 ServiceManager 添加对应的服务aidl实现binder对象，向其他应用提供服务能力。客户进程则是通过对应服务名从 ServiceManager 中获取对应的服务binder对象。

android在最新版本中有三个不同的 ServiceManager ,分别为 ServiceManager，vndServiceManager，hwServiceManager。本文能过分析最近几个版本中的ServiceManager和不同版本中的核心差异来学习 ServiceManager 。

二：binder驱动

通过查看设备节点，我们发现最新的版本中是有三个binder的驱动节点的，分别为 /dev/binder，/dev/vndbinder，/dev/hwbinder。查看内核驱动代码/drivers/android/，通过Kconfig和binder的init函数，可以得知，在binder驱动初始化的时候，通过Kconfig的配置，默认生成了三个设备节点。（？？？？）

三：ServiceManager 和 vndServiceManager

一：ServiceManager的服务端实现

ServiceManager 的源码在 /frameworks/native/cmds/servicemanager/

ServiceManager 和 vndServiceManager 是使用同一套代码编译出不同的bin文件，并通过不同的启动配置运行。两者的差异主要在运行时的权限管理上，后续提到 ServiceManager 时，默认指 ServiceManager和vndServiceManager。

ServiceManager 在 android11时被重构了一次，所以分析时，android11以前和android11之后的需分开说明。

1：旧版 ServiceManager

在旧版中，ServiceManager直接打开驱动节点，解析binder数据。对应的binder服务名和binder对象 通过一个list存起来。

在这个版本的 ServiceManager 中，其他进程只能通过addService把服务添加到sm中，通过getService 获取到对应的服务。服务add后无法主动移出，也无法在add新服务后通知关注对应服务的进程来获取。功能相对单一。

2：新版 ServiceManager

新版的 ServiceManager 参考了 hwServiceManager 的实现，通过新增一个 IServiceManager.aidl 接口，在ServiceManager中实现了这一接口，同时，具体的binder调用就直接使用libbinder库。做到了更高的模块化。

在服务管理上，新版 ServiceManager 通过一个map来管理服务，服务的binder信息存放在一个service的结构体中。新增了两个回调接口，可以把服务的状态变更实时通知道到客户端进程中。

二：ServiceManager的客户端实现、

ServiceManager 的客户端代码在/frameworks/native/libs/binder/IServiceManager.cpp

新版和旧版的核心不同是新版使用了aidl定义了ServiceManager的接口，旧版则是直接在代码中实现BpServiceManager。

客户端通过 defaultServiceManager（）函数获取到 ServiceManager 的客户端binder。在defaultServiceManager（）函数中，实际是通过ProcessState中的getContextObject函数获取的，ServiceManager的binder handle为0，所以getContextObject中直接使用0去获取。

1：旧版 ServiceManager 客户端

在旧版中，是通过 BpServiceManager 去调用 ServiceManager ，只有 getService、checkService、addService、listServices四个方法，除了getService，其他都是直接调用到 ServiceManager。

2：新版 ServiceManager 客户端

在新版中，则是直接通过 ServiceMangerShim去继承IServiceManager，实现了 IServiceManager.aidl 的proxy，这样看起来就和其他aidl接口没有区别。

在新版中，getService、checkService、addService、listServices四个方法和旧版在使用上基本相同，新增了一个新方法 waitForService ,这个方法会先去 getService ，如果无法获取到对应的服务，则向ServiceManager 注册一个 IServiceCallback 并开始等待，当对应的服务被add到 ServiceManager 中时，这个服务被注册的信息会通过 onRegistration 回调到当前进程，解锁等待后再getService。

在android 13中，在waitForService中还会尝试去启动对应的服务。这部分我还没看明白，后面看明白了再分析。

四：hwServiceManager

一：hwServiceManager的服务端实现

hwServiceManager 的源码在 /system/hwservicemanager/

hwServiceManager 的代码在android 10之后就没有再演进了，后面几个版本主要是一些很小的修改。ServiceManager 在android 11中的重构主要是基于 android 10 的hwServiceManager来做的。

上图是一个简单的hwServiceManager 类关系图，对比 ServiceManager 可以发现，其最基本的都是管理 servicer binder和两个状态通知回调接口。只是在实际实现的时候，ServiceManager 基于最新的 hwServiceManager ，做了大量的精减，只用一个 ServiceManager 就完成了这三个的管理。

而hwServiceManager还要考虑到之前版本的兼容，以前对应于直通模式，所以使用了一个冗余的内部类，再加一个外部的hidlService类。

在接口设计上，hwServiceManager和ServiceManager基本相同，add和get都大同小异，两个服务之间最大的不同来自于client调用端。

二：hwServiceManager的客户端实现

hwServiceManager 客户端的实现在 /system/libhidl/transport/