70 篇对抗核验记录 — 红队审查与修复台账
审查对象：70-总览、71、72、73、74、69 共 6 篇。 审查方式：两个红队 agent 独立并行（#1 锚点核对 + 语法/链接；#2 逻辑链与覆盖面攻击），互不知晓对方结论；源码仓只读。 基线：MiCarSettings dev 分支，2026-08-23。
1. 审查规模与总结论
- 红 #1：约 150 个 file:line 锚点逐个回源码核对、12 条重点论断、4 个 mermaid 图、全部交叉链接。
- 红 #2：40+ 锚点抽查、4 类”零调用”断言、3 个 manager 实例入口全量 grep、14 个交叉引用目标验证。
- 头条论断全部扛住复核（见 §3）；确认必修问题 8 个（红 #1 的 3 + 红 #2 的 5），覆盖缺口 4 个，均已修复（§2）。
2. 确认的问题与修复台账（全部已修）
| # | 来源 | 文件 | 问题 | 修复 |
|---|---|---|---|---|
| 1 | 红#1 | 72 §七对照表 | MIUI 标记锚点 :381 指向普通代码行（BluetoothDevice device = intent）；且 BT_LeAudio 标记不在 BEM（实际在 CBD :546/:1777），归属误导 | 改为 BEM 实际标记：BT_MIUIBluetoothFrame(:78、:184)、BT_BluetoothHalfClose(:179、:409、:422、:456)；BT_LeAudio 显式注明在 CBD |
| 2 | 红#1 | 71 §4.2 | xcddif A2dpProfile 构造锚点 :106 错位 5 行（:106 是 mContext = context） | 改为 :110-112（MICAR-PORTING 块），赋值行 :111 |
| 3 | 红#1 | 70 §6 | 链接 _对抗核验记录-70篇.md 当时不存在（死链） | 本文件即为其补建 |
| 4 | 红#2 | 69 §5 第 7 步 | 把 getCarConnectionSummary() 写成车机 UI 实际刷新路径，与 74 章”死链”结论矛盾 | 改为 MiCar 三态摘要（getDeviceSummary），并加死链警示与 74 章指引 |
| 5 | 红#2 | 72 §4.1 | ”一次广播实际只产生 2 次属性分发”绝对化——dcddif 副耳不在顶层列表（CBDM:107-110 吸收后不 add），新 active 0 次分发、主设备被误刷 false；陈旧位残留可 >2 | 加边界框：限定”顶层列表内、无陈旧位”；补副耳/陈旧位/多广播三个反例；70 章自测题同步修正 |
| 6 | 红#2 | 72 §2.3 | manager 入口清单只列 MiBluetoothUtils 一处，论证前提不全 | 补全三入口（MiBluetoothUtils.kt:67 / VoiceAssistProvider.kt:416 settingsBaseUi / BluetoothRequestPermissionActivity.java:97 globalOnly），均 null handler；“主线程分发”补 API 语义推断标注 |
| 7 | 红#2 | 73 §1.1 | ”setActiveDevice 返回=受理≠生效”以肯定语气写成事实 | 补 ⚠️ 框架语义推断标注（栈内同步/异步不在本仓视野） |
| 8 | 红#1⚠️/红#2 | 74 §5.2、73/69/70 | 助听器资源名缩写不精确（both 实为 left_and_right）；connect() 行号 :360 应为签名行 :359 | 资源名写全（bluetooth_hearing_aid_left_active/right_active/left_and_right_active）；connect 统一 :359 |
覆盖缺口补充（红#2 提出，均已写入）：71 §8 补 push/pull 幂等的不对称边界（副耳/组员”永不收敛窗口”）；72 §九补第 8 条排障断点（广播报的设备不在顶层缓存列表）；69 §7 补 settingsBaseUi/globalOnly 两个共享单例的消费者；74 §2.2 补跨设备 active 文案示例（X=[2]、Y=[3] 各自正确）；72 交叉引用补 71 篇实链、73 交叉引用补 72/74 实链。
3. 扛住攻击的重点论断（红队复核通过，可放心引用）
setActive()全仓零调用（仅 dcddif CBD:544 / xcddif CBD:730 两处定义；java/kt 多模式 grep 含反射/method reference，红 #1、红 #2、主线三重独立复核一致）。- AOSP active→文案管道死链：
getCarConnectionSummary全仓零调用；getConnectionSummary唯一外部调用点 =getSubDeviceSummary（dcddif CBDM:127 / xcddif :157/:163）；getSubDeviceSummary零调用。 - 无第五条消费链：
isActiveDevice/mIsActiveDevice在 settingslib 之外全仓零命中（含 settingsBaseUi/settingsVehicleLib/settingsCommon/全部 settingsPage）；ACTION_ACTIVE_DEVICE_CHANGED settingslib 外零注册、全部 AndroidManifest 零命中。 - fetchActiveDevices 调用点恰 3 处（dcddif :289/:497/:1328；xcddif :348/:667/:1751）；refreshBluetoothClass 确不调用。
- isActive 由
Objects.equals(cachedDevice, activeDevice)推导（dcddif BEM:228），EXTRA_ACTIVE 全仓未读。 - 主线程分发实质成立：三个 getInstance 入口全传 null handler，create 工厂零调用（结论成立，原论证入口清单已补全）。
- dispatchAttributesChanged 在 dcddif 恰 9 处调用（:501/:536/:574/:613/:621/:661/:669/:696/:816 + 本体 :895-899，宿主方法归属全对）。
- 四下标数组实值（""／“，使用中”／“，使用中（媒体）”／“，使用中（手机）“，两 flavor 中英一致）、isOnCall 三种 mode、60s 看门狗常量与行号、DOUBLE_BLUETOOTH_DEVICE_LIMIT=2、MICAR-PORTING 10/33 处、1456 行——全部命中。
- f3dif 不在本仓（全仓 find 为空；build.gradle:46-67 证实 dcd→dcddif、xcd/global→xcddif）。
- mermaid 四图语法合法；除第 3 条外全部交叉链接有效。
4. 遗留 ⚠️ 待核验项（文中已就地标注）
mService.getActiveDevices()/BluetoothAdapter.getActiveDevices()按框架契约不返 null——仓内无法验证框架侧（71 §4.1）。- 广播发送端行为（sticky/普通、EXTRA_ACTIVE 存在性）基于 framework 公开机制推断（72 §一）。
- handler=null → 主线程分发，是 registerReceiver 标准 API 语义推断（72 §2.3）。
- “setActiveDevice 受理≠生效”为 AOSP 框架语义推断（73 §1.1）。
- LeAudio 构造不走 AdapterUtil 路由是否为有意设计（71 §4.2 / 73 §2.4）。
5. 方法论备注
本轮延续了 _对抗审查记录 的做法并加了一层：研究员 agent 在交付时自报”最可能被推翻的论断”清单，红队优先攻击该清单——8 个必修问题中有 5 个来自研究员自报项，说明自报机制有效。主线对头条论断（setActive 零调用、消费链死链、调用点 3 处）做了第三重独立 grep 复核。