Quartz 4

🔍 搜索

连接知识库 · 对抗审查记录

16 min read

连接知识库 · 对抗审查记录

第一轮 7 个 Explore Agent 产出后，由主控亲自 grep / 直读源码做的独立对抗核实。 凡 Agent 转述与源码冲突，以本文件为准。 核实日期：2026-07-15 · 分支 dev · HEAD 583a310c8

对抗审查价值极高——纠正 2 处 Agent 误判、确认 3 个真实 bug、抓出 1 处转述笔误。这正是”文案/数值必须直读源码、配独立对抗审查”的实践。

纠正的 Agent 错误（2 处）

❌→✅ 纠正 1：BluetoothDisconnectConfirmDialogFragment 不是”四类对话框之一”

  • 配对 Agent 把它列为蓝牙”四类对话框”之一（Pairing/Picker/DisconnectConfirm/CarplayChoose）。
  • 对抗核实：全仓库 grep BluetoothDisconnectConfirmDialogFragment，除类定义内部 newInstance 自引用外零外部调用。
  • 真相：该类是 AOSP 遗产死代码，未被 MiCar 实例化。实际”断开确认”走 AlertDialog.MiCarBuilder 内联实现（BluetoothBondedDevicesPrefController.java:220-243 的 showDisConnectConfirmDialog）。
  • 文档处理：蓝牙配对章节改为”三类对话框”（Pairing/Picker/CarplayChoose），DisconnectConfirm 标注为死代码。

❌→✅ 纠正 2：isDeviceClassTypeSupport 的 AUDIO_VIDEO 过滤不是 bug，是有意设计

  • 蓝牙发现 Agent 标注”AUDIO_VIDEO major 在 condition1 即 false，导致耳机/音箱/车机音频被排除，与车机应能连耳机的直觉相反，值得 review”。
  • 对抗核实（直读 MiBluetoothUtils.kt:131-160）：
    • condition1：AUDIO_VIDEO / UNCATEGORIZED major → false；COMPUTER → 非 laptop；WEARABLE → 仅 pager；else（含 PHONE）→ true
    • condition2：AUDIO_VIDEO_CAR_AUDIO / HEADSET / HEADPHONES → false；else → true
    • res = condition1 && condition2
  • 真相：车机蓝牙扫描列表只显示手机类设备（PHONE major），屏蔽耳机/音箱/车机自身/电脑(除laptop)/可穿戴(除pager)。这是符合车机场景的预期设计——车机蓝牙主要用于手机互联（电话/通讯录/CarPlay），不连蓝牙耳机听歌（车机走本地音频）。蓝牙耳机若要配对走其他路径（手机主动/CarPlay 流程）。
  • 副产物：condition2 里的耳机分支（:151-154）因 condition1 已 false 而成死代码（防御性冗余）。
  • 文档处理：蓝牙发现章节明确写”预期行为”，并标注 condition2 耳机分支为死代码。

确认的真实问题（3 个 bug，均已带 file:line）

⚠️ Bug 1：dcddif TelephonyUtil.isSupportSatelliteByDevice 反射 receiver 传错

  • 直读 settingsPage/micarConnectionSettings/src/dcddif/java/.../TelephonyUtil.kt:35-63
  • :43 telephonyMgrExDefault = getDefaultInsMethod.invoke(null) ← 正确取到 TelephonyManagerEx 实例
  • :47 isSupportSatellite = method2.invoke(_defaultMgr) ← 却传了 _defaultMgr（TelephonyManager 实例，非 Ex）
  • method2 是从 TelephonyManagerEx 类取的 isSupportSatelliteByDevice，receiver 类型不匹配 → IllegalArgumentException → catch → 返回 false
  • 后果：DCD 平台 isSupportSatelliteByDevice 恒为 false → 卫星分组恒隐藏。对比同文件 setSatelliteEnable:72-79 传的是正确的 telephonyMgrExDefault，证明这是笔误。
  • 实际影响：取决于 DCD 平台是否真支持卫星（若本不支持则无感；若支持则真 bug），需现场验证。xcddif 版本（:46-47）传值正确。

⚠️ Bug 2：SatelliteSettingDialog TelephonyManager 注册/解注册实例不一致

  • 直读 satellite/SatelliteSettingDialog.kt
  • :137 注册：mTelephonyManager?.createForSubscriptionId(finalSubId)?.registerTelephonyCallback(...)
  • :275 解注册：mTelephonyManager.unregisterTelephonyCallback(mServiceStateListener)
  • createForSubscriptionId 返回新实例，在原 mTelephonyManager 上 unregister 解不掉新实例上的 callback → callback 泄漏 / 解注册失败。

⚠️ Bug 3：manifest 同时注册 SATELLITE_COMMUNICATE 与 SATELLITE_COMMUNITE

  • 直读 AndroidManifest.xml:109,113：同一 Activity 注册了 android.settings.SATELLITE_COMMUNICATE（正确）和 android.settings.SATELLITE_COMMUNITE（少一 C，拼写错误）。
  • 推测：调用方某处发的是拼错的 COMMUNITE，manifest 两个都收以防漏。应统一拼写。

抓出的转述笔误（1 处，印证”Agent 转述不可信”）

  • 车机互联 Agent 在能力总表里写 CarPlay 判断包名是 com.mi.car.carplay / com.desaysv.carlink。
  • 对抗核实（直读 ConnectionUtils.kt:41-47）：第二个包是 com.desaysv.carplay（德赛西威 CarPlay），不是 carlink。
  • 教训：与 2026-07-09 后屏投影知识库的经验一致——具体包名/文案/数值必须直读源码，绝不采信 Agent 转述。

互相印证（可信度高，可直接采用）

以下结论被 ≥2 个 Agent 独立指出且无矛盾，已交叉确认：

  • settingslib 源码位于 base/settingsLibAndroid/src/{dcddif,xcddif}/java/com/android/settingslib/bluetooth/（蓝牙发现 + 配对 Agent，CachedBluetoothDevice.startPairing 行号 613 一致）
  • 双 flavor 机制：TelephonyUtil / WifiPickerTracker 工厂 / LocalBluetoothAdapter 均有 dcddif + xcddif 两套（连接框架 + WLAN + 蓝牙发现 + 车机互联 Agent）
  • 手车互联能力判断全靠包名预装（连接框架 + 车机互联 Agent，包名清单一致）
  • DCD 平台 = ro.board.platform == msmmnile（连接框架 + 车机互联 Agent）
  • 蓝牙扫描持续循环、mIsControllerActive 双检、解配设备一次性拦截（3 个蓝牙 Agent 一致）

第二轮：蓝牙知识库 2.0 对抗（2026-07-23）

14 篇新文档 + 02 修订 + README 改造。每篇 fan-out 调研 Agent → 独立对抗审查 Agent → 主控亲自 grep/直读 bugreport Review → 落库。对抗价值极高——纠正主控 1 处核实错误、抓出 5 处技术错误、补 3 处遗漏。

🚨→✅ 纠正主控核实错误（1 处，最关键）

  • 主控称”2956 已修复（commit 7239803be）“——对抗推翻：31/41 对抗审查用 git merge-base --is-ancestor 7239803be HEAD(返回非祖先) + git fsck(dangling) + 直读 onCancel(旧版) 证实 7239803be 是悬空提交，已被 reset，bug 仍在。主控此前被 git branch --contains（受本地 reflog 影响）和某次 sed 读取误导。教训：核实 commit 合入用 merge-base --is-ancestor，勿信 branch --contains；落库前直读当前文件内容。已修正 10/11/12/20/22 五篇 + 41/31 的”已修复”表述。

🚨 对抗抓出的技术错误（5 处）

  1. CTKD 方向写反（11 对抗）：草稿”LTK 经经典通道分发”，实际 BR→LE 派生（smp_calculate_long_term_key_from_link_key @45.087）；44.855 落 Link Key vs 45.087 派生 LTK（root-cause.md §4.1 同步纠正）。
  2. PAN isAutoConnectable 误记 true（12 对抗）：实为 false（PanProfile 三 flavor）。
  3. ACTION_PAIRING_REQUEST 归属误植 AdapterService（20 对抗）：实为 BondStateMachine(:516/:659)。
  4. CarPlay deeplink 笔误（33 调研自纠）：connection://carplay&bt_mac= → mis://complex/connect?action=carplay_connect&bt_mac=(ConnectionConstants:5-6)。
  5. 行号 if-check vs call 混用（32 对抗）：双蓝牙”调用点”用判定行，改调用行 :90/:526/:142/:295/:111。

➕ 对抗补出的遗漏（3 处）

  1. 双蓝牙第五拦截点（32 对抗）：02 文档”三处”漏 BluetoothBondedDevicesPrefController:295（主页已配对点连接），实为五处。
  2. CarPlay 黑名单清除第五路径（33 对抗）：漏 BluetoothUnbondedDevicesPrefController:517（点未配对设备先清黑名单）。
  3. f3dif 广播数差异（21 对抗）：f3dif 20 个广播（新增 AUTO_ON），vs xcddif 29 / dcddif 18。

🔬 对抗交叉印证（高可信）

  • f3dif = 纯 AOSP、黑名单失效：21/31/33 三篇对抗独立印证（0 MICAR-PORTING 标记、无 isCloseAutoConnectDevice、onBondingStateChanged:1147 双参直 connect）。这是 A17 主线真实回归风险（H6）。
  • BondStateMachine SDP 延迟：20 对抗读 AOSP 源码确认 :583 “wait for SDP complete”、3000ms 超时。

互相印证（≥2 Agent 无矛盾）

  • isDeviceClassTypeSupport:141-170、CarPlay UUID ConnectionUtils:30-31、双蓝牙上限=2、2956 时间线（多 Agent 一致）。

f3dif 三个 flavor 行号勘误（21 对抗三栏，落库必引）

项目dcddifxcddiff3dif(A17主线)
BluetoothEventManager 广播数182920
BluetoothCallback 方法数101511
onBondingStateChanged单参:839单参:1050双参:1147
isCloseAutoConnectDevice:821/:853:1032/:1079不存在
MICAR-PORTING 标记10330(纯AOSP)
connect 链终点adapter:402mDevice:544mDevice:611

第三轮：60 系列 CachedBluetoothDevice 精讲 对抗（2026-08-20）

对象：蓝牙/60-CachedBluetoothDevice精讲篇/（60-68 共 9 篇，2026-08-20 新建）。 方法：3 个红队 Agent 并行逐章核查——V1 核 60-63（抽查 210 处）、V2 核 64-67（约 180 处）、V3 核 68 案例事实（对照 jira-data/{KEY}/analysis/root-cause.md 原文）。全部发现已落稿修正。

核查统计

红队范围抽查属实P0P1P2/P3
V160-63 章2101882128
V264-67 章~180~1602314
V368 案例卡8 案例6 忠实024
合计9 章~570~89%41726

❌→✅ 纠正的 P0（4 处，均已改稿）

  1. “五个诞生入口”→四个（V1）：ActiveDeviceChangedHandler（BEM:135-140 注册）不是诞生入口——findDevice 结果直接交 dispatch 做音频路由（HADM:485），全程无 addDevice；全 BEM 仅 4 处 mDeviceManager.addDevice（:212/:375/:438/:590）。63 章已改四入口 + 反面澄清框。
  2. CBDM synchronized 计数（V1）：正文”13 个方法”与括号 19 个行号自相矛盾；实测 20 个 synchronized 方法 + addDevice 内 1 个块（:139），列表补 :368。63 章已改。
  3. setEnabled 行为（V2）：64 章草稿”开=已连接时顺手触发连接”是老 AOSP setPreferred 残留语义——逐一核对 7 个 profile 的 setEnabled 全部只写 connectionPolicy，零连接触发。已改为”幂等写保护”表述并加 7 profile 核对结论。
  4. 不存在的方法名（V2）：getBtClassDrawableWithFallback 在三 flavor 全仓 0 命中=方法不存在（空洞真）；实际存在的是 BluetoothUtils.getBtClassDrawableWithDescription（:157，CBD:2605 在用）。65 章已改并加”别按老资料找”警示。

P1 级要点（17 处，均已改稿）

  • V3：3187 摘要三分支 :104 是”正在连接”非 else（else 在 :106）；2960”关开恢复”系 root-cause 标记的待证候选（两解释分叉），不得写成定论。
  • V1：CBDM 构造行号对调（HearingAid :64-65 / Csip :66-67）；组管理器自身无锁（CsipDeviceManager 0 个 synchronized），串行化靠 CBDM 持锁调用；syncBluetoothState :245-252；xcddif 早退 :274；:330 非 :331；DC:811 非 :812；构造 :230-242；setRssi :991-996；HADM init :274-297。
  • V2：performConnect 两行号（:17/:19）；PBAP 可见判据 :68-69；getBtDrawable kt:328-353（else :349-350）。
  • V3 案例术语：3205 机制是 isBusy 含 DISCONNECTING（“防抖放行”属 3950）；“出局式”= outgoing 非 out-of-band/OOB。

教训（写给下一轮写文档的自己）

  1. 计数枚举型断言（“N 个入口/方法/字段”）必须先 grep 再落笔——本轮 4 个 P0 有 3 个是这类。
  2. 引用方法名前 grep 确认存在——老资料/记忆里的 API 名（getBtClassDrawableWithFallback、connectAllEnabledProfiles）在新基线可能已不存在或改名。
  3. 行为断言（“开=顺手连”）要逐实现类核对，不能凭接口语义或旧版记忆外推。
  4. 案例的”待证”结论必须带着”待证”标签转述——写成定论会污染下游读者。
  5. 案例行号漂移是常态（1922 的 :316 与 134132 的 :331 是同一调用点）——已在 68 章头部加行号时效声明。

第四轮：80 系列 + 23 章 对抗（2026-09-06）

对象：新建 蓝牙/80-Auracast广播QR篇/（80/81 两篇 + 篇内记录）+ 20-Android框架篇/23-BluetoothCallback契约与接入指南.md + README/22/51/基准的事实修正。 方法：主控 session 亲读源码（BluetoothBroadcastUtils、BluetoothLeBroadcastMetadataExt 全文）后出 12 条声明，1 个红队 agent 盲核（不接触主控推理），全部 PASS 才落稿。

核查统计

范围声明PASSFAIL
flavor/build（C1-C2）220
QR 链路（C3-C6、C11）550
Callback/EventManager（C7-C10）431
基线行数（C12）110

❌→✅ 纠正的 P0（1 处）

  1. “BluetoothPreferenceController 是除 EventManager 外唯一实现”为假（C10）：全仓另有 5 个实现——BluetoothMainEntrySettingsFragment.java:56（主源集）、f3dif 专属 BluetoothEventManagerExt.kt:28（object : 写法）、LocalBluetoothManagerExt.kt:28、hearingdevices/ui/PresetUiController.kt:66（字段持有匿名实现）、AmbientVolumeUiController.java:63（多接口 implements 列表）。主控旧 grep 模式 implements BluetoothCallback|BluetoothCallback> 漏掉 Kotlin object : 与逗号分隔的多接口声明。23 章 §3 已按 6 实现者落稿。

措辞精确化（2 处，均已按此落稿）

  • mCallbacks（xcddif BluetoothEventManager:71）声明类型是 Collection<BluetoothCallback>，实例化为 CopyOnWriteArrayList——表述用”声明 Collection/实例 COW”。
  • f3dif 的 build.gradle:88 aidl.srcDirs 指向 src/main/aidl（其余 flavor 为 src/main/java），细节差异记录在案。

本轮基础事实修正（写入 README/22/基准）

  • f3dif 已合入 dev（262 文件；b57402a19 触及 3 个）；f3dif CachedBluetoothDevice.java 与 dev_a17_0610 同 blob（d19660e0…）→ 60 系列 f3dif 行号在 dev 可复用，推翻 2026-08-23 旧结论。
  • sourceSets 5 变体（build.gradle:56-90），新增 xcd_global_a14→xcddif+global。
  • Auracast QR：Utils 仅 xcddif/f3dif；SCHEME 前缀 "BT:" vs "BLUETOOTH:UUID:184F;"（各自 :46，两文件唯一差异）；dcddif 无任何 Broadcast/LeAudio 类。

教训（写给下一轮）

  1. 找接口实现者，单一 grep 模式必然漏：implements X 漏掉 object : X（Kotlin）与 implements A, B, X（多接口）与字段类型声明。至少三模式组合：implements X / object : X / X>。本轮唯一 FAIL 即此。
  2. “某分支独有”类结论有保质期：分支合并（f3dif→dev）会让旧警告失效；复核用 git ls-files + blob 哈希比对（git rev-parse branch:path），别只看目录存在与否。
  3. 声明先行、盲核在后：把结论拆成可证伪的 C1-Cn 再交红队，比”帮我审一下文档”有效得多——FAIL 的那条正是被拆解后暴露的。

第五轮：CachedBluetoothDeviceManager 坑位 对抗（2026-09-06）

对象：42 章新增 §7 + 63 章两处带日期增补 + 基准 §8。 方法：主控亲读 CBDM 全文（xcddif 581 行）出 9 条声明，1 个红队 agent 盲核。

核查统计

9/9 PASS，无 FAIL/PARTIAL。

本轮特色：先查重再入库

  • 入库前先 grep 知识库既有覆盖：9 条里”clearNonBondedSubDevices 首组 return”与”onDeviceDisappeared 死码”63 章已记（:183/:146），不重复落稿，只写增量（onScanningStateChanged 同款 return、xcddif 版事实）。
  • 红队补充事实升级定性：clearAllDevices 仅 xcddif 定义（dcddif/f3dif 无此方法）——“死码”升级为”xcddif 独有死码”。

措辞精确化（落稿已按此）

  • 不对称范围收窄：仅 CSIP 组员两方向不对称；助听 subDevice 两方向对称（:407-417）。
  • C9 分支实为 != BOND_NONE 而非 == BONDED（语义等价，42 §7.5 已标注）。
  • C3 有一处注释级误命中（MiBluetoothPickerDialogFragment.kt:119，注释提及非调用），不计调用点。

教训

  1. “级联解配对”这类行为结论必须标 flavor——f3dif 与 xcddif 同名方法已分叉，63:200 旧表述对 xcddif 不准确，本轮已加注。
  2. 查重先行省一次重复落稿（本轮 4 个候选新点砍掉 1 个已覆盖的）。

Graph View