04 · MANNPROB-1838 根因：离车提醒弹窗弹两次

JIRA: MANNPROB-1838 车型：Lemans 27B（newton）/ FC7300 ｜ 版本：26.06.27.X.CN.D ｜ 复现：Always 经办：周本成 ｜ 报告：麦洁盈 ｜ 现场时间：2026-06-29 10:47-10:48

现象

LockFltRemdForAlive=0x1（离车锁车失败提醒）触发后，离车提醒弹窗弹出多次（用户报告 2 次，证据显示车端发了 3 次 v=1）。

根因（联合，confidence: medium→high）

车端 30 秒内发了 3 次 v=1(LOCK_FAIL) + App 侧 UnlockDoorTrigger 无 cooldown，每次 v=1 上升沿都拉起 DoorUnLockActivity → 视觉”弹多次”。

• App 全程零下发（铁证：0x61403156 access=READ + milogcat/主txt 双源 set 命令 0 条）→ “App↔车端交互循环”假设排除。
• v=2(CANCEL) 是正常生命周期（DoorUnLockActivity:141-145 if(value==CANCEL) finish()），不是异常抖动。

信号序列（0x61403156，bugreport milogcat 铁证）

sequenceDiagram
    participant Car as 车端 FC7300
    participant VHAL as VHAL
    participant Trigger as UnlockDoorTrigger<br/>(scene aar, 无cooldown)
    participant Act as DoorUnLockActivity
    participant Timer as 8s 倒计时

    Car->>VHAL: v=1 LOCK_FAIL #1 (10:47:38.819)
    VHAL->>Trigger: processSignal
    Trigger->>Act: startActivity 弹窗#1
    Act->>Timer: 8s 计时

    Car->>VHAL: v=0 IDLE (10:47:43.054) 复位
    Note over Act: v=0 不 finish,靠8s计时退

    Car->>VHAL: v=1 LOCK_FAIL #2 (10:48:02.786)
    VHAL->>Trigger: processSignal
    Trigger->>Act: startActivity 弹窗#2

    Car->>VHAL: v=2 CANCEL (10:48:05.704)
    VHAL->>Act: onPropertyChanged CANCEL
    Act->>Act: finish() [:141-145] 弹窗#2 自杀

    Car->>VHAL: v=1 LOCK_FAIL #3 (10:48:07.617)
    VHAL->>Trigger: processSignal
    Trigger->>Act: startActivity 弹窗#3
    Note over Act: 3 次 v=1 = 3 次弹窗

时间	值	效果	milogcat 行号
10:47:38.819	v=1	弹窗 #1	181861
10:47:43.054	v=0	复位（不 finish）	181887
10:48:02.786	v=1	弹窗 #2	181970
10:48:05.704	v=2	#2 finish（CANCEL 正常）	181990
10:48:07.617	v=1	弹窗 #3	182012

责任分层

层	责任	证据强度
车端 FC7300 / 车身控制器	信号源（3 次 v=1 的来源）	强（access=READ + CAN 源 + 双源 grep）
3-MW 中间件	透传，无责	强（CAN→VHAL <1ms）
App UnlockDoorTrigger	放大 + 可修复（无 cooldown）	强（源码 + 实机 mock 坐实）
App DoorUnLockActivity	行为正确（8s 计时 + v=2 自杀）	强

⚠️ UnlockDoorTrigger 在 com.micar.scene aar，本仓库无源码；DoorUnLockActivity 在本仓库 micarLockSettings/.../activity/。本仓库的 DoorUnLockActivity 行为正确，bug 修复点在 scene 侧的 UnlockDoorTrigger。

对抗 Review 结论（实机 mock 坐实）

在报 bug 的同款 newton 车机用 AIDL 注入 0x61403156：

结论	mock 裁决
H2「无去抖每次都弹」	✅ 完全坐实：N 次 v=1 = N 次弹窗，1:1 对应
v=2 正常 CANCEL	✅ 坐实：v=2 让 Activity finish + 不弹新窗
v=0 IDLE 不 finish	✅ 仅复位，Activity 靠 8s 计时退

mock 打不破的疑点（confidence 维持 medium 的原因）

• 车端为何发 3 次 v=1：mock 是手动注入，证明”信号→App”因果链，不证明车端每次锁车都这么发。需 FC7300 活体检测算法/信号矩阵文档定性：多发是设计（每 N 秒重扫 → App 该兼容）还是异常（→ 车端修）。
• 用户报告”两次” vs 证据”3 次 v=1”未闭合（无视频抽帧，推测 #2 仅 3 秒被忽略）。

字段矛盾澄清

字段	值	解读
是否误报	误报	不认同（dispute）：现象真实必现 + 线上监控报警
故障原因 / 如何Fix	代码bug / 进Gerrit	⚠️ Development 面板全空（PR/review/commit=0），疑流程误标
O77S 解决结果	已修复	无 diff 可证，可能是车端协议改或老 bug 回归
报警类型 / 反馈标签	可用性 / 商务合作	监控抓的非用户投诉；商务合作疑似误标

字段维护混乱是本单系统性问题，分析以 bugreport + 源码为准，字段仅弱参考。

解决方案（按证据强度分层）

1. 车端（信号源，需先定性）

排查 FC7300 function 0xfd9f 状态机为何 30 秒内 3 次发 LOCK_FAIL。 前提：先确认多发是设计内（活体检测算法重扫 → App 才是该兼容方）还是异常抖动（→ 车端修）。决定责任最终归属。

2. App 兜底（放大因素，可修复）

• UnlockDoorTrigger.processSignal 加 cooldown，借鉴同仓 AvmTrigger.java:643 的 debounce() 范式。
• ⚠️ 阈值评估：间隔实测 24s/5s，典型 500ms 去抖抓不住；30-60s 冷却可能误杀”用户真未关门需二次提醒”。建议按”同一上锁周期内仅弹一次”而非固定时间窗，需产品确认。
• DoorUnLockActivity 行为正确，不建议改 v=2 自杀逻辑（设计内）。

与 1839 的关系

1838（弹两次）和 1839（车门闪烁全开）同场景同弹窗：

• 1838 = v=1（LOCK_FAIL）→ 弹窗重复触发
• 1839 = v=1（LOCK_FAIL）→ 弹窗首帧车门图标全开闪烁
• 都是 DoorUnLockActivity 首帧初始化阶段问题，建议合修「弹窗首帧数据未就绪前不渲染内容」。

本仓库相关代码

位置	作用
DoorUnLockActivity.java:141-145	if(value==CANCEL) finish() v=2 自杀（行为正确，不修）
DoorUnLockActivity.java:47-49	8s 倒计时到点 finish（行为正确）
DoorUnLockActivity.java:150-155	onNewIntent 重置计时（又一次开闭锁失败）
DoorUnLockActivity.java:158-161	onStop → finish()（每次销毁重建，必现机制）

---

下一篇：05-MANNPROB-1839-根因-车门闪烁全开.md