Core服务

startCoreServices() 位于 Bootstrap 之后、Other 之前。它启动的是“不再纠缠于最早期引导、但必须在大量其他服务之前可用”的核心能力：系统配置、电池、UsageStats、WebView、设备状态、Binder/Looper 统计、回滚、tombstone、bugreport、GPU 和远程证明。判断顺序的关键不是服务名，而是下一位消费者：AMS 何时需要 UsageStatsManagerInternal，WebView feature 何时决定是否实例化，调试构建何时增加 CPU monitor。

1. 组入口与顺序

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

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

    t.traceBegin("StartSystemConfigService");
    mSystemServiceManager.startService(
            SystemConfigService.class);
    t.traceEnd();

    t.traceBegin("StartBatteryService");
    mSystemServiceManager.startService(
            BatteryService.class);
    t.traceEnd();

    // 其余服务按同一模式继续，最后关闭 startCoreServices trace。
    ...
    t.traceEnd();
}

每个服务都有独立 trace 标签，失败可以定位到具体阶段。SystemServiceManager.startService() 负责实例化并执行 onStart()；Core 方法本身不捕获单项异常，因此异常会回到 SystemServer.run() 的 StartServices catch，阻止 Other/Apex 继续。

2. 配置与电池

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

SystemConfigService 把系统配置作为 Binder/SystemService 能力提供给后续消费者；BatteryService 的源码注释明确要求 LightsService 已在 Bootstrap 启动，因此 Core 可以直接创建它。Battery 的 onStart() 会注册 health callback、发布 battery/batteryproperties Binder 服务并发布 BatteryManagerInternal LocalServices；跨进程查询和进程内调用分别走两张表。

3. UsageStats注入

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

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

UsageStatsService 的 onStart() 同时发布 UsageStatsManagerInternal、AppStandbyInternal 和 Binder services；SystemServer 随后立即从 LocalServices 取回内部接口并注入 AMS。这个显式回填点证明顺序是消费者驱动的：若先调用 getService()，AMS 得到 null；若只发布 Binder 而不注入 LocalServices，AMS 的进程内路径仍未建立。

4. WebView条件路径

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

if (mPackageManager.hasSystemFeature(
        PackageManager.FEATURE_WEBVIEW)) {
    t.traceBegin("StartWebViewUpdateService");
    mWebViewUpdateService =
            mSystemServiceManager.startService(
                    WebViewUpdateService.class);
    t.traceEnd();
}

WebViewUpdateService 只在设备声明 FEATURE_WEBVIEW 时启动。它的 onStart() 注册 package/user 广播接收器，调用 prepareWebViewInSystemServer() 时由其他启动阶段消费；没有 WebView feature 的设备不会创建该 Binder 服务。条件路径的失败判读必须先确认 feature，而不是把缺少 webviewupdate 名称当成 Core 启动异常。

5. 状态与统计

mSystemServiceManager.startService(
        CachedDeviceStateService.class);
mSystemServiceManager.startService(
        BinderCallsStatsService.LifeCycle.class);
mSystemServiceManager.startService(
        LooperStatsService.Lifecycle.class);

CachedDeviceStateService 为系统服务提供统一设备状态缓存；BinderCallsStatsService 统计 Binder 调用 CPU 时间，LooperStatsService 统计 Handler 消息处理耗时。两者是诊断/性能消费者，不是事务路径本身；Core 启动成功只表示统计服务已注册，不能推断已有完整历史数据。

6. 回滚与诊断

mSystemServiceManager.startService(
        RollbackManagerService.class);
mSystemServiceManager.startService(
        NativeTombstoneManagerService.class);
mSystemServiceManager.startService(
        BugreportManagerService.class);

RollbackManagerService 管理 APK 回滚状态；NativeTombstoneManagerService 跟踪 native 崩溃 tombstone；BugreportManagerService 为 bugreport 请求提供系统服务入口。它们在 Core 中建立，但真正的文件扫描、回滚执行和 bugreport 收集由各自服务线程/调用方完成，不应把 startService() 返回当成任务已完成。

7. GPU与构建条件

mSystemServiceManager.startService(GpuService.class);
mSystemServiceManager.startService(
        RemoteProvisioningService.class);

if (Build.IS_DEBUGGABLE || Build.IS_ENG) {
    mSystemServiceManager.startService(
            CpuMonitorService.class);
}

GpuService 和 RemoteProvisioningService 在所有构建中启动；CpuMonitorService 仅 debug/eng 构建启用，源码注释说明待 JobScheduler 使用后再扩展到所有构建。构建类型条件是稳定边界：user build 没有 CpuMonitor 并非启动失败，而是预期策略。

8. Core交接

startCoreServices() 返回后，SystemServer 才进入 startOtherServices()。此时 SystemConfig、Battery、UsageStats、可选 WebView、统计服务和 GPU 等基础能力已具备，但不意味着所有服务可查：Other 仍会发布 telecom、account、content、network、window、input 等大量服务，并可能等待 Core 提供的 Binder/LocalServices。

9. 失败定位与导航

• SystemConfig/Battery：查对应 onStart()、health/Lights 依赖和 Binder/LocalServices 发布；
• UsageStats：查 UsageStatsManagerInternal 是否在 AMS 注入前可见；
• WebView：先确认 FEATURE_WEBVIEW，再查 package receiver 和准备时机；
• 统计服务：区分服务已启动但尚无历史样本与启动失败；
• Rollback/Tombstone/Bugreport：定位各自异步任务和文件 owner；
• CpuMonitor：确认构建类型，不要把 user build 缺少该服务当成错误。

# 输入 Core 组入口，输出服务顺序、feature gate 和构建条件。
rg -n "startCoreServices|StartSystemConfigService|StartBatteryService|StartUsageService|FEATURE_WEBVIEW|StartCachedDeviceStateService|StartBinderCallsStatsService|StartLooperStatsService|StartRollbackManagerService|StartNativeTombstoneManagerService|StartBugreportManagerService|GpuService|RemoteProvisioningService|CpuMonitorService" \
  frameworks/base/services/java/com/android/server/SystemServer.java

# 输入 UsageStats/Battery/WebView 实现，输出 onStart 发布物和消费者接口。
rg -n "void onStart|publishBinderService|publishLocalService|UsageStatsManagerInternal|BatteryManagerInternal|FEATURE_WEBVIEW" \
  frameworks/base/services/usage/java/com/android/server/usage/UsageStatsService.java \
  frameworks/base/services/core/java/com/android/server/BatteryService.java \
  frameworks/base/services/core/java/com/android/server/webkit/WebViewUpdateService.java

下一篇将展开 startOtherServices() 的前半段和 secondary Zygote preload 任务；不会重复本文的 Core 服务顺序和 feature/build 条件。