Chapter 160: Android system_server Service Map

读 Android 系统行为时，system_server 是第一张需要建立的服务地图。一个应用启动页面、解析 Intent、创建窗口、申请 WakeLock、接收广播、触发 ANR，表面上来自不同 Framework API，最终会汇入 system_server 内的一组 Java system service。读者读完本章后，应能把一个 App 可见现象定位到对应服务、Binder 入口、权限检查点、状态所有者和失败结果。

本章用一个贯穿行为串起服务地图：用户点击通知打开应用页面，应用进程被拉起，目标 Activity 被解析，窗口被加入显示系统，页面执行期间申请短时 WakeLock，随后主线程阻塞触发 ANR。这个行为同时经过 PackageManagerService、ActivityManagerService、WindowManagerService、PowerManagerService、Binder 注册模型和 Watchdog / ANR 链路。它覆盖 system_server 最常见的责任边界。

system_server 的核心判断是：它保存系统级状态，代理应用访问敏感能力，并把跨进程请求转成可审计、可排序、可拒绝的系统操作。Android 公开 API 文档能看到 ActivityManager 负责活动、服务和进程信息，PackageManager 负责包与权限状态，WindowManager 负责窗口加入与更新，PowerManager.WakeLock 负责设备保持唤醒的声明；AOSP 源码中的 SystemServer、AMS、PMS、WMS、PMS 电源服务实现这些公开表面背后的服务所有权。本章以 Android 15 / 16 代际的公开文档和 AOSP 主线概念为边界，OEM 定制、GMS 扩展和厂商服务会增加服务数量，但不会改变这张核心责任图。

下面的图先给出本章的贯穿路径。图中每个节点代表一个责任边界，后续小节按这些边界展开。

这条路径体现了 system_server 的读取顺序：先确认 App 发起了什么请求，再找公开 Framework manager，再找 Binder 服务入口，再判断哪一个服务持有状态，最后看拒绝、阻塞、重启和日志发生在哪个边界。

160.1 system_server 作为 Java System Service 宿主进程

system_server 是 Android 中承载大量 Java system service 的进程。它由 Zygote 派生后启动 SystemServer 主类，按阶段创建、注册、启动核心服务。这里的“宿主进程”表示多个服务共享一个进程空间、线程资源、Binder 线程池和启动时序；服务本身有各自对象、锁、Handler、状态表和 Binder 接口，但进程级故障会扩散到系统级故障。

这层设计解决的是系统能力集中编排问题。Activity 启动、包扫描、窗口管理、电源状态、输入策略、权限授予等能力需要共享用户、包、进程、显示和电源状态。若每个能力分散到独立进程，跨服务一致性会依赖大量 IPC 事务；集中在 system_server 后，服务之间可以通过进程内对象和明确启动阶段建立依赖关系，再把对 App 的外部入口暴露成 Binder service。

启动顺序是阅读 system_server 的第一条线索。早期服务负责基础设施，例如日志、配置、包信息、权限和进程管理；随后启动图形、输入、网络、电源、通知、存储、账户等服务；最后进入 systemReady 之类的准备阶段，让服务看到系统已经完成关键初始化。这个顺序决定了依赖方向：Activity 管理需要包信息，窗口管理需要显示和输入基础状态，电源管理需要电池和设备状态，通知打开页面时需要 AMS、PMS 和 WMS 都处于可用状态。

以本章贯穿行为为例，用户点击通知打开应用页面时，system_server 内部至少要完成四件事。PMS 提供目标组件和包状态，AMS 决定进程和 Activity 生命周期，WMS 接收窗口 token 和窗口层级，PowerMS 判断页面持有 WakeLock 后设备能否继续保持运行状态。应用看到的是“页面打开并保持亮屏”，系统看到的是多个服务在同一进程内按状态依赖协作。

集中宿主也带来进程风险。某个服务持有全局锁时间过长、Binder 线程耗尽、主线程消息长时间不返回，都会影响同进程内的其他服务。Android 因此把低延迟、强隔离或 native-heavy 能力放在后续 Chapter 要讲的 native service 和 daemon 中，例如图形合成、音频混音、媒体编解码、相机和传感器服务。system_server 负责 Java Framework 层的大部分策略所有权，底层数据流仍会跨到 native service、HAL、driver 和 kernel。

可以用下面的最小地图记住 system_server 的责任范围：

责任维度	典型服务	保存的状态	App 可见结果
组件和进程	ActivityManagerService	进程记录、任务、组件生命周期、OOM adj	启动、切后台、服务被限制、进程被回收
包和权限	PackageManagerService	安装包、签名、权限、组件声明、用户安装状态	Intent 解析失败、权限拒绝、组件不可见
窗口和显示策略	WindowManagerService	Window token、z-order、focus、display policy	窗口显示、焦点变化、遮挡、旋转和动画
电源和设备状态	PowerManagerService	WakeLock、屏幕状态、睡眠唤醒、电源策略	亮屏、息屏、后台任务受限、耗电归因
稳定性诊断	Watchdog / ANR 链路	监控线程、阻塞点、错误报告	ANR 弹窗、系统重启、bugreport 证据

阅读源码或日志时，system_server 的入口可以从 AOSP 的 SystemServer.java 开始，再沿服务类跳转。公开 API 层可以用 Android Developers 的 ActivityManager、PackageManager、WindowManager 和 PowerManager.WakeLock 作为行为表面。

160.2 ActivityManagerService 与进程 / 组件生命周期管理

ActivityManagerService 通常简写为 AMS，它是 system_server 中管理进程、Activity、Service、Broadcast、ContentProvider 和任务栈的核心服务。它的工作定义是：接收来自 Framework 的组件请求，读取包与权限状态，决定组件是否可以启动，安排目标进程，维护生命周期状态，并把进程优先级反馈给内存回收策略。

在贯穿行为中，通知点击触发 startActivity 后，AMS 先关心请求者身份、目标 Intent、用户 ID、任务栈归属和后台启动限制。请求者身份通过 Binder 调用携带，包和组件信息来自 PMS，前后台与可见性状态来自 AMS 自己保存的进程和任务记录。AMS 根据这些状态决定复用已有进程、拉起新进程、复用已有任务，或者因后台启动限制和权限边界返回失败。

进程优先级是 AMS 连接用户体验与内存策略的关键状态。前台 Activity、可见 Activity、前台服务、后台服务、缓存进程对应不同 OOM adj 区间。AMS 持有进程记录并持续更新进程重要性，底层 low memory killer 或相关内存回收策略根据这些优先级决定回收顺序。用户看到的“切回应用是否重载”，背后往往是 AMS 生命周期状态和内存压力共同输出的结果。

组件生命周期也由 AMS 统一编排。Activity 的 resume、pause、stop，Service 的启动和绑定，Broadcast 的分发和超时，ContentProvider 的发布和引用计数，都需要一个全局状态表。这个全局表让系统能处理交叉场景：一个 Activity 启动时需要先暂停当前 Activity；一个前台服务启动时需要通知和权限状态；一个 provider 访问可能要求目标进程先启动并完成 provider publish。

AMS 和 WMS 的协作在页面启动中最容易观察。AMS 负责“哪个 Activity 应该进入前台”，WMS 负责“哪个窗口可以获得层级、焦点和输入目标”。Activity 生命周期已经进入 RESUMED 并不等于窗口已经完成绘制；窗口可见也需要 app 进程、ViewRoot、Surface、输入和动画状态配合。分析启动慢时，先看 AMS 的组件调度，再看 WMS 的窗口绘制等待，可以把进程启动慢、包解析慢、窗口等待和应用主线程阻塞分开。

AMS 的失败表现有三类。第一类是启动拒绝，例如权限、用户、组件导出状态或后台启动策略导致请求失败。第二类是生命周期超时，例如 Activity pause、Service start、Broadcast receive 等阶段长时间没有完成。第三类是进程状态变化，例如后台进程因内存压力被回收，或者 crash 后由 AMS 记录错误状态并决定重启策略。公开 ActivityManager 文档说明它能提供 activities、services 和进程相关信息，并提示部分接口主要用于调试和面向用户的进程管理 UI；这也反映了 AMS 的真实角色是系统所有者，App 能看到的只是受限观察窗口。

可复用判断顺序如下：遇到“页面没起来、服务没活、广播没到、进程被杀”这类现象，先确定 App 请求类型，再确定 AMS 是否接收到了 Binder 调用，再查目标组件和用户状态，再看进程是否存在和优先级是否足够，最后看 WMS、PMS、PowerMS 或底层服务是否提供了拒绝原因。这个顺序能把生命周期问题从包安装、权限、电源和窗口问题中分离出来。

160.3 PackageManagerService 与安装包、签名、权限、组件解析

PackageManagerService 通常简写为 PMS，它负责把 APK、签名、权限声明、组件声明、安装状态和用户维度状态整理成系统可查询的包数据库。它的工作定义是：在启动和安装阶段建立包事实，在运行阶段为其他服务提供组件解析、权限判断、签名关系和安装可见性结果。

在贯穿行为中，AMS 收到 startActivity 后不会直接相信 App 传入的类名。AMS 需要调用 PMS 解析 Intent，确定目标 Activity 是否存在、是否属于当前用户、是否导出、是否可见、是否匹配 action / category / data，以及调用者是否满足权限要求。这个步骤把“应用想打开某页面”转成“系统确认某个组件可以被当前调用者启动”。

PMS 的输入来自安装包和系统分区。启动时，PMS 扫描系统应用、vendor / product 分区中的预装应用以及用户安装应用，读取 manifest 中的组件、权限、feature、uses-library、intent-filter 和签名信息。安装或更新时，PMS 验证包结构、签名连续性、版本和安装策略，然后更新包状态。多用户设备上，同一个包还可能有不同用户的安装、禁用、隐藏和权限状态。

权限授予是 PMS 与权限管理体系交叉最密的区域。普通权限、危险权限、签名权限和特殊访问各有不同授予路径。PMS 保存包声明与基础授权事实，运行时访问通常还会经过 Context.checkPermission、AppOps、目标 system service 的二次检查和用户设置。公开 PackageManager.checkPermission 文档指出它返回某包某权限是否已授予，并提示一般访问检查应使用 Context.checkPermission 系列 API。这说明 PMS 的权限结果是事实来源之一，最终授权仍要结合调用者身份、用户、AppOps 和服务内策略。

组件解析直接影响用户可见行为。一个通知点击后页面打不开，可能来自目标 Activity 未安装、被当前用户禁用、intent-filter 不匹配、组件未导出、调用者无权限、包处于 suspended 状态，或者跨 profile 策略拒绝。对 App 来说，这些可能表现为 ActivityNotFoundException、SecurityException、返回失败结果或系统静默丢弃某些后台请求。对系统分析来说，PMS 负责回答“目标是否存在并可被解析”，AMS 再回答“当前时刻是否允许启动”。

签名关系决定了更高信任级别。签名权限、shared UID 历史兼容、系统应用权限、privileged permission 白名单、安装来源和更新关系都依赖签名和分区事实。现代 Android 对 shared UID 和特权权限有更多限制，具体行为受 Android 版本、目标 SDK、设备配置和 OEM 策略影响。本章只使用稳定判断：PMS 是签名和包状态的系统事实表，任何依赖包身份的服务都会回到这个事实表。

定位 PMS 问题时，可以按五步走。第一步看包是否安装在目标用户下。第二步看组件声明和 intent-filter 是否匹配。第三步看导出状态、权限声明和签名关系。第四步看包是否被禁用、隐藏、suspended 或受 profile 策略限制。第五步把 PMS 返回结果交给 AMS、WMS 或目标服务继续判断。这个顺序能把“目标不存在”和“目标存在但当前策略拒绝”分开。

160.4 WindowManagerService 与窗口层级、焦点、显示策略

WindowManagerService 通常简写为 WMS，它负责窗口 token、窗口层级、焦点、输入目标、显示策略、配置变化和窗口动画。它的工作定义是：接收来自应用和 AMS 的窗口状态变化，建立窗口与 Activity、显示设备、输入系统和合成系统之间的关系，并决定哪个窗口可以显示、获得焦点和接收输入。

在贯穿行为中，AMS 决定目标 Activity 进入前台后，会与 WMS 建立 Activity 对应的窗口 token。应用进程随后通过 ViewRoot 链路向 WMS 添加窗口，公开 WindowManager.addView 行为表面体现为“把 View 和 LayoutParams 加入窗口”。WMS 检查 token、窗口类型、权限、显示 ID、层级关系和布局参数，再把窗口状态交给 Surface / input / animation 相关链路。

窗口 token 是 WMS 的核心边界。Activity 窗口需要合法 Activity token，系统 overlay 需要对应权限和窗口类型，输入法窗口需要输入法服务身份，状态栏、导航栏和系统 UI 窗口由系统服务持有特殊层级。token 让 WMS 能判断一个窗口属于哪个组件、哪个用户、哪个 display，以及它是否有资格进入特定层级。

z-order 和 focus 决定用户看到哪个窗口、操作哪个窗口。z-order 是窗口在显示层级中的相对顺序，focus 是输入事件的目标归属。一个 Activity 已经启动但窗口被其他系统窗口覆盖，用户看到的是遮挡；一个窗口可见但没有焦点，用户点击或键盘输入会进入另一个目标。WMS 要和 input dispatcher、display policy、system UI、动画系统协同，才能给出最终可见结果。

显示策略把物理屏幕状态引入窗口管理。旋转、刘海 / cutout、状态栏和导航栏占用、锁屏、分屏、画中画、外接显示、折叠屏 posture、亮度和刷新率相关策略都会影响窗口布局和显示。WMS 保存策略结果，应用收到的是配置变化、insets、布局大小变化或窗口可见性变化。分析“页面显示尺寸异常、软键盘遮挡、外屏没有窗口”时，WMS 是第一责任服务。

WMS 与 AMS 的边界需要分清。AMS 管 Activity 生命周期和任务归属，WMS 管窗口可见性、焦点和显示层级。页面启动慢可能卡在 AMS 拉进程，也可能卡在 WMS 等待窗口绘制；输入无响应可能来自 App 主线程阻塞，也可能来自焦点目标错误；窗口添加失败可能来自 token 无效，也可能来自权限和窗口类型不匹配。WindowManager.BadTokenException 这类公开异常正是 token 边界被拒绝后的 App 可见结果。

WMS 的排查顺序可以固定为：先看窗口类型和 token，再看目标 display 与用户状态，再看 z-order 和 focus，再看输入目标，再看动画和绘制等待。这个顺序能把“组件启动成功但窗口不可见”拆成具体系统边界。

160.5 PowerManagerService 与电源、WakeLock、设备状态

PowerManagerService 可以简写为 PowerMS，它负责 WakeLock、屏幕点亮与关闭、设备 sleep / wake、battery saver、idle、thermal 回调和电源相关状态协调。它的工作定义是：把 App 和系统组件的唤醒诉求、用户交互、传感器状态、电池状态和温控状态合并成设备当前电源状态。

在贯穿行为中，页面打开后 App 申请短时 WakeLock，公开 PowerManager.WakeLock 文档说明 wake lock 是应用声明设备需要保持运行的一种机制，使用时需要 android.permission.WAKE_LOCK，并通过 acquire() 获取、release() 释放。PowerMS 接收这个 Binder 请求后，需要记录持有者、tag、uid、类型、WorkSource、超时和引用计数，再把它合并进全局电源状态。

WakeLock 的系统意义是“声明某类运行需求”，最终设备状态仍由 PowerMS 与其他策略共同决定。屏幕亮灭、CPU 保持运行、Doze、App standby、battery saver、thermal throttling、低电量模式、用户手动息屏、接近传感器和系统 idle 状态都会影响结果。App 看到 acquire() 调用成功，只能说明 PowerMS 接受了这次声明；它无法单独决定整机所有功耗策略。

PowerMS 连接多个责任主体。AMS 会提供前后台、uid 活跃性和进程状态；BatteryStats 或相关统计链路用于耗电归因；DisplayPowerController 相关链路控制屏幕；Thermal 服务提供温控状态；Alarm、Job、Network 等服务会参考省电策略决定后台工作。PowerMS 因此是一个策略汇聚点，单独看 App 代码无法解释全部电源行为。

页面场景中的失败表现有几种。没有声明 WAKE_LOCK 权限会导致请求失败或抛出安全异常；持有 WakeLock 后没有及时释放会造成耗电归因和后台限制；设备进入省电或 idle 状态后，后台任务、网络和 alarm 可能被延迟；热状态升高后，系统可能降低性能、限制显示亮度或调整工作调度。用户看到的是掉电、发热、后台延迟或屏幕行为变化，系统内部则是 PowerMS、AMS、JobScheduler、AlarmManager 和 thermal 链路共同输出。

PowerMS 的判断顺序是：先确认 App 是否真的持有 WakeLock，再确认持有者 uid、类型和超时，再看设备当前交互状态和屏幕状态，再看 battery saver / idle / thermal 状态，最后把结果映射到 App 可见现象。这样可以把“应用声明唤醒需求”与“系统最终选择电源状态”分开。

160.6 system_server 与 Binder Service 注册模型

system_server 对 App 暴露能力主要依赖 Binder service 注册模型。服务启动后把 Binder 接口注册到 ServiceManager，Framework manager 通过服务名查找 Binder handle，App 进程中的 manager 对象再把 Java 方法调用转成 Binder transaction。这个模型让应用无需知道服务对象地址，只需要通过稳定服务名和 AIDL / Binder 接口完成跨进程调用。

注册模型可以按四个阶段阅读。第一阶段是创建服务对象，例如 AMS、PMS、WMS、PowerMS。第二阶段是向 ServiceManager 注册服务名和 Binder 实现。第三阶段是客户端通过 Context.getSystemService、manager 单例或内部 API 获取代理。第四阶段是 Binder 驱动传递调用者 pid / uid、参数 Parcel 和返回值，服务端在方法内执行权限、AppOps、用户和状态检查。

权限执行点通常在服务端。App 调用 ActivityManager、PackageManager、WindowManager 或 PowerManager 的 public API 时，客户端 Framework 会做参数整理和少量前置检查，但真正可信的身份来自 Binder 事务中的调用者 uid / pid。服务端需要基于这个身份查询 PMS、AppOps、用户状态、SELinux 上下文或内部白名单，然后决定接受、拒绝、延迟或降级处理。研究 Android system service 安全时，Binder 接口就是关键边界，因为绕过 public API 直接打 Binder 也必须被服务端校验挡住。

服务查找失败和服务死亡有不同影响。若 ServiceManager 中没有目标服务，客户端会拿不到代理或在调用时失败；若 system_server 内某个 Java 服务对象内部异常，影响范围取决于异常是否被捕获、是否阻塞关键线程以及是否损坏共享状态；若整个 system_server 进程死亡，init / zygote 管理链路通常会导致系统服务重启，用户体验接近系统软重启。Binder death recipient 可以感知远端进程死亡，但普通 App 对多数核心服务死亡没有恢复控制权。

在贯穿行为中，startActivity、resolveActivity、addView、acquire WakeLock 都是不同服务名背后的 Binder 调用。AMS 依赖 PMS 解析包，WMS 依赖 AMS 提供 token，PowerMS 依赖 PMS / AppOps / uid 状态判断权限和归因。Binder 模型让这些调用都具有调用者身份，也让服务之间可以通过接口形成清晰责任链。

下面的 Mermaid 图用于固定 Binder 注册与调用边界。重点是服务端校验位置和死亡影响范围。

这张图的读取方式是：客户端 manager 只是调用入口，ServiceManager 只提供名字到 Binder handle 的查找，服务对象才是系统状态和策略执行点。排查时，先确定服务名和 Binder 接口，再看服务端方法使用了哪些身份和状态表，最后把失败映射成异常、返回码、超时或用户可见 UI。

160.7 system_server Watchdog、ANR 与系统稳定性

Watchdog 和 ANR 链路是 system_server 稳定性保护的两个观察入口。Watchdog 关注系统服务线程和关键锁是否长时间卡住，ANR 关注应用主线程、广播、服务、输入分发和 provider 等操作是否超过系统等待时间。它们的共同目标是把“长时间没有返回”转成可诊断状态，并在必要时触发错误报告、杀进程或系统服务重启。

在贯穿行为中，页面打开后应用主线程执行耗时操作，输入事件无法被处理。WMS / input 链路会观察到输入目标长时间不响应，AMS 参与生成 ANR 记录，系统收集主线程堆栈、进程状态、CPU 信息和相关日志，最后用户可能看到“应用无响应”对话框。这里的责任链是：App 主线程阻塞是直接原因，AMS 记录应用生命周期和错误状态，WMS / input 提供输入等待证据，system_server 负责诊断和处置。

ANR 类型需要按触发入口区分。输入 ANR 来自窗口焦点目标没有及时处理输入；Broadcast ANR 来自 receiver 执行超时；Service ANR 来自 service 生命周期回调超时；ContentProvider ANR 来自 provider 发布或访问等待超时；Activity 启动相关等待则会表现为启动超时、窗口绘制等待或应用无响应。不同入口对应不同服务和日志线索，统一写成“卡了”会丢失责任边界。

Watchdog 更偏向 system_server 自身健康。它会监控关键线程、Handler、锁和服务检查器。如果 system_server 主线程、Binder 线程、UI 相关线程或某些关键服务长时间无法响应，Watchdog 会收集诊断信息，并可能触发 system_server 重启。普通 App ANR 通常处理目标 App；system_server Watchdog 触发后影响系统级可用性。

主线程阻塞和 Binder 饥饿是两个高频原因。App 主线程做磁盘 I/O、网络等待、锁等待或大对象计算，会触发 App ANR；system_server 内部持有全局锁再做慢操作，会阻塞其他服务调用；Binder 线程池耗尽会让新事务排队，表现为多个无关 API 同时慢。阅读日志时，要区分“服务端未返回”和“客户端主线程等待服务端返回”，两者都会造成界面无响应，但修复位置完全不同。

诊断证据可以按层级组织。App 层看主线程堆栈、生命周期回调和耗时任务；Framework 层看 AMS / WMS / PowerMS 相关日志；Binder 层看调用等待、线程池和服务端阻塞；system_server 层看 Watchdog trace、关键锁和服务检查器；kernel 层看调度、I/O 和内存压力。这个证据顺序能把 App 代码问题、系统服务阻塞和设备资源压力区分开。

本章的最终判断框架可以收束为一句话：system_server 服务地图把 App 可见现象拆成“哪个服务持有状态、哪个 Binder 接口接收请求、哪个策略点作出判断、哪个稳定性链路记录失败”。读 Android 行为时，先画出这张服务地图，再进入具体源码、日志或系统 API，才能把页面启动、包解析、窗口显示、电源保持和 ANR 这些现象放回同一条责任链。

最小自检任务

给定场景：一个应用收到通知后打开目标 Activity，页面短暂白屏，随后出现 ANR；日志中还能看到该应用申请过 WakeLock。请写出从通知点击到 ANR 的最小系统路径，并指出 AMS、PMS、WMS、PowerMS、Binder 注册模型和 Watchdog / ANR 链路各自应承担的判断问题。

答案要点

最小路径应从 App 或系统通知入口进入 AMS。AMS 接收启动请求，基于调用者身份、目标用户、后台启动策略和当前任务状态决定是否调度 Activity。AMS 需要向 PMS 查询目标组件是否存在、是否匹配 Intent、是否导出、调用者是否满足权限和用户状态要求；PMS 回答组件解析和包身份问题。

Activity 调度后，AMS 负责目标进程启动或复用，并维护组件生命周期。WMS 接收 Activity 对应的窗口 token，检查窗口类型、token、display、z-order、focus 和输入目标。白屏需要分别检查进程启动、Activity 生命周期、窗口添加、首帧绘制和应用主线程阻塞，不能把所有等待归到单一服务。

WakeLock 通过 Framework manager 和 Binder 代理进入 PowerMS。PowerMS 检查权限、uid、tag、类型、超时、WorkSource、电源状态、battery saver、idle 和 thermal 状态。它回答应用是否声明唤醒需求，以及这个声明如何进入设备电源状态；它不解释 Activity 生命周期和窗口绘制。

Binder 注册模型负责把客户端 manager 连接到 system_server 中的服务对象。ServiceManager 提供服务查找，Binder 事务携带调用者身份，服务端方法执行可信权限和状态检查。排查时应确认请求打到了哪个服务名、哪个 Binder 接口、服务端根据哪些身份和状态拒绝或接受。

ANR 判断由 WMS / input、AMS 和诊断链路共同形成。输入 ANR 关注焦点窗口是否及时处理输入，AMS 记录应用进程和组件错误状态，诊断输出主线程堆栈、CPU、锁等待和相关日志。若 system_server 自身关键线程卡住，Watchdog 会进入系统服务健康检查路径，影响范围高于单个 App ANR。

本章知识点总结

• 宿主进程：system_server 承载大量 Java system service，共享进程、线程和启动时序，集中保存系统级状态。
• 启动顺序：服务创建和 systemReady 阶段决定依赖方向，包、权限和进程管理通常先于窗口、电源和高层策略。
• AMS 边界：AMS 管进程、任务、组件生命周期、前后台状态和 OOM adj，是启动、后台限制和进程回收的核心服务。
• PMS 边界：PMS 管包扫描、签名、权限事实、组件声明和 Intent 解析，是包身份和组件可见性的事实表。
• WMS 边界：WMS 管窗口 token、z-order、focus、input target、display policy 和动画，是窗口可见和输入归属的状态所有者。
• PowerMS 边界：PowerMS 管 WakeLock、屏幕状态、sleep / wake、battery saver 和 thermal 回调，把唤醒声明合并进电源策略。
• Binder 注册：核心服务通过 ServiceManager 注册，客户端通过 manager 和 Binder proxy 调用，服务端依据 Binder 身份执行可信检查。
• 权限检查点：客户端 API 只能整理请求，可信权限、AppOps、用户和状态检查应在服务端 Binder 方法内完成。
• 死亡影响：单个服务对象异常、关键线程阻塞和整个 system_server 死亡对应不同影响范围，后者接近系统软重启。
• ANR 入口：输入、广播、服务、provider 和 Activity 等等待路径对应不同 ANR 证据，AMS 与 WMS 提供主要系统侧状态。
• Watchdog 入口：Watchdog 监控 system_server 关键线程、锁和服务检查器，触发后影响系统级可用性。
• 判断顺序：分析 App 可见现象时，先找请求入口，再找服务所有者，再看权限和状态检查，最后用失败表现定位责任边界。