内容验证标准说明

技术结论必须能回到证据。源码机制优先用固定版本的代码验证，公开 API 与兼容要求优先用官方文档验证，运行时行为再用系统跟踪数据（trace）、日志、命令输出或可复现实验补充。单凭二手文章、搜索摘要或没有条件说明的性能数字，不能标为已验证。

这是全书统一采用的验证规则，不替代各技术章节自己的证据。它只定义“怎样标注、怎样降低置信度、怎样确认待核对项已经完成”，不对某个 Java 框架层（Framework）、Linux 内核（Kernel）或具体设备行为追加机制结论。

默认源码版本

平台机制和内核机制分别按以下固定版本核对：

• Android 平台：Android 17（API 37），AOSP 源码标签（tag）为 android-17.0.0_r1。该标签中的 manifest（项目清单）文件列出组成这一平台版本的各个源码项目。
• Android Common Kernel（ACK，Android 公共内核）：6.18，源码标签为 android17-6.18-2026-06_r6。

平台代码和内核代码不能混用版本名。android-17.0.0_r1 用于 frameworks/base、frameworks/native、system/core、ART、Bionic 等 AOSP 项目；android17-6.18-2026-06_r6 用于 Android Common Kernel。设备厂商可能在 ACK 之上叠加 SoC（片上系统）支持与产品补丁，因此 ACK 源码只能证明公共内核版本，不能替代具体设备的内核提交版本、配置与厂商实现。

如果一个章节没有单独声明更窄的版本范围，应按上述两个固定版本阅读。若章节需要引用更早版本、厂商分支、实验构建或主线开发分支，正文必须把它们从 Android 17 确定性结论中分离出来。

一条源码锚点应包含什么

源码锚点是一组能够让读者回到固定版本代码的定位信息。正文中的每个源码依据至少要能回答四个问题：

1. 版本：代码来自哪个固定源码标签。
2. 项目与路径：例如 frameworks/base/services/core/java/com/android/server/am/OomAdjuster.java。
3. 符号：对应哪个类、方法、结构体、枚举或配置项。
4. 结论边界：这段代码能证明什么，不能证明什么。

行号可以帮助定位，但不能单独充当锚点。文件变化会让行号漂移，源码标签、路径与符号组合更适合长期核对。正文引用代码节选时，还要说明省略范围，不能把伪代码写成 AOSP 原文。

一条合格的源码锚点可以写成“android-17.0.0_r1 / frameworks/base/.../OomAdjuster.java / OomAdjuster#updateOomAdjLocked，用于说明进程优先级分数（adj）的计算入口；不证明厂商修改过的 lmkd（低内存终止守护进程）参数”。这种写法比只写“见源码第 N 行”更适合长期维护。

版本演进怎样处理

讲版本迭代的章节可以引用 Android 17 以前的源码标签，目的是对比旧行为、定位引入版本或解释兼容分支。此类段落需要同时写明旧版本与 Android 17 的观察结果，不能让旧标签变成整章的默认依据。

Android 17 是本书确定性结论的最高版本。来自 main、master、Android 18 或后续版本的代码只能作为未来变化线索，不能反推 Android 17 已经具备相同行为。如果章节必须讨论尚未发布或更高版本，应明确隔离为“超出本书基线”，不写进 Android 17 的结论。

当未来线索与本书采用的 Android 17 固定版本冲突时，正文应优先保留 Android 17 结论，并把未来变化放入独立段落或脚注。只有按新的正式版本重新核对章节并同步更新元数据后，才能把新行为提升为正文默认结论。

证据等级

• high：关键判断由固定源码标签直接支持，并有官方文档、测试、trace 或另一条独立源码路径交叉验证。
• medium：关键判断由一条可靠的一手来源支持，但缺少运行时或跨模块交叉验证。
• low：只有旧版本、二手资料、厂商单机现象或尚未复现的推断。此类内容必须保留限制说明，不能写成通用机制。

置信度描述证据强度，不代表内容完成度。章节元数据中的编辑状态与正文的“已验证”“待核对”“版本边界”等技术结论互不替代。

如果一个章节混合了不同证据强度，整章 confidence 应由证据最弱的关键结论决定，并在正文中标出高风险段落。局部未完成项不能靠把整章设为 high 来掩盖；反过来，流水线的 needs-review 也不能自动否定已经由固定源码标签支持的技术段落。

待核对项怎样完成核验

正文中出现“待核对”“待复现”“需要实机确认”等标注时，应视为尚未解决的技术问题，不是编辑备注。要把这类标注改为已核对，至少需要补齐以下内容之一：

• 固定源码标签能够直接证明该机制，并且正文写清版本、路径、符号与边界。
• 官方文档或兼容性要求能够直接证明 API/行为约束，并且章节说明适用 API 级别。
• trace、日志、命令输出或实验记录能够证明运行时现象，并且记录设备、构建、采集工具和复现条件。

如果只能补到二手资料、搜索摘要或未注明条件的性能数字，应保留限制说明并降低相关结论的置信度，不应把标注删除后写成通用事实。

来源清单与章节标注

章节开头 YAML 元数据中的 sources 是来源入口清单，不等于正文全部证据。每个包含关键机制结论的章节，正文仍应在相关段落附近给出可定位的源码标签、路径、符号、文档页或实验记录。只在 YAML 中放一个仓库根路径，不能证明具体结论。

last_verified_against 应写明本次验证覆盖的固定版本，例如 AOSP android-17.0.0_r1 与 Android Common Kernel android17-6.18-2026-06_r6。如果章节只验证了其中一部分，不应把另一部分写成已覆盖。last_verified 记录最近一次证据核对日期，不应仅因文字润色自动更新。

实机与性能数据

源码只能说明实现和条件，不能自动证明设备上的耗时、功耗或收益。性能数字必须给出设备、构建类型、版本、负载、采样工具、样本量和对照基线，例如改动前的数据或未开启功能的对照组。厂商系统（ROM）、芯片驱动、硬件抽象层（HAL）、内核配置或温控策略会改变结果时，需要说明这些数据只适用于哪些设备和配置。

系统跟踪数据和日志同样要记录采集条件。看到一个时间片事件（slice）或计数器轨道（counter track），只能证明这次采集中出现了对应事件；要把它上升为机制结论，还需要与固定版本源码中事件的生成位置、参数含义和触发条件对应。

标注的使用方式

读到关键判断时，先核对版本，再看路径与符号，最终确认结论是否覆盖当前设备。若正文还带有待核对标记，或证据只覆盖有限的版本和设备，该段适合作为排查入口，不应直接用于生产决策。源码、运行数据与设备条件能互相对应时，结论才足够稳。