1. 为什么要自己动手添加一个 Java 系统服务
做过系统定制或者 Framework 层开发的读者应该都有体会：Binder 是 Android 系统里跨进程通信的绝对核心。日常写 App 时用 AIDL 定义接口、绑定 Service，本质上就是在跟 Binder 打交道；但真正进入系统层面，自己动手往 SystemServer 里塞一个系统服务，则是另一套完全不同的玩法。这篇专题就聚焦一个非常具体、非常高频的需求：如何往 Android 系统里添加一个 Java 系统服务，并让它通过 ServiceManager 统一注册、统一管理、被上层应用合法调用。
先说清楚这个需求出现的典型场景。我做过一个企业的定制 ROM 项目，当时需要在系统层面提供一套设备唯一标识的生成与校验接口。应用层可以直接写一个 App 来做，但问题在于：普通 App 的进程可能被用户强杀，或者被厂商清理掉，而系统服务的进程由 init 启动、由 SystemServer 统一托管，生命周期完全可控。更重要的是，系统服务可以拿到一些普通应用拿不到的权限，比如读写特定分区、访问底层驱动节点。把这些能力封装成一个 Java 系统服务，是解决这类需求最干净、最符合平台规范的方式。
再往深一层说，Java 系统服务并不是指你在 Manifest 里注册的那个 Service，而是指运行在 SystemServer 进程内、通过 ServiceManager 以字符串名称（比如 "mount"、"power"、"window"）对外暴露的 Binder 服务。Android 系统里二十多个核心服务，从 ActivityManager 到 WindowManager，全部走这条注册路径。所以，如果你想把一个能力提升到“系统级”，让系统内所有 App 都能通过getSystemService(XX)或者ServiceManager.getService("xxx")拿到 Binder 代理，那你必须理解这套注册、查询、调用链路的每一环。
这篇文章面向三类读者：第一种是做 ROM 定制、系统应用开发的，需要新增系统 API；第二种是研究 Binder 原理，想找一个小而完整的落地案例来串联知识点的人；第三种是遇到“服务在应用层调用不到”这类问题，想搞清楚排查思路的开发者。我会从原理讲到实操，从代码讲到编译，最后把我在几个真实项目里踩过的坑一并抖出来。
2. 添加 Java 系统服务的完整技术链路
2.1 先理解 SystemServer 与 ServiceManager 的分工
在动手写代码之前，必须先把这一条链路理清楚。Android 系统开机后，init 进程会启动 zygote，zygote 再孵化出 system_server 进程。SystemServer 进程的入口方法里调用了一系列startXxxService()，这些方法做的事情其实就四件：创建服务实例、把服务注册到 ServiceManager、把服务加入 Watchdog 监控、给应用层提供 Binder 句柄。
ServiceManager 本身是一个独立的原生进程（servicemanager），它维护着一张字符串名字到 Binder 引用的映射表。所有服务注册时，调用ServiceManager.addService(name, service)，底层通过 Binder 驱动把 Binder 节点传给 servicemanager；应用层查询时，调用ServiceManager.getService(name)，底层同样通过 Binder 驱动拿到服务的代理对象。关键点在于：ServiceManager 里存的并不是 Java 对象，而是 Binder 引用，所以跨进程调用时，真正的工作发生在 Binder 驱动和每个进程的 Binder 线程池里。
因此，添加 Java 系统服务这一步，你实际上同时在做三件事：定义跨进程接口（AIDL）、实现一个 Binder 服务类（继承生成好的 Stub）、调用ServiceManager.addService()注册。三步缺一不可。
这里心法特别重要：Java 系统服务本质上就是一个普通的 Binder 服务，只不过它的宿主进程变成了 SystemServer。凡是能在应用层 AIDL Service 里做到的，系统服务基本都能做；反过来，系统服务能做的很多事，普通 Service 做不到，差别只在权限与宿主进程的管理方式。
2.2 Java 服务与 Native 服务的核心差异
系统服务并不只有 Java 一种实现方式。Android 里也大量存在 Native 服务，比如 media、surfaceflinger。Java 服务由 SystemServer 进程直接 new 出来，宿主是 ART 虚拟机；Native 服务则运行在独立进程或独立线程里，用 C++ 实现。
在实际选型时，为什么大部分系统级能力还是用 Java 服务居多？核心原因在于开发效率。SystemServer 里已经有大量现成的 Java 系统服务可以直接依赖，比如 PackageManager、ActivityManager、AudioManager，你在实现自己的服务时可以直接调用这些服务的方法，不需要自己处理复杂的进程间通信。如果做成 Native 服务，每次想调用 PackageManager 都要重新封装一层 Binder 代理，维护成本成倍上升。
但 Java 服务也有明显的边界：它拿不到纯 Native 层的东西。比如你要直接访问某个驱动节点，或者做高性能的音视频处理，Java 层要么通过 JNI 下探，要么就得把核心逻辑放到 Native 服务里。我在之前的项目里就遇到过一个情况：某硬件产商的加密模块只有 C 接口，当时我的方案是 Java 服务持有一个 JNI 桥接对象，底层推送到 Native 处理，上层仍然保持 Java 系统服务的形态。这样应用层开发者的接入成本最低。
还有一点要注意，Java 系统服务的注册时机通常在 SystemServer 的startOtherServices()里，这部分代码路径会同时启动几十个服务，每个服务的初始化顺序会产生依赖关系。比如你需要用到 PackageManager，那你的服务就必须在 PackageManager 注册之后再启动；如果你需要用到 ActivityManager 的某些能力，还得分清楚是ActivityManager还是ActivityTaskManager，这两个服务的注册时机完全不同。
2.3 服务注册的本质：addService 到底做了什么
ServiceManager.addService()这个调用的底层链路值得仔细讲一讲。Java 层的ServiceManager.addService()会通过 Binder 代理进入 servicemanager 进程，最终调用到内核的 binder 驱动。
内核 binder 驱动维护了一个“binder_proc”和“binder_node”的结构，当 servicemanager 收到 addService 请求时，它把当前 Service 的 Binder 节点记录到自己的映射表里。以后每次 getService，servicemanager 就根据名字找到 Binder 节点，并在请求方进程里生成一个对应的 Binder 代理对象。代理对象在应用层表现为XXX.Stub.asInterface(binder)封装好的接口实现。
从这个本质出发，你可以理解几个实际工作中的现象。第一，服务名字是跨进程契约，addService("my_service")之后，客户端必须getService("my_service")才能拿得到，拼错一个字符都不行。第二，同一个进程中重复注册同一个名字会覆盖旧服务，不会报错，这既是便利也是隐患。第三，如果你在 SystemServer 里注册了服务但客户端拿不到，大概率是 selinux 权限拦截，而不是服务没注册成功。
这里我自己有一个习惯：每次注册完服务，第一时间用adb shell service list | grep my_service验证注册结果。这个问题能在最早期暴露 90% 的注册类错误，比后面黑盒排查高效得多。
3. 搭一个最小可用的 Java 系统服务
3.1 定义 AIDL 接口：服务对外能力的契约
第一步是写 AIDL 文件。AIDL（Android Interface Definition Language）是 Binder 接口的定义语言，它决定了跨进程调用时两端如何序列化参数、如何映射方法。系统的所有 Java 服务几乎都会定义自己的 AIDL 接口，位置在frameworks/base/core/java/android/os/下，后缀为.aidl。
我以一个自带的安全认证服务为例，实际项目中我需要提供两个能力：生成一次性令牌；校验某个令牌是否有效。于是 AIDL 定义如下：
package android.os; interface IMyAuthService { String generateToken(String packageName, int flags); boolean verifyToken(String token); String getServiceVersion(); }这里有几个细节要强调。AIDL 接口的 package 声明必须与文件路径一致，否则编译会直接失败。方法参数和返回值类型必须是 Binder 支持的类型：基础类型、String、CharSequence、List、Map，以及自定义 Parcelable。如果你的返回值需要传给应用层做二次封装，建议直接返回可序列化的对象，避免应用层再去反序列化。
编译系统会为这个 AIDL 生成一个IMyAuthService.Stub抽象类，以及IMyAuthService.Stub.Proxy内部类。你只需要实现 Stub 里的方法，客户端拿到 Binder 代理后，IMyAuthService.Stub.asInterface()会自动判断当前进程是本地还是远程，分别走直接调用和 Binder 驱动两条路径。
3.2 写实现类：继承 Stub 并补充权限校验
AIDL 生成 Stub 之后，你的核心逻辑全部写在 Stub 的实现里。实现类放在 SystemServer 所在进程内，也就是说它可以调用其他系统服务的方法，而客户端拿到的只是 Binder 代理，无法直接访问这些内部对象。
实现类要注意几个问题。首先是线程模型：Binder 方法默认在 Binder 线程池中被调用，多个客户端同时请求时可能并发进入你的实现方法。如果某个方法需要修改共享状态，必须保证线程安全，否则跑一段时间就会出现诡异的数据错乱。我在一次压测中遇到过令牌生成计数错乱的问题，排查了很久才发现是并发写 HashMap 导致内存可见性问题，后来改成 ConcurrentHashMap 并加锁才稳定。
其次是权限校验。系统服务面临的风险远大于普通 App 服务，任何调用者都能通过ServiceManager.getService()拿到 Binder 代理，然后尝试调用你定义的方法。如果这些方法涉及敏感能力，必须在实现方法中校验调用者的 UID 或权限。常用的方式是：
public String generateToken(String packageName, int flags) { // 校验调用者身份 int callingUid = Binder.getCallingUid(); if (callingUid != Process.SYSTEM_UID && callingUid < Process.FIRST_APPLICATION_UID) { throw new SecurityException("Permission denied"); } // 核心逻辑 }这里我再补充一条经验：不要只依赖调用者传入的 packageName 来判断身份，因为它是可以被伪造的。要使用系统底层提供的Binder.getCallingUid()、Binder.getCallingPid()以及 PackageManager 的反查结果来确认真实身份。我在实际项目里遇到过恶意应用伪造包名尝试调用系统服务的情况，靠这个校验方式拦截住了。
实现类的内部结构建议做成“薄壳服务”：Stub 实现只做参数解析、权限校验、线程调度，具体业务逻辑下沉到一个独立的 Manager 类。这样写有几个好处：便于单元测试，不依赖 Binder 环境即可测试核心逻辑；便于后续扩展，如果业务逻辑需要跨进程或者独立模块，壳不动、内部随便改。
3.3 注册到 SystemServer：把服务挂进系统进程
实现类写完，最后一步是让它运行起来并在 ServiceManager 里挂名。不同 Android 版本有差异，但整体框架是稳定的。Android 10 及以上的版本，主流做法是在 SystemServer 里新增一个静态方法，然后在startOtherServices()中调用。
这里给出一个适合参考的模板：
private static void startMyAuthService(Context context) { try { IMyAuthService.Stub service = new MyAuthService(context); ServiceManager.addService("my_auth", service, true /* allowIsolated */); // 第三个参数是是否允许隔离进程访问，一般建议传 false 除非确有需求 } catch (Throwable e) { Slog.e(TAG, "Failed to start my_auth service", e); } }启动顺序要注意：如果你在服务初始化时调用了PackageManager.getPackageInfo()或者ActivityManager.getCurrentUser()，那你必须把这些依赖服务启动之后再调用你的启动方法。以我项目为例，我的服务初始化和注册只依赖简单上下文，所以在startOtherServices()的中间位置插入没问题；但如果你的服务依赖 WindowManager，就不能放在它前面。
关于allowIsolated参数，在 Android 9 之前 addService 只有两个参数，后来版本为了安全隔离增加了这个标志位。隔离进程（isolated process）是 Android 用来运行受限内容的特殊进程，通常没有权限直接访问系统服务。如果你的服务不应该被这类进程调用，传 false 是最稳妥的选择。
3.4 客户端验证：从 ServiceManager 里把服务取回来
服务注册成功不代表万事大吉。客户端能不能跨进程拿到服务，还需要单独的验证链路。系统级服务的客户端调用有两种方式：一种是直接拿 Binder 代理，适合系统应用或负责该服务的开发者；另一种是封装成系统 API，通过Context.getSystemService()暴露给所有应用。
验证代码比较简单：
IBinder binder = ServiceManager.getService("my_auth"); if (binder == null) { throw new RuntimeException("my_auth service not found"); } IMyAuthService service = IMyAuthService.Stub.asInterface(binder); String token = service.generateToken("com.example.app", 0); boolean valid = service.verifyToken(token);有一个重要细节：在系统应用进程中，ServiceManager.getService()是隐藏 API，普通 App 无法直接调用。你需要通过反射、或者完全在系统源码环境里编译才有权限。如果是做 ROM 定制，推荐的做法是写一个系统 API 类，比如MyAuthManager，内部持有IMyAuthService，通过Context.getSystemService(Context.MY_AUTH_SERVICE)返回给应用层。
这一步是很多初学者容易搞砸的地方。只把 Service 注册进系统，却没有提供对应的 Manager 类，上层应用根本无法通过标准方式访问，最终只能靠反射这种脆弱的方案。在系统定制项目里，正规形态一定是“AIDL 定义能力 + Manager 封装语义”，两者缺一不可。
4. 让服务在开机流程中可靠稳定地拉起
4.1 确定启动时机：早一点还是晚一点？
系统服务的启动时机直接决定了它的可用性。服务启动太早，依赖的核心服务还没就绪，初始化时可能拿不到数据；启动太晚，某些阶段性任务（比如开机广播、首次启动向导）已经错过，应用查不到服务。
我的习惯是把启动逻辑拆成两段：实例创建与注册放得早，依赖初始化放得晚。具体实现时，可以在MyAuthService构造函数里只做无依赖的准备工作，真正需要 PackageManager 或者用户信息的逻辑放到一个onBootCompleted或者惰性加载的 getter 里。
启动时机的选择还要看系统版本。Android 12 后，SystemServer 中很多服务的初始化迁移到了ActivityManagerService的系统就绪回调里。比如系统准备完成时调用的systemReady()，就是一个服务初始化的合适位置，因为此时核心服务基本都可用。如果你需要确保服务对所有应用可用，也可以监听Intent.ACTION_BOOT_COMPLETED广播，在系统整体启动完成后做进一步初始化。
这里要特别提醒一个坑：在startOtherServices()里addService之后，你的服务已经可以被应用层查询到了，但此时服务内部可能还没有准备好数据。如果应用在开机阶段就去调用，可能得到空值或者异常。所以对外部调用者来说，最好提供一个“服务是否就绪”的状态查询方法，或者干脆在初始化未完成时抛一个ServiceNotReadyException，这比返回错误数据要好得多。
4.2 服务保活与看门狗：谁在照顾它？
SystemServer 进程是 Android 的核心，一旦崩溃会触发重启。但你的 Java 服务如果只是 SystemServer 里的一个普通对象，并不会单独被守护。因此，你需要在服务内保证任何方法都不能 throw 不明异常到 Binder 框架，否则可能导致整个 system_server 进程崩溃，用户体验就是突然重启。
看门狗（Watchdog）机制是系统级服务必须考虑的一环。在 SystemServer 里，很多服务会在主线程上等待你注册的 monitor 回调，如果某个服务长期阻塞主线程，Watchdog 会杀掉系统进程并重启。所以，你的服务一定不要把耗时操作放到主线程里执行。
我在某项目里就遇到过这样一次事故：一个系统服务在处理请求时加了分布式锁，而这个锁等待了主线程空闲，结果锁一直拿不到，主线程阻塞超过 60 秒，触发 Watchdog，整个系统重启。排查发现是锁的顺序反了。后来我把所有耗时逻辑全部迁到独立线程池，主线程只做快速返回，问题才解决。
保活的核心原则归纳起来就三条：不要在 Binder 方法线程里做不可控的长任务；不要在主线程里等 Binder 调用结果；所有跨服务调用设置合理的超时。这三条做到了，服务稳定性就有大半了。
4.3 Selinux 策略：注册成功却访问被拒的元凶
这个坑几乎每个做系统服务的人都会踩。现象是：service list能看到你的服务，但客户端调用某个方法时，总是抛出Permission denied，而且 logcat 里没有任何 Java 异常，只有内核审计日志。
原因在于 Android 强制开启了 SELinux。servicemanager 在分发 addService 和 getService 时，会用 SELinux 规则判断调用者是否被允许注册或访问对应服务。默认情况下，你新加的my_auth服务并不在任何 sepolicy 规则里，普通应用进程（甚至系统进程之外的某些域）都没有访问权限。
你需要修改 sepolicy 文件，在 Android 源码的system/sepolicy/private/service_contexts或system/sepolicy/preferred/app_domain.te中增加授权。这里给出一个典型的配置思路：
# service_contexts 中声明服务名与类型 my_auth u:object_r:my_auth_service:s0 # 在对应 te 文件中允许客户端域访问 allow appdomain my_auth_service:service_manager find; allow appdomain my_auth_service:binder call;如果你的服务内部还要访问其他系统服务，同样需要补充 allow 规则。SELinux 模式是 Enforcing，所有规则必须写对，否则会在日志里留下avc: denied记录。排查这类问题时，快速定位的命令是：
adb shell dmesg | grep avcSELinux 是 Android 安全模型的重要防线，所以我建议你在做系统服务时就把权限最小化原则刻进习惯里：只给必要的域放开必要的操作，不要图省事直接allow * my_auth_service:*，那等于给所有攻击者开了口子。
5. 从应用层到底层的高频问题排查技巧
5.1 服务查询不到：先确认进程与注册状态
客户端调用ServiceManager.getService()返回 null，是新手最常遇到的问题。排查顺序我从经验中固定成了四步：
第一步，确认服务是否真的注册成功。执行adb shell service list | grep my_auth，如果没有输出，说明服务注册这一步有问题，直接去查 SystemServer 启动日志，看startMyAuthService有没有抛异常。
第二步，确认查询的进程身份。如果你在普通 App 里直接调用ServiceManager.getService()，会因为隐藏 API 限制抛出NoSuchMethodError或SecurityException；如果你通过反射绕过限制，还可能因为 ServiceManager 的“可访问域”不同拿到空。系统服务的查询必须来自有系统权限的进程。
第三步，确认 SELinux 规则。查看dmesg | grep avc，如果有 deny 记录，补规则重编。
第四步，也是最隐蔽的：如果你在服务初始化方法内部死锁或崩溃，addService可能已经执行但是服务对象状态异常。这种情况下服务名存在，Binder 代理也能拿到，但一调用就挂掉。查 SystemServer 的 tombstone 和 logcat 可以找到根因。
这套排查顺序可以覆盖我见过的绝大多数“查不到服务”的情况。实际项目中，我把这套顺序写进了团队内部的排查手册，效率提升非常明显。
5.2 客户端调用报 SecurityException：权限校验的边界
服务端自己做了 UID 校验，客户端在调用时如果被SecurityException拒绝，排查点反而简单：要么是你的服务端校验规则过严，要么是客户端进程的 UID 确实不符合要求。
有一种容易误伤的场景是 system_app 和普通应用的区别。很多系统服务允许 system uid 调用，但不允许普通应用调用。你在开发阶段可能用系统签名打包 App 测试，一切正常；但换到普通签名应用时就失败。此时要明确需求：这个服务到底允许哪些调用者？如果只允许系统应用，普通应用就该走另外的授权通道，而不是硬调。
我在开发时习惯在服务端打印调用者信息：
Slog.d(TAG, "Calling uid: " + Binder.getCallingUid() + ", pid: " + Binder.getCallingPid());日志里一眼就能看出来调用方是谁，配合adb shell ps查进程信息，很快就能定位原因。
5.3 跨进程对象传递：Parcelable 序列化的隐藏规则
如果你的服务接口需要传递自定义对象，必须让它实现 Parcelable 并手写CREATOR。这里有一个容易忽略的点：自定义对象里嵌套了 Binder 对象时，内存跨进程的语义会发生变化。客户端把对象传给服务端时，对象中的 Binder 会变成代理对象；反过来也一样。这个自动转换机制虽然方便，但在复杂对象中容易造成误判，比如两个进程都维护同一个服务接口的引用，你以为它们是等价的，实际上跨进程后变成了两个代理句柄。
项目里遇到过：客户端向服务端注册一个回调监听器，服务端存进 ArrayList，客户端进程被杀后，服务端再回调时发现 Binder 已经死掉。逻辑上这是正常的，但因为没有监听 BinderDeath，回调失败导致服务端积压大量无用的监听器。后来我在注册回调时增加了linkToDeath处理，并在回调异常时移除对应监听器，问题才解决。
如果你在服务接口中需要使用 PendingIntent、ResultReceiver 这类自动 parcel 的核心组件，比自定义 Parcelable 更安全，建议优先使用。它们携带着系统级的跨进程能力，不需要你手动处理序列化边界。
5.4 开机时间与启动稳定性：日志要打得巧妙
系统服务做久了你会发现，真正影响用户体感的是开机速度。每多一个服务，系统启动时就要多做一次序列化、注册、初始化。如果服务初始化里有耗时的文件读取，或者跨服务调用的等待，开机时间可能被拉长好几秒。
有一个实际处理过的例子：某同事写的服务在初始化时要把历史令牌文件全部加载进内存，数据量有几十万条，启动耗时达到 4 秒多。后来改成懒加载，只在第一次生成令牌时才读取文件，开机时间立刻恢复正常。这类“启动时多做了一点”的积累，每个服务都加一点，系统就会肉眼可见地变慢。
调试启动问题时，logcat 里按时间过滤是基本功：
adb logcat -b all -t 3000 | grep SystemServerSystemServer 的启动日志会把每个服务启动的消耗打印出来，对照自己的服务启动时间，能判断是不是瓶颈。
6. 实战心得与几个值得坚持的习惯
做完几个真实项目后，我把自己反复吃过的亏总结成几条原则，写在这里，算是对后来者的一个提醒。
第一，接口设计要克制。Java 系统服务一旦上线，接口变化会影响所有老客户端，所以 AIDL 方法尽量少而精，参数尽量用稳定的基本类型。不要因为“系统是我自己的”就随意改动接口签名，排障成本会指数上升。
第二，日志要有分级意识。服务刚上线时，把所有关键路径的 log 打全，包括方法进入、参数摘要、权限判定结果、耗时统计。等稳定后，把高频路径调成 verbose 级别，避免日志风暴拖慢系统。我用过的方式是在服务内增加一个可动态配置的 log tag，通过系统属性控制打印级别，这样在生产环境也能临时打开详细日志，不需要重新编译。
第三，凡是跨进程调用，都要考虑“对方挂了”的情况。Binder 调用返回DeadObjectException时，你的服务要有重试或者降级方案，不能让上层异常崩溃。在实现回调类服务时，一定要注册 Binder 死亡监听，及时清理无效引用。
第四，新增系统服务不是终点，配套的测试才是。至少要做到：接口的单元测试覆盖所有方法；跨进程调用用独立测试应用验证；长时间压测检查内存泄漏和回调堆积；真实设备上开关机循环 20 次以上确认不会影响系统重启。这些测试如果缺少，服务活了但系统死了的情况绝对会发生。
添加 Java 系统服务这条路，原理层面并不神秘，无非是 AIDL、Stub、ServiceManager、SystemServer 这几个关键词串起来；但真正把它做成一个稳如磐石的系统能力，靠的是对权限边界、启动时序、SELinux、稳定性细节这些“非代码”层面的敬畏。希望这篇专题能帮你少走一些弯路，也希望你也能在自己的定制系统里，亲手把一个服务从零推到系统级，那份掌控感，确实是普通 App 开发给不了的。
