企业官网建设流程全解析

做 Binder 专题这段时间，我一直在梳理 Android 系统服务这一条线。前面几篇聊了 Binder 驱动、ServiceManager 启动流程、服务注册与获取的完整通路，到这一篇，终于要进入实操味道最浓的部分：如何从零添加一个 Native 系统服务。这个需求在实际开发里非常常见，比如你有一个硬件设备需要向上层提供访问接口，或者你希望把某个底层能力以系统服务的形式统一管起来，又或者你想绕开 HAL 直接给应用层开一条通路。不论场景怎样，走一遍“写服务端 -> 注册进 ServiceManager -> 客户端获取调用”的完整链路，是你理解 Binder 架构最好的方式。

这篇文章我会用一个模拟的虚拟设备管理服务作为例子，带你完整走一遍 Native 系统服务的添加流程。我会把 AIDL 接口的定义、服务端 Bn 类的实现、编译集成、SELinux 权限配置、客户端验证这些环节逐一拆开，每一步都告诉你为什么要这么做，以及我在实际踩坑中总结出来的注意事项。不管是刚开始接触系统服务开发的同学，还是已经在做系统定制、Framework 开发的工程师，这篇文章都可以直接拿来当作操作手册参考。

1. 整体设计与思路拆解

1.1 为什么选择 Native 系统服务这条路

在 Android 系统里，给上层提供能力通常有三条路：纯 Java 服务、Native 系统服务、HAL 加 JNI 的组合方案。如果你只把服务写在 Java 层，那么 Java Framework 可以直接调用，但底层的 C/C++ 进程想访问就会有障碍。如果走 HAL 方案，十几年前的 Android 版本主要用 hidl 之前的 legacy HAL，现在主流是 HIDL/AIDL HAL，切割进程边界、跨进程性能开销也比较明显。在某些场景下，我们确实需要一个运行在独立 Native 进程里的 Binder 服务，让它以自己的身份注册进 ServiceManager，让所有进程都能通过 Binder 拿到这个服务的代理对象。

选 Native 系统服务而不是别的方案，核心考量通常是三点。

第一是访问权限的开放度。注册进 ServiceManager 之后，只要符合 SELinux 规则，任何进程都能按需获取这个服务，不用走 Java 层的权限校验接口，也不用专门给某个应用开白名单。第二是进程模型灵活。你可以让这个服务跑在独立的 Native 进程里，崩溃了不会拖垮 SystemServer，资源占用也可以单独控制。第三是性能路径短。调用方直接通过 Binder 驱动和你的服务通信，不会经过 Java 层反射或 JNI 转跳，对于高频数据交互场景，延迟更可控。

当然，独立 Native 服务也有代价，比如你还得自己处理 SELinux 标签、init 启动脚本、进程守护策略。这也是为什么我坚持要完整走一遍，因为只有把这几块都打通，你才算真正掌握“添加系统服务”这个能力。

1.2 服务端三层结构与整体通路

一个 Native 系统服务，从代码结构上看，通常会分成三层：接口定义层、服务实现层、进程入口层。

接口定义层就是我们常说的 AIDL 文件，它定义了服务对外暴露的方法和传输的数据结构，编译时自动生成 Binder 通信相关的桩代码。服务实现层是真正干活的地方，你继承生成的 Bn 基类，把接口方法实现出来。进程入口层负责启动一个 Binder 线程池，创建服务对象，把它注册到 ServiceManager，然后进入循环等待其他进程的调用请求。

这里容易让新手懵的地方在于：AIDL 生成的代码里，Stub 和 Proxy 是什么关系。简单说，服务端继承 BnInterface，本质上是继承了生成的 Stub 类，它负责接收 Binder 驱动传来的事务请求，解析方法编号和参数，调用你重写的业务方法。客户端拿到的是 Proxy 对象，它负责把参数打包进 Parcel，通过 Binder 驱动发送到服务端。两边的桩代码是编译期的对称产物，我们只需要在服务端实现业务逻辑，在客户端调用接口方法，剩下的编解码、序列化、驱动交互全部由生成的代码搞定。

我用一个生活化的类比帮你理一理这个过程：服务端就像开了一家银行柜台，AIDL 文件是柜台上张贴的业务列表，客户端是拿号办业务的顾客。顾客把需求填在单子上（Parcel 写入），通过传话窗口（Binder 驱动）递给柜员（Stub），柜员按单子执行，再把结果写回单子还给你。你不需要自己设计传话窗口的机械结构，只需要把业务列表定义好，把实际业务处理逻辑写好。

这种对称的 Stub/Proxy 设计还有一个额外的好处：调试和扩展非常容易。如果哪天你在服务端接口里加了一个方法，重新编译生成代码后，未实现的客户端调用会得到明确的异常或返回码，你能很快定位到是代码没同步还是运行环境不一致。

2. 接口定义与代码实现

2.1 AIDL 接口的设计要点

添加 Native 系统服务的第一步，是确定服务对外提供什么能力。这里我强烈建议用 AIDL 来定义接口，而不是从 Android 8.0 之前的老风格里复制一套手写的 Parcelable 传输协议。原因很简单：AIDL 有完整的编译期检查、类型映射和语言绑定生成，C++ 和 Java 两端都能用，维护成本远低于手写 Parcel 序列化。

我来模拟一个场景，假设我们有一个虚拟加密设备，需要对外暴露两个能力：获取设备是否在线、对输入数据做一次透明加密。那 AIDL 文件可以定义成下面这样。

// IVirtualDevice.aidl package com.example.virtualdevice; interface IVirtualDevice { boolean isOnline(); boolean encrypt(in String input, out String output); }

这里的知识点主要有三个。

第一个是包名和接口名会直接映射到 C++ 的命名空间和类名。编译后生成的头文件对应的类名通常是 IVirtualDevice，核心桩类命名是 BpVirtualDevice 和 BnVirtualDevice。你的服务实现类要继承 BnVirtualDevice。

第二个是 in/out/inout 方向描述符。对于 String 和基本数据类型，in 就够用了；如果你定义一个 Parcelable 自定义结构体并且要在服务端返回修改后的数据，必须认真标注方向。这个标注会影响生成的代码如何处理缓冲区——是只读进、只写出、还是读写都行。标记错了，轻则数据返回不对，重则编译期生成代码逻辑错误，运行时不报错但结果诡异。

第三个是文件路径和包名必须匹配。AIDL 的路径决定了生成本地头文件的归属目录。你放在哪个目录，include 时就用哪个路径，乱放会让编译脚本写起来很别扭。

这个 AIDL 文件定义好之后，下一步就是在系统源码的编译单元里，通过编译规则生成 C++ 实现。

2.2 生成代码与 Stub/Proxy 机制解读

我把 AIDL 文件放到hardware/interfaces/virtualdevice/1.0/这种典型的系统接口目录里。在实际项目里，你可以放到自己的模块目录，只要 make 规则和 include 路径对应得上就行。

在hardware/interfaces/virtualdevice/1.0/下创建Android.bp，大致写法是这样的。

aidl_interface { name: "com.example.virtualdevice", cpp_std: "c++17", owner: "vendor", srcs: ["IVirtualDevice.aidl"], }

编译时系统会调用 AIDL 编译器，生成 C++ 的头文件，存放在out/soong/.intermediates/对应路径下。你不需要手动维护那份带 Parcel 读写的代码，编译系统会帮你生成。这里提醒一句：如果是在 Android 10 及以上版本使用aidl_interface模块，生成规则管理的命名空间和旧版的LOCAL_AIDL_INCLUDES是不同的，新旧写法混杂的话会出现链接报错，后面常见问题部分我会专门讲。

讲到生成代码的内部逻辑，有一个关键点值得展开。生成的 BpVirtualDevice（客户端代理）中，每一个方法对应一个事务码。Binder 驱动和 ServiceManager 并不关心你的方法叫什么名字，它只认事务码。比如isOnline被分配为 FIRST_CALL_TRANSACTION + 0，encrypt被分配为 FIRST_CALL_TRANSACTION + 1。客户端发起调用时，BpVirtualDevice 会把对应的事务码写进 Parcel，然后通过 transact() 发送出去。服务端的 BnVirtualDevice 在 onTransact() 里根据事务码分发到不同的本地方法。

你在调试时如果看到服务端日志里打印出未知的事务码，基本都是两端代码版本不一致造成的。服务端旧、客户端新，或者反之，都会导致这样的问题。

2.3 服务实现类编写与运行原理

服务实现类的代码是整个服务端最核心的一块。你需要继承BnVirtualDevice，实现 AIDL 里声明的虚函数。下面是一个简化版的实现。

// VirtualDeviceService.cpp #include "com/example/virtualdevice/IVirtualDevice.h" class VirtualDeviceService : public BnVirtualDevice { public: ::android::binder::Status isOnline(bool* _aidl_return) override { *_aidl_return = mOnline; return ::android::binder::Status::ok(); } ::android::binder::Status encrypt(const ::android::String16& input, ::android::String16* output) override { std::string inStr = android::String8(input).c_str(); std::string outStr = mEncryptor.process(inStr); *output = ::android::String16(outStr.c_str()); return ::android::binder::Status::ok(); } private: bool mOnline = true; SomeEncryptor mEncryptor; };

几点值得特别注意。

第一，返回值是::android::binder::Status，而不是直接返回 bool。这是现代 Android Binder C++ 接口的统一风格，它的设计目的是给跨进程调用提供一个传递异常和错误码的通道。业务上如果出了差错，你可以通过 Status::fromExceptionCode 返回给客户端，让客户端拿到具体的错误码。

第二，String16 和 String8 的转换。AIDL 的 string 类型映射到 C++ 是 String16，你在实现里通常要转成 String8 或 std::string 才好做字符串处理。项目里统一好这个转换的封装，别到处裸转，后面维护会省很多事。

第三，服务实现类不需要自己加 sp 管理。注册进 ServiceManager 时，框架会帮你持有服务端的强引用。但在一些极端场景下，你需要重写 onAsBinder 方法返回一个稳定的 Binder 句柄，这个句柄可以作为死亡通知的监控对象，后面我会聊到。

2.4 进程入口与 Binder 线程池启动逻辑

服务端的进程入口，是很多人容易忽略、但恰恰是最容易踩坑的地方。一个 Native Binder 服务进程，需要完成四件事：启动 Binder 线程池、创建服务对象、注册到 ServiceManager、保持进程存活。

先看一段典型的 main 函数。

// main.cpp #include <binder/IPCThreadState.h> #include <binder/IServiceManager.h> #include <binder/ProcessState.h> using namespace android; int main(int argc, char** argv) { // 1. 启动 Binder 线程池 sp<ProcessState> proc = ProcessState::self(); proc->startThreadPool(); // 2. 创建服务对象 sp<VirtualDeviceService> service = new VirtualDeviceService(); // 3. 注册到 ServiceManager defaultServiceManager()->addService(String16("virtual_device"), service); // 4. 主线程进入 IPC 等待 IPCThreadState::self()->joinThreadPool(); return 0; }

第一行ProcessState::self()会打开 /dev/binder 设备，并初始化进程级别的 Binder 状态。startThreadPool()会启动一个线程池，里面的线程负责从 Binder 驱动读取事务请求。注意，这一步不是注册完服务之后才开始，而是在注册之前就要启动好，否则服务端还没有能力回应早到的调用请求。

第三步addService是关键动作。它会通过 Binder 驱动向 ServiceManager 进程发起事务，把自己（一个 Binder 句柄）登记到服务名映射表里。注册成功后，其他进程就能通过getService查询这个句柄了。这里有两个细节要清楚：一是服务名是一个字符串，不能超过 256 字节，命名要统一，一旦发布不要轻易改；二是服务名重复注册时，新注册的服务会覆盖掉旧服务，这一点在服务重启场景下需要特别注意。

最后joinThreadPool()会让主线程也加入到 Binder 线程池里，这个函数通常不会返回，所以进程会一直存活下去。如果你在 main 函数后面还写了其他业务逻辑，那基本不会被执行到，这是正常的，别以为程序卡死了。

3. 编译集成与注册细节

3.1 Android.bp 配置与链接依赖

上面写好代码之后，要用编译脚本把服务端可执行文件构建出来。Android.bp 里要注意模块类型是cc_binary，并且把 AIDL 生成的库链进来。一个典型的配置如下。

cc_binary { name: "virtual_device_service", cpp_std: "c++17", srcs: [ "main.cpp", "VirtualDeviceService.cpp", ], shared_libs: [ "libbinder", "liblog", "libutils", "com.example.virtualdevice", ], init_rc: ["virtual_device_service.rc"], vintf_fragments: ["virtual_device_service.xml"], }

这里面有几个隐藏知识点。

首先是shared_libs里的com.example.virtualdevice。这是 AIDL 接口库，它会提供 Bn、Bp 和相关的 Parcel 类型辅助代码。如果你的 AIDL 文件里还定义了 Parcelable 结构体，这个库也会一并生成对应的读写方法。

其次是init_rc和vintf_fragments。前者是 init 进程启动服务用的脚本，后者是 VINTF 兼容性描述文件。对于自定义的 vendor 服务，VINTF fragment 通常用于描述服务所属的 HAL 接口或 vendor 服务特性。很多开发者直接把这两项删掉也能编译通过，但如果你的服务需要开机自启，init_rc 必不可少；如果你的目标产品要走 VINTF 校验，fragment 也不能缺。

最后是链接顺序问题。如果 AIDL 接口头文件是从生成目录 include 进来的，srcs 里不需要写.aidl文件，因为 aidl_interface 模块已经把生成文件暴露给了依赖它的模块。如果你发现 include 不到头文件，先检查模块名是否写错，或者是否缺失了对aidl_interface模块的依赖。

3.2 init.rc 启动脚本的编写与进程生命周期管理

服务端的可执行文件编译好之后，如果没有 init 脚本帮你拉起进程，那你只能手动 adb shell 启动，服务一断就没得用，这在产品上完全不可接受。所以我们需要写一个 init.rc 文件，让 init 进程在开机时把服务拉起来，并且在进程异常退出时尝试恢复。

一个比较稳妥的写法如下。

service virtual_device /vendor/bin/hw/virtual_device_service class core user system group system seclabel u:r:virtual_device:s0 oneshot false disabled false

逐行解释一下：

• service virtual_device后面的路径是编译产物实际安装到系统镜像里的位置。
• class core表示这个服务属于核心启动类。如果你希望它在 early boot 阶段就能被访问，可以放到 core 类。如果你的服务强依赖某些分区挂载完成，可能要放到 main 类或者自己指定时机。
• user system和group system控制服务运行的身份。除非业务需要，不要直接跑在 root 身份下，否则一旦代码有漏洞，影响面会大很多。
• seclabel是 SELinux 标签，这个标签必须和你后面写的 sepolicy 规则一致。标签写错了，服务可能起不来，或者能起来但客户端访问被拒绝。
• oneshot false是让 init 把服务当作常驻进程守护。如果服务一启动就退出，init 会反复拉起它。如果你的服务本身只执行一次不需要常驻，才考虑改成oneshot true。对于 Binder 服务来说，肯定需要常驻。
• disabled false表示开机即启动。如果某些服务需要在特定时机才拉起，可以改成disabled true然后用start命令控制。

这里有个实战细节必须提醒：init 拉起服务是异步的，你的客户端可能在服务注册成功之前就去 getService。此时 Binder 驱动会阻塞等待服务出现吗？不会。getService 的默认行为是轮询等待一段时间，超时后返回空。所以客户端的重试逻辑要写好，第一次拿不到就隔几百毫秒再试，避免开了个屏就崩溃。

3.3 addService 的注册时机与服务端就绪判断

服务端代码里defaultServiceManager()->addService(...)一执行，服务名在 ServiceManager 里就立即可查了。但这里有一个隐蔽细节：addService 注册成功并不代表你的服务已经完全准备好了。如果你的构造函数里还要做比较耗时的资源初始化，比如打开设备节点、加载算法库、读取配置，那么客户端很可能在 addService 之后马上拿到 Binder 句柄，然后调用接口方法，但服务端还在构造函数里没跑完。

这种竞态通常很隐蔽，偶发出现，排查时又很容易忽略。我的建议是让构造函数尽量轻量，把耗时初始化放到 addService 之后的某个显式方法里，或者用自旋状态标记就绪。如果服务没就绪，接口方法可以先行返回一个明确的错误码，而不是让调用方干等。

我写的代码里有一个叫mOnline的成员变量，这种标记位在复杂服务里可以扩展为状态机。客户端可以轮询状态接口来判断服务是否 ready。很多系统服务也是这么做的，比如一些 HAL 服务对外提供 init 完成回调，本质都是为了避免注册与就绪之间的竞态窗口。

3.4 ServiceManager 服务名查表与动态更新

现在来看注册完成的全局视角。ServiceManager 内部维护着一个名字到 Binder 句柄的映射表。当服务 A 注册后，进程 B 调用getService("virtual_device")时，Binder 驱动会把这个请求转发给 ServiceManager，ServiceManager 查表后返回对应的 Binder 句柄引用。这个句柄是经过强转的，可以理解为指向服务端的一个索引，真正跨进程传输数据时，Binder 驱动会完成句柄到真实进程路由的转换。

这个机制带来一个好处：客户端拿到的服务代理不需要知道服务端进程的网络地址、进程 ID 等细节，只要知道一个稳定的字符串名字就够了。这也是系统服务架构解耦设计的精妙之处。

有一个现象值得一提：当你的服务进程被杀掉后，Binder 驱动会这个句柄对应的引用自动失效，ServiceManager 会把该服务的注册信息移除，但不会自动删除名字条目本身，会在驱动层的清理中标记为 dead。客户端如果再调用这个代理，会收到DEAD_BINDER之类的错误。想要重新接上，客户端必须再次 getService 获取新句柄。

4. SELinux 权限配置与进程域设计

4.1 为什么注册进 ServiceManager 还会权限失败

很多人在自己机器上把这套流程跑通之后，发誓根镜像一开就一切正常。但同样一套代码，到了 user 版本或开了 SELinux enforcing 的设备上，服务就注册失败，或者客户端一调用就得到Permission Denied。原因就是 Android 的 SELinux 策略强制介入了 Binder 通信。

SELinux 对 Binder 服务的管理，是基于进程标签（domain）和服务标签（service label）的。服务端进程的 domain 在 init.rc 里由seclabel指定，服务端要注册服务给 ServiceManager，需要满足对应的 allow 规则。客户端进程要 getService 和 transact，也需要有权限。

如果你是完全不允许域名转换的封闭环境，直接默认放行整个串会容易拿到一个能跑通的系统，但产品上绝不建议这么干。

一个非常常见的错误是：服务端进程的 seclabel 写成了u:r:system_server:s0，想的是“反正 system_server 权限大，什么都能干”。但实际上，SELinux 要求一个进程只能有一个 domain，如果你把自定义服务进程的标签设成 system_server，这个服务的行为会被视为对 system_server 域的逃脱。系统服务和普通 vendor 进程的 provider 路径不同，这种写法轻则设备起不来，重则安全审核直接打回。我建议任何自定义服务都单独建 domain，一个人一个坑位，谁也别蹭谁的权限。

4.2 sepolicy 规则编写实战

在项目里新增一个名为virtual_device的 domain，需要添加对应的 te 文件。路径通常在device/某厂商/某产品/sepolicy/vendor/下，内容大致要覆盖四类规则：

第一，服务端进程自身的 domain 定义和基本允许。

type virtual_device, domain; type virtual_device_exec, exec_type, file_type, vendor_file_type; init_daemon_domain(virtual_device) allow virtual_device virtual_device_exec:file { execute_no_trans };

init_daemon_domain(virtual_device)这句很关键，它会把 virtual_device 域挂接到 init 的 mac 策略体系里，init 进程才能合法地把这个域拉起并切换标签。

第二，服务端向 ServiceManager 注册服务。

allow virtual_device servicemanager:service_manager add; allow virtual_device default_android_service:service_manager add;

servicemanager这个 target 是 ServiceManager 进程的域，default_android_service是对服务名的一种默认访问标签。实际项目里，我们通常会针对具体服务名设置专门的服务上下文，避免所有 vendor 服务共用 default 标签导致权限面过大。

服务上下文文件的格式如下：

virtual_device u:object_r:virtual_device_service:s0

第三，客户端访问服务端的 Binder 进程通信规则。

allow appdomain virtual_device:binder { transfer call };

这一句的含义是，允许所有应用域进程通过 Binder 调用 virtual_device 域的进程。如果需要限制特定应用才允许，可以把appdomain改成具体的客户端 domain。调用具体服务时，还需要 transact 权限。

allow appdomain virtual_device_service:service_manager find;

find是允许客户端根据服务名在 ServiceManager 里查到对应句柄的权限。没有这条，客户端 getService 就会失败。

第四，服务端可能需要访问设备节点或其他资源，这类规则根据实际业务添加到 te 文件里即可。比如你的虚拟加密设备需要访问/dev/xxx，那就要增加对应的 dev 节点访问允许。

我先给一个最小可用版本：

allow virtual_device servicemanager:service_manager add; allow virtual_device default_android_service:service_manager add; allow appdomain virtual_device:binder { transfer call }; allow appdomain virtual_device_service:service_manager find; allow virtual_device self:udp_socket create_socket_perms; allow virtual_device self:tcp_socket create_socket_perms;

注意，这些规则里的virtual_device_service是服务上下文的名字，而不是服务进程的 domain。理解这一点很重要：service_manager 的对象类（如 find/add）操作的是服务上下文，而 binder 的 call/transfer 操作的是进程域。把这两个体系搞混了，排查问题时会非常痛苦。

4.3 常见 denial 的日志解读

权限配置再完备，也不可能一次写对。启用 enforcing 之后，遇到问题第一步肯定是抓审计日志。在 adb 环境下可以执行：

adb root adb shell setenforce 0 adb shell dmesg | grep avc

或者直接看 logcat 里的 SELinux denial。常见的失败形式有三种。

第一种是注册阶段失败，典型日志是：

avc: denied { add } for service=virtual_device scontext=u:r:virtual_device:s0 tcontext=u:r:servicemanager:s0 tclass=service_manager

这表示缺少 add 权限。通常就是我在上面写的servicemanager:service_manager add这行没有配对。

第二种是客户端查服务失败，日志类似：

avc: denied { find } for service=virtual_device scontext=u:r:untrusted_app:s0 tcontext=u:r:virtual_device_service:s0 tclass=service_manager

这表示客户端根本没有资格在 ServiceManager 里找到这个服务。除了要加 find 规则外，还要确认服务上下文映射文件已生效。服务上下文文件名或内容变了，需要重新编 boot 镜像。

第三种是客户端已经拿到句柄，但调用时被 binder 层拒绝，日志类似：

avc: denied { call } for scontext=u:r:untrusted_app:s0 tcontext=u:r:virtual_device:s0 tclass=binder

tclass 从 service_manager 变成了 binder，说明客户端已经过了查表这一关，卡在了 Binder 驱动层面的跨进程调用。要补的是appdomain virtual_device:binder { call transfer }。

给一个排查建议：先开setenforce 0跑通功能，再一条条加回规则，加一条验证一次，不要一上来就写一大坨 allow。这样定位问题会快很多。

5. 客户端获取服务与验证流程

5.1 实名获取 Binder 的标准姿势

服务端注册好后，客户端获取服务的路径其实很统一，就是用defaultServiceManager()->getService()。区别在于客户端是 C++ 还是 Java，这里两个都展示一下。

C++ 客户端获取方式。

#include <binder/IServiceManager.h> sp<IVirtualDevice> getVirtualDevice() { sp<IServiceManager> sm = defaultServiceManager(); sp<IBinder> binder = sm->getService(String16("virtual_device")); if (binder == nullptr) { return nullptr; } return interface_cast<IVirtualDevice>(binder); }

Java 客户端获取方式。

import com.example.virtualdevice.IVirtualDevice; IVirtualDevice service = IVirtualDevice.Stub.asInterface( ServiceManager.getService("virtual_device"));

在早期 Android 上，Java 层直接调用ServiceManager.getService，但现代版本更推荐通过ServiceManager类或 Binder 服务管理封装来获取。拿不到服务时不要假死，建议包装成带重试逻辑的获取函数。

值得展开的是interface_cast和IVirtualDevice.Stub.asInterface的作用。它们都做同一件事：把一个 IBinder 句柄转换成本地接口代理。如果这个句柄本来就是本进程内创建的 Binder 对象，它不会走跨进程，而是直接返回服务端对象本身。这种同进程优化在系统开发里很常见，它会给你调试时带来一点疑惑——明明打印日志显示走的是本地实现，代码路径却和远程调用不同，但实际上这是 Binder 设计上的底层优化。

5.2 与服务端交互验证的完整流程

客户端代码写好之后，把它编译成可执行文件或者作为模块跑起来，验证流程我认为应该包含四步，不能跳过任何一步。

第一步，确认服务进程确实启动了。执行adb shell ps -A | grep virtual看进程是否存在。如果进程不存在，去 logcat 看 init 拉起失败的原因，最常见的是 seclabel 标签无效、二进制文件权限不可执行、依赖库缺失。

第二步，确认服务确实注册成功了。执行：

adb shell service list | grep virtual

如果有输出，说明 addService 已经生效。这里还有一个更细的玩法：service list 里输出带[vendor]前缀，表示这是一个 vendor 提供的服务。如果你的服务没有跑到预期的标识类别里，要检查 VINTF 和 init 配置。

第三步，运行客户端可执行文件，调用接口方法。检查返回值和日志。建议服务端在接口方法里加 ALOGI 级别的日志，方便确认调用确实从 Binder 线程池进来了，而不是走的本进程直调。

第四步，做一次压力测试。循环调用几百次encrypt，或者并发起多个线程同时请求。Binder 线程池默认大小是可以扩展的，但如果你的服务端方法里有耗时操作，比如持锁等待，并发上来了很容易出现调用超时，或者线程池被占满后新请求排队时间过长。通过这些测试能提前暴露服务端的并发能力问题。

5.3 错误码与异常返回的解析思路

跨进程调用遇到问题时，返回的错误码和异常信息会直接暴露问题环节。我把常见错误码的定位思路写在这里。

DEAD_BINDER：服务端进程已经死掉或者 Binder 驱动侧清理了句柄。先检查服务进程是否还活着，再检查是否是 SELinux 策略把活着的服务给干掉了，最后检查是否服务端自己 crash 了。

FAILED_TRANSACTION：Binder 驱动传输失败。通常是 Parcel 里塞的数据太大，或者事务码不匹配。如果你在调试时改动过 AIDL 接口但没有同步两端代码，优先怀疑这个。

NAME_NOT_FOUND：getService 时 ServiceManager 没找到对应名字。重点检查服务名拼写和 addService 时机。很多情况是服务进程启动失败了，根本没走到 addService。

SECURITY_ERROR：Binder 事务被策略拒绝。这个和前面聊的 SELinux denial 是强相关，优先抓 avc 日志。

UNKNOWN_TRANSACTION：服务端无法识别的 transaction 码。绝大多数是两端代码版本不一致，尤其是 AIDL 文件改过方法顺序，导致生成的 PB 事务号变化了。

把这几个错误码作为速查表记忆，你排查系统服务问题的效率会提升很多。我实际干活时，几乎每次都靠这几个错误码结合 avc 日志快速定位，十次里能解决九次。

6. 常见问题与避坑技巧

6.1 编译报错与 AIDL 命名空间冲突

写 AIDL 接口时最容易踩的第一个坑就是包名冲突。假设系统里已经有一个com.example.virtualdevice的接口库，你新建另一个模块也用了同样的包名和接口名，编译时就会出现重复符号或者 Soong 报 ambiguity 错误。这个问题在新手项目里尤其常见，因为大家都爱用com.example这个示例包名。建议从立项开始就用项目的唯一标识符，比如公司域名倒写加模块名，别贪图省事用通用包名。

第二个坑是 C++ 命名空间映射规则。AIDL 包名com.example.virtualdevice在 C++ 端会生成com::example::virtualdevice的命名空间。如果你在代码里 include 头文件后直接写IVirtualDevice，是找不到类型的，必须写全命名空间，或者用 using 声明。我在 2.3 小节的示例代码里省略了这一层，但在实际工程中这是高频报错点，提前知道能省几分钟排查时间。

第三个坑是 AIDL 自带的数据类型映射。比如byte映射到 C++ 是int8_t，Java 是byte；long映射到 C++ 是int64_t。如果你在接口里喜欢用 Java 的int表示大数，跨端很容易出溢出问题。定义接口时想清楚每种数据类型的有效范围，避免到联调阶段才发现类型对不上。

6.2 selinux 策略不生效的三个隐蔽原因

规则明明写好了，编译也过了，但 enforcing 环境下还是被拒绝。我遇到的隐蔽原因主要有三个。

第一个是修改 sepolicy 之后没有完整重打包。SELinux 策略通常被打进 boot 镜像或 vendor 分区，如果你只是给某个模块打 patch 后单独 push，策略库并没有更新。验证时先确认当前设备的 sepolicy 版本，最简单的方法是重新刷入完整镜像或者确认你 push 的 secilc 编译产物确实被加载了。

第二个是服务上下文文件没有同步更新。即使 te 文件里写了 allow 规则，service_contexts 文件里的映射错了，比如服务名和标签不匹配，客户端依然会被拒。很多时候你的规则本身没错，错的是映射文件里的名字少写了一个下划线。

第三个是 vendor 和 system 分区策略的边界。Android 9 之后把 system 和 vendor 的 sepolicy 拆成了独立的编译单元。你的服务如果是 vendor 进程，规则必须放在 vendor 的 sepolicy 目录里；如果你写在 system 下，进程实际加载的 vendor sepolicy 根本没有这条规则。这个边界问题在编译系统里往往不会报错，运行起来才暴露。

6.3 死亡通知与重启恢复

在实际产品中，一个 Native 系统服务不可能永远不出故障。has died 的情况必须提前考虑好。服务进程崩溃后，Binder 驱动会通知已注册的死亡回调。客户端可以注册DeathRecipient，收到死亡通知后主动重新获取服务。

class ServiceDeathRecipient : public IBinder::DeathRecipient { void binderDied(const wp<IBinder>& who) override { // 重新获取服务 std::thread([this]() { std::this_thread::sleep_for(500ms); sp<IVirtualDevice> newService = getVirtualDevice(); }).detach(); } };

注册死亡通知的时机要在拿到 Binder 句柄后立刻进行，否则服务端可能在注册回调之前就挂了，回调自然收不到。Java 端对应的是linkToDeath方法，逻辑一样。

服务端这边，init 的class core配合oneshot false，会在进程异常退出时自动拉起，这是最基本的保活策略。如果你的服务挂了之后还需要重新初始化硬件，那么 init 重启后必须在 main 函数里做一次完整的重新初始化，否则服务进程虽然活了，但业务状态不对。

还有一个细节：服务重启后，进程的 Binder 句柄会变化，之前注册在 ServiceManager 里的旧句柄会被清理。客户端持有的旧代理全部失效。这时候客户端的死亡回调就是最终的救场手段。我在多个项目里实测过，客户端进程如果没有实现死亡回调，服务一升级或崩溃，整个业务链就断了，直到客户端进程重启。这个环节一定要在设计阶段考虑进去。

6.4 性能调优与线程池配比

Binder 服务端的默认线程池大小由 Binder 驱动参数控制，ProcessState::self()->setThreadPoolMaxThreadCount()可以调整。默认值通常够用，但如果服务端的接口方法都是耗时操作，而客户端调用并发很高，建议根据业务模型调整。

调大线程池数量并非没有代价。每个 Binder 线程都会占用一部分栈空间和调度资源，线程池过大反而会因为上下文切换开销而拖慢整体响应。我在实际项目中的经验是，先跑一轮并发压测，观察服务端线程池是否被打满，被打满时再逐步上调，每次增加 4 个线程左右观察效果。

Binder 事务缓冲区大小默认 1MB，如果单次要传输的数据接近这个上限，需要提前分段处理，而不是试图一次性塞进去。AIDL 接口设计时，对于可能携带大数据的接口，建议用异步回调或者数据分片，而不是同步大对象交换。

6.5 调试利器和日志定位技巧

最后分享几个调试 Native 系统服务的实用工具和技巧。

adb shell service list是查看服务注册状态的利器。它能快速看出服务在不在、服务名对不对、是 vendor 还是 system 服务。

adb shell dumpsys activity service 服务名在 Java 服务里很常用，Native 服务如果实现了IDump接口，也可以注册 dumpsys 输出，方便在问题现场获取服务端内部状态。

adb shell killall 服务进程名在测试死亡恢复机制时非常方便。杀掉进程后观察 init 是否自动拉起，客户端是否触发死亡回调并重连。这一条链路验证通过，服务的生产可用性才算过关。

日志方面，服务端建议在入口处加这样的日志：

ALOGI("[%s] entering", __FUNCTION__);

并在每个接口方法返回时打印关键参数。跨进程调试最怕的是两边各执一词，有日志能快速锁定是哪一端先出了问题。打日志也有技巧，不要打大字符串的完整内容，打印长度和指纹就好，避免日志刷屏拖垮性能。

写在最后的实操感悟

添加 Native 系统服务这个需求，看起来不过是写一个服务类、注册一个名字，但当我把整个流程串起来之后才发现，真正考验人的不是某个单一环节，而是 Binder 驱动、ServiceManager、SELinux、init 这些模块之间的配合关系。每次遇到服务注册失败，我会先查进程起来了没有，再查 avc 日志，再查 service list，基本三步就能定位问题。这套排查路径我从第一次做系统服务一直用到现在，几乎没失过手。

如果你也在做类似的开发，我建议你从最小可用的虚拟服务开始，不要一上来就搞复杂业务。先把空服务跑通，再逐步加方法、加权限、加业务逻辑。等服务端、客户端、权限、守护链路都稳定了，后续扩展就是在既有框架里填代码的事，难度会低很多。这个专题后面我还会写自定义服务如何做系统级权限管控、如何通过 vndk 限制避免私有库依赖这些更深入的话题，到时候我们再接着聊。