崩溃恢复链

本文面向已经读过 SystemServer.run、ZygoteInit.main、SIGCHLD 进程死亡处理和首次启动与普通启动的读者。前文分别介绍了启动入口、进程创建和启动场景；本文只回答一个更窄的问题：system_server 已经运行后发生 Java 异常、Watchdog 超时或 native crash，哪个对象先观察到退出，谁决定杀掉谁，谁负责再次启动，以及反复失败时何时停止重启。

这里的“恢复”不是一个统一的 restart API。Java 未捕获异常负责留下 crash 日志并终止当前进程；Watchdog 负责在 system_server 卡住时收集线程现场并终止进程；native Zygote 负责收割 system_server 子进程并让自己退出；init 负责依据 service 状态重新拉起 Zygote。每一层都有自己的 owner、状态和生效时机。把它们混为“AMS 收到崩溃后重启 system_server”，会漏掉真正的父子进程关系和 crash-loop 保护。

1. 恢复边界

system_server 是由 primary Zygote fork 出来的子进程。它退出时，直接父进程不是 init，而是 Zygote；但是 Zygote 不能继续作为“正常父进程”运行，因为它的关键子进程已经消失。因此恢复链是：

图中的两个动作不要颠倒：system_server 退出只产生 SIGCHLD；是 Zygote 的 native handler 识别到保存的 system-server PID 后才主动杀掉 Zygote。init 看到的是 Zygote service 退出，而不是直接看到一次“重启 SystemServer”命令。

层	owner	观察对象	关键输出	是否负责再次启动
Java runtime	`RuntimeInit`	未捕获异常	crash log、`sys.system_server.crash_java`	否
system_server watchdog	`Watchdog`	Handler/monitor 是否完成	thread dump、DropBox、watchdog atom	否，终止自己
Zygote native	`SigChldHandler`	子进程 `waitpid()` 状态	`Process ... exited`、SIGKILL Zygote	否，触发父级退出
init service manager	`Service::Reap`	Zygote service 退出	`onrestart`、crash count、critical 处置	是

2. Java异常

Java 层的入口在 RuntimeInit.commonInit() 注册。这里的 pre-handler 只负责日志，default handler 才负责停止进程；它并不调用 init，也不直接创建新的 Zygote。

源码文件：frameworks/base/core/java/com/android/internal/os/RuntimeInit.java

3. Watchdog

Java 异常是“线程主动结束”，Watchdog 是“线程没有在期限内完成”。Watchdog 线程本身位于 system_server，但它不直接修复阻塞的服务；它在收集现场后决定是否杀死 system_server。

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

4. Zygote接管

SystemServer 的 Java 进程退出后，primary Zygote 通过 native SIGCHLD handler 收割子进程。这个 handler 必须使用 waitpid()，否则退出的 system_server 会变成 zombie，Zygote 也无法准确知道哪个 PID 已经结束。

源码文件：frameworks/base/core/jni/com_android_internal_os_Zygote.cpp

5. init重启

init 只认识 service。primary Zygote 的 rc 定义包含 onrestart 和 critical；它没有一条“SystemServer 崩溃后直接启动 SystemServer”的规则。因为 SystemServer 是 Zygote 的子进程，init 的重启对象是 zygote service。

源码文件：system/core/rootdir/init.zygote64.rc

6. 重启状态机

init 的 Service::Reap() 同时处理资源清理、失败回调、crash-loop 计数和状态转换。关键状态不是“进程死了”这一瞬间，而是 pid_ = 0、SVC_RESTARTING 和下一次 Start() 之间的顺序。

源码文件：system/core/init/service.cpp

7. CrashLoop保护

critical 的含义是“连续失败达到阈值后升级处置”，不是“每次失败都触发 bootloader”。在 Android 17 的 init 实现中，关键 service 在 boot 未完成前或时间窗口内反复非正常退出，超过 4 次才进入 fatal 分支；并且 24 小时内已经执行过一次 fatal reboot 时会节流。

源码文件：system/core/init/service.cpp

相关函数：Service::Reap 的 crash-loop 分支

cpp

// 本文注：只有 critical 或 updatable service 的非正常退出进入计数。
if (((flags_ & SVC_CRITICAL) || is_process_updatable)
        && !(flags_ & SVC_RESTART)
        && !was_last_exit_ok_) {
    bool boot_completed =
            GetBoolProperty("sys.boot_completed", false);
    if (now < time_crashed_ + fatal_crash_window_
            || !boot_completed) {
        if (++crash_count_ > 4) {
            if (flags_ & SVC_CRITICAL) {
                if (!GetBoolProperty(
                        "init.svc_debug.no_fatal."
                                + name_, false)) {
                    uint64_t epoch_time =
                            std::chrono::duration_cast<
                                    std::chrono::seconds>(
                                    std::chrono::system_clock::now()
                                            .time_since_epoch())
                                    .count();
                    if (epoch_time
                            - GetIntProperty(
                                    "persist.init.svc.last_fatal_reboot_epoch",
                                    0)
                            > 24 * 60 * 60) {
                        SetProperty(
                                "persist.init.svc.last_fatal_reboot_epoch",
                                std::to_string(epoch_time));
                        SetFatalRebootTarget(
                                fatal_reboot_target_);
                        LOG(FATAL)
                                << "critical process '"
                                << name_
                                << "' exited 4 times";
                    }
                }
            } else {
                // updatable service 通知 update_verifier/apexd，而非立即 fatal reboot。
                SetProperty(
                        "sys.init.updatable_crashing_process_name",
                        name_);
                SetProperty(
                        "sys.init.updatable_crashing", "1");
            }
        }
    } else {
        time_crashed_ = now;
        crash_count_ = 1;
    }
}

这里的计数 owner 是 init 内存中的 Service 对象，time_crashed_ 和 crash_count_ 随 init 生命周期存在；persist.init.svc.last_fatal_reboot_epoch 只用于跨重启节流。init.svc_debug.no_fatal_<service> 可关闭 fatal 处置，开发和测试环境因此可能看到 crash loop 继续重启而不进入 bootloader。上面的 updatable 分支也说明 APEX 可更新 service 的失败后果和 critical 不同。

8. 诊断输出

一次完整诊断要把“根因现场”和“恢复动作”分开采集。Java crash、Watchdog 和 native crash 的输出位置不同，不能只看 logcat | grep FATAL。

8.1 Java与Watchdog

RuntimeInit.LoggingHandler 写入 crash log，并在 system UID 的 system_server 路径递增 sys.system_server.crash_java；Watchdog 另写 WATCHDOG EventLog、SYSTEM_SERVER_WATCHDOG_OCCURRED atom，并把线程 dump 放入 DropBox。

bash

# 输入：当前设备的 system_server 属性。输出：Java crash 累计值与本次 runtime restart 次数。
adb shell getprop sys.system_server.crash_java
adb shell getprop sys.system_server.start_count

# 输入：system_server dump 服务。输出：本次进程的 Runtime restart、start count 和时钟。
adb shell dumpsys system_server_dumper --name SystemServer

# 输入：system 与 main buffer。输出：Java fatal、Watchdog kill 和 Zygote 收割日志。
adb logcat -b system -b main -v threadtime -d \
  | rg 'FATAL EXCEPTION IN SYSTEM PROCESS|WATCHDOG KILLING SYSTEM PROCESS|Exit zygote because system server|Process [0-9]+ exited'

# 输入：DropBox 服务。输出：watchdog、system_server crash 现场条目。
adb shell dumpsys dropbox --print system_server_native_crash
adb shell dumpsys dropbox --print watchdog

这些命令的输入分别是 system properties、SystemServerDumper Binder service、log buffers 和 DropBoxManager；输出只能证明对应记录是否存在，不能单独证明 init 已经完成重启。要确认恢复动作，还需要读取 init service 状态和后续 SYSTEM_SERVER_START。

8.2 Native与init

native crash 的 tombstone 由 debuggerd 生成，BootReceiver 在启动后的后台线程把包含 >>> system_server <<< 的 tombstone 额外复制为 system_server_native_crash。init 的服务状态则通过 init.svc.zygote 和 crash-loop 属性观察。

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

相关函数：BootReceiver.addFileWithFootersToDropBox

java

String fileContents = FileUtils.readTextFile(
        file, maxSize, TAG_TRUNCATED);
String text = headers + fileContents + footers;

// 本文注：只有 tombstone 且内容标记为 system_server 才使用专用 tag。
if (tag.equals(TAG_TOMBSTONE)
        && fileContents.contains(">>> system_server <<<")) {
    addTextToDropBox(db,
            "system_server_native_crash",
            text, filename, maxSize);
}
if (tag.equals(TAG_TOMBSTONE)) {
    FrameworkStatsLog.write(
            FrameworkStatsLog.TOMB_STONE_OCCURRED);
}
addTextToDropBox(db, tag, text, filename, maxSize);

BootReceiver 是诊断输出的后处理者，不是 native crash 的终止者。它只是根据 tombstone 文本内容增加一个精确 tag；如果 DropBox tag 未启用、文件时间戳已记录或文件不存在，该副作用可以缺失，但不影响 debuggerd 和 init 的进程处理。

bash

# 输入：init property service。输出：zygote 当前状态及 crash-loop 节流时间。
adb shell getprop init.svc.zygote
adb shell getprop persist.init.svc.last_fatal_reboot_epoch

# 输入：kernel/debuggerd tombstone 目录。输出：最近 system_server native 崩溃的线程和 signal。
adb shell ls -lt /data/tombstones | head
adb shell grep -R -n '>>> system_server <<<' /data/tombstones

# 输入：启动时间线。输出：旧 zygote 退出、重启和新 system_server start 的相邻事件。
adb logcat -b all -v threadtime -d \
  | rg 'system_server.*terminated|Exit zygote|init.*zygote|SYSTEM_SERVER_START|BOOT_PROGRESS_SYSTEM_RUN'

如果 sys.system_server.crash_java 增长但没有 tombstone，优先检查 Java 异常路径；如果有 tombstone 但没有 FATAL EXCEPTION IN SYSTEM PROCESS，说明根因可能在 native；如果 Zygote 日志出现退出但 init.svc.zygote 长时间不是 running，应转向 init rc、SELinux 或 executable 启动失败，而不是继续分析 AMS。

9. 调用时序

下图把三个进程边界放在一条时间轴上。消息 SIGCHLD 是内核到 Zygote 的信号，onrestart 是 init 内部 Action，不是 Binder 调用。

system_server 的 Java 报告动作和 Zygote 的退出动作之间没有同步等待关系：Java handler 只等待 handleApplicationCrash() 的 Binder 调用返回或失败，然后立即终止；Zygote 收到的只是最终进程状态。init 的 Start() 发生在之后的主循环时间点，因此“crash 日志出现”和“新 SystemServer 已经开始”不是同一个时间戳。

10. 失败矩阵

现象	第一观察者	关键状态	可能的下一步
Java `FATAL EXCEPTION IN SYSTEM PROCESS`	`RuntimeInit.LoggingHandler`	`sys.system_server.crash_java` 增加	查原始 Java stack，再看 Zygote 是否退出
`WATCHDOG KILLING SYSTEM PROCESS`	`Watchdog`	checker `OVERDUE`、`allowRestart`	查 blocked checker、thread dump、debugger/controller 条件
tombstone 含 `>>> system_server <<<`	debuggerd/BootReceiver	signal、native backtrace、DropBox tag	查 native 库和对应 service 调用
Zygote 日志 `Exit zygote because system server...`	Zygote `SigChldHandler`	`pid == gSystemServerPid`	查 init zygote restart 与 onrestart
zygote 反复 `restarting`	init `Service::Reap`	`crash_count_`、`time_crashed_`	检查 `critical`、fatal 节流和启动失败
新 SystemServer 启动但计数持续增加	`SystemServer` 构造函数	`mStartCount > 1`	区分 runtime restart 与物理 reboot，回到启动场景判定

有两个常见误判。第一，sys.boot_completed=1 只说明某次启动曾到达 boot complete，不能替代 Zygote 的 gSystemServerPid 或 init 的 crash count。第二，sys.system_server.start_count 只统计当前 property 生命周期内的 SystemServer 实例，不告诉你根因是 Java、Watchdog 还是 native。

11. 源码验证

源码测试不能完整模拟真实 init、内核信号和 debuggerd，但可以验证状态转移中的局部契约。阅读时应把“测试断言覆盖的范围”和“必须依赖设备现场的部分”分开。

源码文件：frameworks/base/services/tests/servicestests/src/com/android/server/WatchdogTest.java

相关测试：WatchdogTest.blockedThread

java

@Test
public void blockedThread() {
    // 输入：10ms 的 checker 超时，但被检查的 Handler 不回调。
    mChecker.scheduleCheckLocked(TIMEOUT_MS);
    assertEquals(Watchdog.WAITING,
            mChecker.getCompletionStateLocked());

    mClock.advanceBy(6);
    // 断言：预警时间到达，只能收集信息，不应立即 kill。
    assertEquals(Watchdog.WAITED_UNTIL_PRE_WATCHDOG,
            mChecker.getCompletionStateLocked());

    mClock.advanceBy(6);
    // 断言：完整 timeout 后才进入 OVERDUE。
    assertEquals(Watchdog.OVERDUE,
            mChecker.getCompletionStateLocked());
}

这个用例用 TestClock 分两次推进时间：第一次到达 pre-watchdog 状态，第二次才到达 OVERDUE。它证明了时间状态机和本文所说的“先收集、后终止”；不证明真实设备上的线程 dump 内容或 kill 后的 init 重启。

ART Service 的测试则验证 staged artifact 失败和延迟提交，说明恢复链中“新进程已启动”不等于“所有启动期资源都已完成消费”。

源码文件：art/libartservice/service/javatests/com/android/server/art/ArtManagerLocalTest.java

相关测试：testCommitPreRebootStagedFiles、testCommitPreRebootStagedFilesObsolete

java

when(mArtd.checkPreRebootStagedFilesStatus())
        .thenReturn(TestingUtils.createPreRebootStagedFilesStatus(
                true /* isCommittable */, 200 /* createdAtMillis */));

mArtManagerLocal.onBoot(
        ReasonMapping.REASON_BOOT_AFTER_OTA,
        null /* progressCallbackExecutor */,
        null /* progressCallback */);

InOrder inOrder = inOrder(mArtd);
inOrder.verify(mArtd).deletePreRebootStagedMetadata();
// 本文注：开机阶段先提交 primary；BOOT_COMPLETED 后才提交 secondary。
verify(mArtd, times(1))
        .commitPreRebootStagedFiles(any(), any());

simulateBroadcast(Intent.ACTION_BOOT_COMPLETED);
verify(mArtd, times(2))
        .commitPreRebootStagedFiles(any(), any());

isCommittable=true 的输入覆盖成功提交和生命周期延迟；对应的 testCommitPreRebootStagedFilesObsolete() 将输入改为 false，断言 cleanUpPreRebootStagedFiles() 被调用且从未 commit。它们不能证明 Zygote 或 init 的重启，但能防止把“启动恢复”叙述成一次无条件的全量资源恢复。

12. 阅读收束

可以用下面的顺序复述一次真正的 SystemServer crash：先指出根因属于 Java、Watchdog 还是 native；再说明当前进程怎样退出；然后指出 primary Zygote 如何通过 gSystemServerPid 判断必须自杀；最后追踪 init 的 Service::Reap、SVC_RESTARTING 和 HandleProcessActions() 如何重新拉起 Zygote。若失败连续发生，还要补上 critical 的 4 次阈值、boot-completed 条件和 24 小时 fatal reboot 节流。

做到这一步，就不会把三种不同的“计数”混在一起：sys.system_server.crash_java 是 Java 日志路径的计数，mStartCount 是当前 property 生命周期内的 SystemServer 实例数，init 的 crash_count_ 是某个 service 的非正常退出窗口。它们的 owner、持久性和消费者都不同，诊断结论也必须分别建立。

崩溃恢复链 ​

1. 恢复边界 ​

2. Java异常 ​

3. Watchdog ​

4. Zygote接管 ​

5. init重启 ​

6. 重启状态机 ​

7. CrashLoop保护 ​

8. 诊断输出 ​

8.1 Java与Watchdog ​

8.2 Native与init ​

9. 调用时序 ​

10. 失败矩阵 ​

11. 源码验证 ​

12. 阅读收束 ​

崩溃恢复链

1. 恢复边界

2. Java异常

3. Watchdog

4. Zygote接管

5. init重启

6. 重启状态机

7. CrashLoop保护

8. 诊断输出

8.1 Java与Watchdog

8.2 Native与init

9. 调用时序

10. 失败矩阵

11. 源码验证

12. 阅读收束