核心服务顺序

SystemServer 的服务顺序不是“越重要越早”，而是由数据和能力依赖决定。Installer 必须在 PMS 前准备目录；ATM 先于 AMS 提供 task/window lock；DisplayManager 和默认 display phase 先于 PMS；UsageStats 启动后立即把 LocalServices 接口注入 AMS；WMS 创建后回填 AMS，InputManager 再取得 WMS callback，DisplayManager 最后确认 Window/Input ready。

本文把这些依赖边串成一张可反向排查的图。具体服务内部算法仍回到各自模块文章。

1. 四组只是外层顺序

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java

startBootstrapServices(t);
startCoreServices(t);
startOtherServices(t);
startApexServices(t);

四组保证粗粒度顺序，但组内仍有对象注入、LocalServices 查询、boot phase、Future 等细粒度同步。只看到一个服务属于 Bootstrap/Core 并不足以判断它何时真正可用。

2. Installer到PMS

Installer installer = mSystemServiceManager.startService(
        Installer.class);

mActivityManagerService.setInstaller(installer);

mPackageManagerService = PackageManagerService.main(
        mSystemContext, installer,
        domainVerificationService,
        mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF);

Installer 实例先保存，再分别注入 AMS 和 PMS。它的 consumer 不通过 ServiceManager 查询，而是直接持有 Java 实例。若 installd/目录准备失败，AMS/PMS 构造即使继续也缺少文件系统操作能力，因此该边属于硬依赖。

3. ATM到AMS

ActivityTaskManagerService atm =
        mSystemServiceManager.startService(
                ActivityTaskManagerService.Lifecycle.class)
                .getService();

mActivityManagerService =
        ActivityManagerService.Lifecycle.startService(
                mSystemServiceManager, atm);
mWindowManagerGlobalLock = atm.getGlobalLock();

ATM 先建立 activity/task 状态和 global lock，AMS 再持有 ATM 实例。后续 WMS 也接收 mActivityManagerService.mActivityTaskManager，因此 ATM 是 AMS/WMS 间共享状态的早期 owner。

4. Display到PMS

mDisplayManagerService = mSystemServiceManager.startService(
        DisplayManagerService.class);

mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_WAIT_FOR_DEFAULT_DISPLAY);

mPackageManagerService = PackageManagerService.main(...);

PMS 读取 resources、features 和 display metrics 前，默认 display 必须可用。PHASE_WAIT_FOR_DEFAULT_DISPLAY 是显式屏障，不是普通日志标签；该 phase 中任一服务回调失败，PMS 不应继续启动。

5. UsageStats注入

mSystemServiceManager.startService(
        UsageStatsService.class);
mActivityManagerService.setUsageStatsManager(
        LocalServices.getService(
                UsageStatsManagerInternal.class));

UsageStatsService 在 onStart() 发布本地接口，SystemServer 随后查询并注入 AMS。这条边要求发布和读取在同一线程顺序完成；Binder 名称是否存在与该本地接口无关。

6. WMS与Display

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java

mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_WAIT_FOR_SENSOR_SERVICE);

WindowManagerService wm = WindowManagerService.main(
        context, inputManager, !mFirstBoot,
        new PhoneWindowManager(),
        mActivityManagerService.mActivityTaskManager);
ServiceManager.addService(Context.WINDOW_SERVICE, wm, ...);

mActivityManagerService.setWindowManager(wm);
wm.onInitReady();

inputManager.setWindowManagerCallbacks(
        wm.getInputManagerCallback());
inputManager.start();
mDisplayManagerService.windowManagerAndInputReady();

该闭环包含五个动作：等待 SensorService、创建并发布 WMS、WMS 回填 AMS、InputManager 取得 WMS callback 并启动、DisplayManager 等待两者 ready。任何一步提前都会造成 callback 为空、display policy 未完成或输入事件无消费者。

7. 第三方应用门槛

mActivityManagerService.systemReady(() -> {
    mSystemServiceManager.startBootPhase(
            t, SystemService.PHASE_ACTIVITY_MANAGER_READY);

    mPackageManagerService.waitForAppDataPrepared();

    if (webviewPrep != null) {
        ConcurrentUtils.waitForFutureNoInterrupt(
                webviewPrep, WEBVIEW_PREPARATION);
    }

    mSystemServiceManager.startBootPhase(
            t,
            SystemService.PHASE_THIRD_PARTY_APPS_CAN_START);
});

AMS ready 后仍不能立即启动第三方应用。PMS app data 和 WebView preparation 必须完成，600 phase 才开放第三方代码。这样避免应用在数据目录、WebView RELRO 或服务权限状态未就绪时发起 Binder 调用。

8. 依赖类型

依赖类型	例子	生效方式
实例注入	Installer → AMS/PMS	Java 字段直接保存
LocalServices	UsageStats → AMS	同进程类型查询
Binder 名称	WMS、TelephonyRegistry	ServiceManager 名称表
BootPhase	Display、Sensor、AMS ready	所有 SystemService 回调
Future	WebView、secondary preload	等待异步任务完成
ready callback	WMS/Input/Display	显式方法回填与联结

识别依赖类型后，排查入口才准确：LocalServices 问题查同进程 map，Binder 问题查 servicemanager，Future 问题查线程池任务，BootPhase 问题查 phase callback。

9. 反向排查

• PMS 启动卡住：向前检查 Installer、DomainVerification、默认 Display phase；
• AMS 缺 UsageStats：检查 UsageStats onStart() 是否发布 LocalServices，以及注入是否发生；
• WMS 已注册但输入无效：检查 WMS callback、InputManager.start 和 Display ready join；
• 第三方应用迟迟不启动：检查 AMS systemReady、PMS app data 和 WebView Future；
• 服务名称可查但功能未 ready：检查 onBootPhase/systemReady/onInitReady，不能只看 addService。

# 跨服务实例注入和 ready 回调。
rg -n "setInstaller|setUsageStatsManager|setWindowManager|setWindowManagerCallbacks|windowManagerAndInputReady|waitForAppDataPrepared" \
  frameworks/base/services/java/com/android/server/SystemServer.java

# 粗粒度服务组与 BootPhase 屏障。
rg -n "startBootstrapServices|startCoreServices|startOtherServices|startApexServices|PHASE_WAIT_FOR_DEFAULT_DISPLAY|PHASE_WAIT_FOR_SENSOR_SERVICE|PHASE_THIRD_PARTY_APPS_CAN_START" \
  frameworks/base/services/java/com/android/server/SystemServer.java

下一篇将选择 AMS/WMS/PMS 的实际初始化时序，深入构造、发布和 systemReady 消费；不会重复本文的跨服务依赖分类。