SystemServer.run

SystemServer.run() 是服务编排器，不是服务实现的集合。它先完成进程级准备，再把服务按 bootstrap、core、other、Apex 四组顺序启动；Apex 组结束后调用 sealStartedServices() 禁止继续加入服务；最后设置 Binder transaction callback 和主 Looper。本文解释为什么这些阶段不能互换、异常怎样传播，以及每组文章应继续读到哪里。

1. 两个trace范围

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

TimingsTraceAndSlog t = new TimingsTraceAndSlog();
try {
    t.traceBegin("InitBeforeStartServices");
    // 属性、Binder、Looper、context、manager 等进程级准备。
    ...
} finally {
    t.traceEnd(); // InitBeforeStartServices
}

try {
    t.traceBegin("StartServices");
    startBootstrapServices(t);
    startCoreServices(t);
    startOtherServices(t);
    startApexServices(t);
    updateWatchdogTimeout(t);
    CriticalEventLog.getInstance().logSystemServerStarted();
} catch (Throwable ex) {
    Slog.e("System", "Failure starting system services", ex);
    throw ex;
} finally {
    t.traceEnd(); // StartServices
}

InitBeforeStartServices 覆盖进程级准备，StartServices 覆盖四组服务和 watchdog 收束。服务启动异常被 catch 记录后重新抛出，不会继续进入 Looper.loop()。两个 finally 都关闭 trace section，保证失败启动在 Perfetto/trace 中仍有完整范围。

2. Bootstrap的角色

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

private void startBootstrapServices(
        @NonNull TimingsTraceAndSlog t) {
    t.traceBegin("startBootstrapServices");

    ArtModuleServiceInitializer.setArtModuleServiceManager(
            new ArtModuleServiceManager());

    final Watchdog watchdog = Watchdog.getInstance();
    watchdog.start();
    mDumper.addDumpable(watchdog);

    ServiceManager.addService(
            Context.PROTOLOG_CONFIGURATION_SERVICE,
            new ProtoLogConfigurationServiceImpl());

    PlatformCompat platformCompat =
            new PlatformCompat(mSystemContext);
    ServiceManager.addService(
            Context.PLATFORM_COMPAT_SERVICE, platformCompat);
    ServiceManager.addService(
            Context.PLATFORM_COMPAT_NATIVE_SERVICE,
            new PlatformCompatNative(platformCompat));

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

bootstrap 放的是互相依赖、必须尽早可用的服务和基础设施：ART module manager 避免后续 class linker 与 GC 冲突；Watchdog 尽早启动以覆盖早期死锁；platform compat 会被 AMS/PMS 等后续服务消费；Installer 必须先完成关键目录准备。该分组的 owner 是 SystemServiceManager 或 ServiceManager，具体注册方式取决于服务是否需要跨进程 Binder 名称。

3. Core的角色

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

private void startCoreServices(
        @NonNull TimingsTraceAndSlog t) {
    t.traceBegin("startCoreServices");

    mSystemServiceManager.startService(SystemConfigService.class);
    mSystemServiceManager.startService(BatteryService.class);

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

    if (mPackageManager.hasSystemFeature(
            PackageManager.FEATURE_WEBVIEW)) {
        mWebViewUpdateService =
                mSystemServiceManager.startService(
                        WebViewUpdateService.class);
    }
    ...
}

core 服务不一定都直接 addService。SystemServiceManager.startService() 负责实例化和生命周期回调；UsageStatsManagerInternal 通过 LocalServices 供 AMS 进程内读取，体现了进程内依赖而非 Binder 查询。WebView 服务受 feature gate 控制，设备不具备 WebView 时不应把缺少该服务当作启动失败。

4. Other的角色

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

private void startOtherServices(
        @NonNull TimingsTraceAndSlog t) {
    t.traceBegin("startOtherServices");
    mSystemServiceManager.updateOtherServicesStartIndex();

    final Context context = mSystemContext;
    boolean disableNetworkTime = SystemProperties.getBoolean(
            "config.disable_networktime", false);
    boolean disableCameraService = SystemProperties.getBoolean(
            "config.disable_cameraservice", false);
    boolean isWatch = RoSystemFeatures.hasFeatureWatch(context);
    boolean isAutomotive = RoSystemFeatures.hasFeatureAutomotive(context);

    mZygotePreload = SystemServerInitThreadPool.submit(() -> {
        String[] abis32 = Build.SUPPORTED_32_BIT_ABIS;
        if (abis32.length > 0
                && !Process.ZYGOTE_PROCESS.preloadDefault(abis32[0])) {
            Slog.e(TAG,
                    "Unable to preload default resources for secondary");
        }
    }, "SecondaryZygotePreload");
    ...
}

other 是数量最多、设备变体最多的组。先记录 other 服务起始索引，供 SystemServiceManager 区分启动阶段；再读取 property 和 feature，决定网络时间、相机、Watch、Automotive 等条件路径。secondary Zygote preload 被投递到 init 线程池，失败记录日志但不等于所有 other 服务失败。这里不能把源码中出现的局部变量表当作“本设备必然启动的服务清单”。

5. Apex服务组

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

private void startApexServices(
        @NonNull TimingsTraceAndSlog t) {
    t.traceBegin("startApexServices");
    List<ApexSystemServiceInfo> services =
            ApexManager.getInstance().getApexSystemServices();
    for (ApexSystemServiceInfo info : services) {
        String name = info.getName();
        String jarPath = info.getJarPath();
        t.traceBegin("starting " + name);
        if (TextUtils.isEmpty(jarPath)) {
            mSystemServiceManager.startService(name);
        } else {
            mSystemServiceManager.startServiceFromJar(name, jarPath);
        }
        t.traceEnd();
    }
    mSystemServiceManager.sealStartedServices();
    t.traceEnd();
}

Apex 服务必须最后启动，源码注释的理由是 APEX 可以在 OTA 之外更新：若平台服务在 Apex 后继续新增依赖，模块更新可能破坏稳定性。每个 info 可能只给类名，也可能提供 jar path；后者用 startServiceFromJar。sealStartedServices() 是编排不变量，之后任何新服务注册应被视为启动流程设计错误。

6. 服务组后的收束

Binder.setTransactionCallback(new IBinderCallback() {
    @Override
    public void onTransactionError(
            int pid, int code, int flags, int err) {
        mActivityManagerService
                .frozenBinderTransactionDetected(
                        pid, code, flags, err);
    }
});

Looper.loop();
throw new RuntimeException(
        "Main thread loop unexpectedly exited");

transaction callback 在所有服务启动后才安装，因为它需要已初始化的 AMS 处理 frozen Binder transaction。主 Looper 是 run 的正常终点，不会返回；若 Looper.loop() 返回，源码立即抛异常，防止 SystemServer 带着停止消费消息队列的主线程继续存活。

7. 失败定位

• 启动服务组前失败：回到 SS016 的属性、Binder、Looper、SystemContext 初始化；
• bootstrap 失败：优先读 Watchdog、Installer、PlatformCompat 与相关 startService 调用；
• core 失败：检查 feature gate 和 LocalServices 的进程内依赖；
• other 失败：先确认设备 feature/property 分支，再定位具体服务 trace；
• Apex 失败：检查 ApexManager 返回项、jar path、classloader 和 sealStartedServices 前后顺序；
• Looper 退出：属于 SystemServer 主线程致命状态。

# 服务组调用、trace 和异常传播。
rg -n "StartServices|startBootstrapServices|startCoreServices|startOtherServices|startApexServices|sealStartedServices|Looper\.loop" \
  frameworks/base/services/java/com/android/server/SystemServer.java

# Bootstrap 与 Core 的实际消费者。
rg -n "Watchdog|PlatformCompat|Installer|SystemConfigService|BatteryService|UsageStatsService|WebViewUpdateService" \
  frameworks/base/services/java/com/android/server/SystemServer.java

# APEX 项目和线程池中的 secondary Zygote preload。
rg -n "ApexManager|getApexSystemServices|startServiceFromJar|SecondaryZygotePreload|preloadDefault" \
  frameworks/base/services/java/com/android/server/SystemServer.java

下一篇将只展开 createSystemContext()：ActivityThread.systemMain() 如何生成 SystemContext/SystemUiContext，以及为什么这必须先于 SystemServiceManager。服务组编排已经在本文收束。