AMS/WMS/PMS时序

AMS、WMS、PMS 经常被概括成“SystemServer 启动三个核心服务”，但源码中的可用状态至少有四层：对象已构造、Binder/LocalServices 已发布、依赖已注入、systemReady()/BootPhase 已完成。Android 17 先创建 ATM 再创建 AMS，先准备 DisplayManager 和默认 display，再初始化 PMS；WMS 又要等 SensorService，创建后回填 AMS，InputManager 接收 WMS callback，最后 DisplayManager 才能确认 Window/Input ready。

1. ATM与AMS构造

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java、frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

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

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

ATM 的 Lifecycle 先构造并保存 ActivityTaskManagerService，AMS 的静态 Lifecycle.startService() 再把 ATM 放入构造上下文。AMS 创建后，SystemServer 显式注入 SystemServiceManager 和 Installer，并从 ATM 取出 global lock。此时只是进程内对象关系建立，AMS 尚未通过 setSystemProcess() 发布完整 Binder 服务。

2. PMS前置条件

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

mDisplayManagerService = mSystemServiceManager.startService(
        DisplayManagerService.class);
mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_WAIT_FOR_DEFAULT_DISPLAY);

DomainVerificationService domainVerificationService =
        new DomainVerificationService(
                mSystemContext, SystemConfig.getInstance(),
                platformCompat);
mSystemServiceManager.startService(domainVerificationService);

DisplayManager 先启动，PHASE_WAIT_FOR_DEFAULT_DISPLAY 让已启动服务获得默认显示能力；DomainVerificationService 复用 SystemConfig 和 PlatformCompat。PMS 的初始化不是孤立构造，它依赖 Installer、默认 display、SystemConfig、PlatformCompat 和 DomainVerification。

3. PMS主初始化

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java、frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java

Watchdog.getInstance().pauseWatchingCurrentThread(
        "packagemanagermain");
try {
    mPackageManagerService = PackageManagerService.main(
            mSystemContext, installer,
            domainVerificationService,
            mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF);
} finally {
    Watchdog.getInstance().resumeWatchingCurrentThread(
            "packagemanagermain");
}

mFirstBoot = mPackageManagerService.isFirstBoot();
mPackageManager = mSystemContext.getPackageManager();

Watchdog 只暂停当前线程的 checker，因为 PMS 扫描和解析可能长时间运行；其他线程仍受监控。PackageManagerService.main() 返回后，SystemServer 才保存 mFirstBoot 并取得 PackageManager facade。PMS 对象存在不等于包数据、应用进程和 systemReady 已完成。

4. AMS发布系统进程

源码文件：frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

public void setSystemProcess() {
    ServiceManager.addService(
            Context.ACTIVITY_SERVICE, this,
            true, DUMP_FLAG_PRIORITY_CRITICAL
                    | DUMP_FLAG_PRIORITY_NORMAL
                    | DUMP_FLAG_PROTO);
    ServiceManager.addService(ProcessStats.SERVICE_NAME,
            mProcessStats);
    ServiceManager.addService("permission",
            new PermissionController(this));
    ServiceManager.addService("processinfo",
            new ProcessInfoService(this));

    ApplicationInfo info = mContext.getPackageManager()
            .getApplicationInfo("android",
                    STOCK_PM_FLAGS | MATCH_SYSTEM_ONLY);
    mSystemThread.installSystemApplicationInfo(
            info, getClass().getClassLoader());
    ...
}

setSystemProcess() 是 AMS 从“已构造对象”进入“系统 Binder 服务集合”的关键点：它发布 activity、process stats、permission、processinfo 等名称，并把 android ApplicationInfo 安装到 system ActivityThread。该步骤需要 PMS 已可查询系统包，因此位于 PMS 主初始化之后。

5. WMS创建与AMS回填

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java、frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java

mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_WAIT_FOR_SENSOR_SERVICE);

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

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

WMS 创建前先推进 SensorService phase；创建时接收 InputManager、PhoneWindowManager、ATM 等依赖。发布 Binder 后，SystemServer 还要调用 AMS 的 setWindowManager() 完成反向引用，再调用 wm.onInitReady()。因此“window 服务可查”和“AMS 已持有 WMS、WMS 已完成初始化”是不同状态。

6. 输入与显示

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

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

mDisplayManagerService.windowManagerAndInputReady();

InputManager 必须先取得 WMS callback 后启动，DisplayManager 又在 WindowManager 和 InputManager 都完成后调用 windowManagerAndInputReady()。这一步把三个服务的 ready 状态联结起来；任何一方只完成 onStart() 都不足以证明显示和输入链路可用。

7. systemReady阶段

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java、frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

lockSettings.systemReady();
mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_LOCK_SETTINGS_READY);
mSystemServiceManager.startBootPhase(
        t, SystemService.PHASE_SYSTEM_SERVICES_READY);

wm.systemReady();
mPackageManagerService.systemReady();
mDisplayManagerService.systemReady(safeMode);

systemReady 不是单个全局布尔值：LockSettings、SystemServiceManager phase、WMS、PMS、DisplayManager 各自有 ready 方法，且调用顺序由依赖决定。AMS 的 systemReady() 还会在内部完成 controllers、AppOps、ProcessList 等状态后执行回调，推动 PHASE_ACTIVITY_MANAGER_READY。

8. 四种状态判读

状态	代表代码	能说明什么
对象构造	new ActivityManagerService、PackageManagerService.main	Java/native 对象存在
Binder发布	ServiceManager.addService	其他进程可按名称查询（仍受权限影响）
依赖注入	setInstaller、setWindowManager、setUsageStatsManager	进程内引用已建立
ready完成	systemReady、onInitReady、BootPhase	对应依赖和阶段动作已执行

现场看到 Binder 名称存在时，仍需判断它属于哪一层：AMS 可能已发布但 PMS/system process 尚未完成，WMS 可能可查但 Input callback 尚未安装，PMS 可能已构造但 app data 尚未准备。

9. 反向排查与导航

• AMS 查询失败：查 setSystemProcess()、PMS 是否可查询 android 包；
• PMS 初始化卡住：查 Installer、默认 display phase、DomainVerification 和 Watchdog pause；
• WMS 可查但无输入：查 setWindowManagerCallbacks()、inputManager.start() 和 Display ready；
• 服务 ready 顺序错误：查 BootPhase 单调性和 systemReady/onInitReady 调用点；
• 依赖为空：区分 Binder 名称查询与 LocalServices/字段注入。

# 输入三大服务调用点，输出构造、发布、注入和 ready 顺序。
rg -n "ActivityTaskManagerService\.Lifecycle|ActivityManagerService\.Lifecycle|PackageManagerService\.main|WindowManagerService\.main|setSystemProcess|setWindowManager|systemReady|onInitReady" \
  frameworks/base/services/java/com/android/server/SystemServer.java \
  frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

# 输入 SystemServiceManager phase，输出 phase 屏障和生命周期分发。
rg -n "PHASE_WAIT_FOR_DEFAULT_DISPLAY|PHASE_WAIT_FOR_SENSOR_SERVICE|PHASE_LOCK_SETTINGS_READY|PHASE_SYSTEM_SERVICES_READY|PHASE_ACTIVITY_MANAGER_READY|startBootPhase" \
  frameworks/base/services/java/com/android/server/SystemServer.java \
  frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

下一篇将进入 SystemServiceManager 的依赖与生命周期编排实战，结合一个具体服务解释 onStart、onBootPhase 和 LocalServices 注入；不会重复 AMS/WMS/PMS 的初始化时序。