## AOSP 问题定位先看现象

如果上一轮已经写过常规背景，这一版就直接从 先写最小补丁验证假设、行为、日志、测试三类证据一起收口 和现场证据切进去，让 AOSP 问题定位 的正文骨架明显换轨。AOSP 问题定位 一旦出问题，现场通常不会只报一个错，而是先从 还有一种低效排障方式，是很快找到了怀疑点，却因为验证动作过大，把本来简单的问题重新弄复杂。 这种工程背景里放大成连锁反应。这类故障最烦的地方在于它经常伪装成偶发成功，但真正的根因往往就藏在 怀疑点一多就同时改多个模块、增量编译范围没有收住 这一类边界条件里。

## AOSP 问题定位先这样修

只要状态生产者、状态消费者、兜底重试这三层没有明确 owner，AOSP 问题定位 后面一定还会反复炸，所以这里先把责任边界钉住。先用日志 tag 和调用栈缩模块，再确认分支和 build 对齐，最后才做全局搜索和补丁验证。这篇方案刻意改成另一种收口顺序：先补观测和责任边界，再落修复动作，最后补回归口，不再沿用上一轮的铺垫节奏。

## AOSP 问题定位示例代码

这一版示例故意换成另一套骨架：围绕 日志缩目录、分支对齐和最小补丁 先给结构或审计对象，再给命令或校验入口，最后再贴核心实现。如果一段代码不能直接进工程跑，一条命令不能直接拿去比对现场，那它对排障文章的价值就不够高。

1. 排查命令

mm services/core
atest FrameworksServicesTests

2. 核心实现

fun shouldPatch(path: String, stackTrace: String): Boolean {
    return stackTrace.contains(path.substringAfterLast('/'))
}

3. 修复辅助代码

data class YuandaimaMinimalPatchVerificationCheckResult(
    val key: String,
    val ok: Boolean,
    val detail: String
)

## AOSP 问题定位常见坑

mm、atest、repo diff 这类现成观测手段不要浪费，很多问题不是没有证据，而是证据没有被串成同一条时间线。真正要避开的不是标题撞车，而是 AOSP 问题定位 还沿用同一套观察路径和收尾话术，所以这一版专门把坑位改写到 日志缩目录、分支对齐和最小补丁 相关的边界。如果同分类最近文章已经覆盖过常规背景，这次就直接补旧稿没展开的失败信号、止血顺序和验收证据。

## 报错怎么处理

1. 任务重复执行

如果修复后还是偶发重入，说明幂等、入口锁或回退动作还没真正闭环，继续补最短验证路径。

fun shouldPatch(path: String, stackTrace: String): Boolean {
    return stackTrace.contains(path.substringAfterLast('/'))
}

2. 状态不一致

如果现场出现状态和预期不一致，先用 mm 拉证据，再按 先写最小补丁验证假设、把增量编译范围压到单模块 的顺序收口。

mm services/core
atest FrameworksServicesTests

## 命令和代码直接跑

这个最小样例的职责不是重复上轮步骤，而是把 日志缩目录、分支对齐和最小补丁 对应的新验证路径单独跑通，确保第二轮文章和上一轮不是同构改写。真正有价值的最小样例，必须保留最短入口、最少依赖和明确输出，这样复现、修复、回归三步才能连起来。只要先稳定复现一次，再把修复版稳定跑通一次，文章就不是经验笔记，而是可执行模板。

1. 最小数据结构

data class YuandaimaMinimalPatchVerificationState(
    val id: String,
    val status: String
)

2. 最小执行入口

fun main() {
    println(YuandaimaMinimalPatchVerificationState("1", "ok"))
}

3. 本地验证命令

mm services/core
atest FrameworksServicesTests