1. 课程导入
Android 系统服务（System Service）是 Android 框架层的中枢神经。应用开发者熟悉的 ActivityManager、PackageManager、WindowManager、AudioService、LocationManager 等能力，本质上都是通过 Binder 跨进程调用到 system_server 中运行的系统服务。理解并掌握系统服务开发，意味着从“写 App”跨越到“改平台”，能够定制系统行为、扩展框架能力、优化整机体验。
一、学习目标：从调用者到实现者
本课程的目标不是让读者记住某个 API，而是建立一套可复用的系统服务开发方法论。完成学习后，应达到以下四个层次：
- 认知层：说清
system_server、Binder、ServiceManager、AIDL、SystemServiceRegistry 之间的关系，理解系统服务为何必须跨进程。 - 实现层：能独立编写一个带 AIDL 接口的系统服务，完成注册、启动、权限校验与客户端调用。
- 集成层：能把服务接入
SystemServer启动流程，配置 SELinux 策略、init.rc 与 seapp_contexts，使其在真实设备上稳定运行。 - 调优层：能通过 dumpsys、logcat、systrace、Binder 统计等手段定位死锁、超时、权限拒绝与内存泄漏问题。
二、核心概念：五个必须打通的术语
系统服务开发涉及大量框架术语，初学阶段最容易混淆的是“服务”一词的多义性。Android 中至少有四种“服务”：应用组件 Service、系统服务 System Service、Native 守护进程、以及 Binder 服务实体。本课程聚焦第二种，但必须借助第三、第四种来落地。
| 概念 | 所在位置 | 作用 | 典型代表 |
|---|---|---|---|
| SystemServer | system_server 进程 | 系统服务启动与生命周期宿主 | SystemServer.java |
| Binder | 内核 + 用户态 | 跨进程通信与线程池调度 | /dev/binder |
| ServiceManager | servicemanager 进程 | Binder 服务的注册与查询中心 | addService / getService |
| AIDL | 接口定义层 | 生成 Stub 与 Proxy，规范 IPC 契约 | IFoo.aidl |
| SystemServiceRegistry | framework 层 | 把 Binder 服务映射为 App 可用的 Manager | getSystemService |
这五个概念构成一条完整的调用链：App 调用 getSystemService，经 SystemServiceRegistry 拿到 Manager，Manager 通过 AIDL Proxy 跨 Binder 到达 system_server 中的 Stub，最终由服务实现类处理。任何一环断裂，服务都不可用。
三、整体知识框架：四层结构
为了便于学习，我们把系统服务开发划分为四个层次，自下而上依次是内核与驱动层、Native 与 Binder 层、Java 框架层、应用接口层。下图展示了各层的关键对象与数据流向。
学习时应沿着这条链路自顶向下或自底向上反复走通。只写 AIDL 而不懂 Binder 线程模型，会在并发场景踩坑；只懂 Binder 而不懂 SystemServer 启动顺序，服务可能因依赖未就绪而崩溃。
四、方法流程：一个系统服务的诞生路径
新增一个系统服务通常遵循固定流程，可概括为“定义接口、实现服务、注册启动、暴露接口、验证调优”五步：
- 定义 AIDL：在
frameworks/base/core/java/android/os/下新增IMyService.aidl，声明方法、参数方向与返回值。 - 实现服务：编写
MyService extends IMyService.Stub，在方法内完成权限检查、参数校验与业务逻辑。 - 注册启动：在
SystemServer.startOtherServices()中创建实例并调用ServiceManager.addService()。 - 暴露接口：在
SystemServiceRegistry中注册MY_SERVICE与对应 Manager，供 App 获取。 - 验证调优：编译刷机后，用
adb shell service list、dumpsys验证注册与运行状态。
// 典型注册片段（SystemServer.java）
try {
ServiceManager.addService(Context.MY_SERVICE, new MyService(context));
Slog.i(TAG, "MyService started");
} catch (Throwable e) {
Slog.e(TAG, "Failed to start MyService", e);
}
五、案例场景：为什么需要自定义系统服务
假设产品需要为所有 App 提供统一的“设备使用时长统计”能力，且要求数据不可被应用篡改、统计逻辑对应用透明。若用普通 App 实现，每个应用都要自行采集，既重复又不可信。正确做法是新增一个系统服务：由框架统一采集、存储与鉴权，应用只通过 Manager 查询结果。这类需求在定制 ROM、车机、教育平板、企业设备中非常普遍，也是系统服务开发最典型的落地场景。
六、常见误区与复盘
初学者最容易陷入以下误区，提前规避能节省大量调试时间：
- 把应用 Service 当系统服务：两者生命周期、进程模型、权限体系完全不同，不能混用。
- 忽略权限校验：系统服务运行在高权限进程，若不做
checkCallingPermission，会造成严重安全漏洞。 - 忘记 SELinux 策略：服务注册成功但调用被拒，往往是
avc: denied日志在提示策略缺失。 - 在 SystemServer 中做耗时操作：会拖慢开机，甚至触发 Watchdog 重启。
- 只测正常路径：并发调用、Binder 死亡、空参数等异常路径才是稳定性关键。
本课程后续将围绕上述框架逐层展开：先讲 Binder 与 ServiceManager 的通信底座，再讲 SystemServer 启动与生命周期，然后进入 AIDL 接口设计、权限与 SELinux 集成，最后通过完整实战项目把知识串成可交付的系统服务模块。掌握这条主线，就能在 Android 平台开发中拥有真正的框架层改造能力。