🎯 Seetong 问题雷达 第263期

🔴 问题 1：Android 8.4.1.6 报警（人形侦测／车辆行走）App 端不提醒，在线报警列表回落本地缓存 ｜ 负责人：张威、陈宝旺、许源

1. 现象与覆盖范围

• 现象：同一名用户在 2 分钟内连续提交 2 条反馈，描述「升级后人形运动和车辆行走手机 APP 不提醒」「手机 APP 不提醒人来人往，车来车往」。诉求是设备端已经触发人形／车辆事件，但手机端既不弹提醒、也看不到对应报警条目。
• 涉及反馈：
• 260762（2026-11-01 06:11:07，Android 8.4.1.6，Redmi 23013RK75C，吉林长春农安县，用户 W_YCqONuFVoz，附 Logan 10 893 行）
• 260763（2026-11-01 06:12:35，同用户同机型，附 Logan）
• 存量延续：同一诉求在 2026-10-17 第 247 期已立任务 T-20261017-090729-9de7（「报警功能突然失效与通知不达」）。本期是同族问题的第 2 次复现，按「已知问题新增样本」处理，不重复创单。
• 严重度评分：62 / 100（反馈量 10 ／ 共性 22 ／ 关键度 30）。报警属录像报警类，关键度按 30 计；反馈量按「本期 2 条、1 名独立用户」给 10 分；共性按「1 个品牌 × 1 个机型 × 1 个版本 + 报警链路」计 22 分，样本集中不加大共性分。

2. 神策证据

• AlarmMessage 事件在神策中不存在：SELECT count(*) FROM events WHERE event='AlarmMessage' 返回空结果集。按名称模糊检索 2026-11-01 全量事件，只命中 SiteMessageClick（1 631 次），没有任何报警投递、送达或提醒类事件。报警是否触达、触达几成，在神策侧完全不可观测，本期只能靠 Logan 举证。
• 大盘基线（2026-11-01 自然日，截至 17:00，未跑完故不做趋势对比）：
• CloudPlayback 总 PV 209 241、UV 96 108。
• SiotDevConnectResult 总连接 3 449 465，其中 RELAY 2 464 364（71.4%）、SRFLX 567 423（16.5%）、LOCAL 357 389（10.4%）。近 4 天 RELAY 占比稳定在 71.1%~71.8%，连接形态无突变。
• 以上两项只说明「大盘连接与回放正常」，无法解释个案的报警不达，不作为本案证据。
• 结论边界：神策只能证明「报警链路无埋点」，不能量化漏报率。

3. Logan 关键日志（核心证据）

反查反馈 260762（seetong_42c5397e…83c960ba…，覆盖 04:54–06:11，10 893 行）：

• 账号与设备事实：04:54:49.460 LibImpl-onUserInfoUpdate isUserBind->UserDetailInfoModel{userId=14211502, nickName='啊', phone='15947809286'}，报警页设备快照 deviceSnapshotCount=24。
• 远端报警列表返回空：04:54:52.148 ws onMessage:{"biz":"res_pull_device_alarm_list","data":{"code":200,"msg":"success","data":{"date":"2026-11-01","startTime":"00:00:00","endTime":"04:54:52","hasMore":false,"deviceAlarmList":[]}}}，请求参数为 {"deviceIds":["16171805","21315587","21318073","14888917"],"date":"2026-11-01",…}。
• 页面用本地缓存兜底：04:54:52.299 queryAlarmMessages success … itemCount=0 → 04:54:52.300 requestFirstPage responseCount=0, remoteThumbCount=0 → 04:54:52.352 loadInitialCacheFallbackUiState restored trigger=empty_remote_response cachedCount=75 targetCount=20 targetReached=true → 04:54:52.353 requestFirstPage uses cached fallback because initial remote response is empty。用户看到的 76 条报警全部来自本地缓存，服务端当日报警为 0 条。
• 在线人形报警通道为空：同日多次 requestPendingOnlineAlarmMessages success … itemCount=0 与 syncPendingOnlineAlarmMessages empty（04:54:52、04:55:21、04:55:29、04:55:56 等）。
• 设备状态自证：04:54:50.000 doMsgRspCB-->TPS_MSG_NOTIFY_AUTH_SUCCESS-->devId=16171805 devAuthResp=TS8108D35,0，设备系列 TS8108D35、结果 0 成功，说明设备端链路是通的。
• 报警历史已被清空：queryAlarmDateBuckets success … bucketCount=4, firstDate=2026-10-29, bucketDates=2026-10-29, 2026-10-28, 2026-10-27, 2026-10-26；站内信 member-message/get/list 连续返回 4 条「设备（设备名称：16171805）已被删除」（2026-10-29 13:59／12:17／12:06／10:24）。
• 系统通知权限正常：AlarmMessagePage system notification permission result … granted=true, status=granted（多次出现），排除「系统通知被关」这一最常见解释。
• 推送通道可用：SPushisSupportFirmPush:miui → SPush-Exec getPushScheme-->{"phoneBrand":"miui","firmPush":1,"systemNotification":1,"pushSdk":["hw","xm","op","vi","hr","realme","um"]} → 04:54:52.196 /seetong-sms/push/scheme 返回 {"scheme":"xm"}，小米通道已正确下发。
• 关键引文：
• 2026-11-01 04:54:52.353 [pool-14-thread-1] AlarmMessagePageVM: requestFirstPage uses cached fallback because initial remote response is empty
• 2026-11-01 04:54:53.072 AlarmMessagePageVM: queryAlarmDateBuckets success currentDate=2026-11-01, bucketCount=4, firstDate=2026-10-29

4. 代码定位

• 涉及模块：Seetong-App-Android 报警接收与落库 + seetong-kmp 报警页数据层。
• 关键类：
• app/src/main/java/com/seetong/app/seetong/sdk/impl/LibImpl.java:3563 case SDK_CONSTANT.TPS_MSG_ALARM: onMsgAlarm(pData, nDataLen)
• 同文件 :5356 private void onMsgAlarm(...)，:5397 Global.saveAlarmMessage(...) 落库，:5420 起为提醒分支
• 同文件 :5425-5427 注释原文：「为防止与弹出的离线通知重复，暂时不弹出设备的告警通知」，仅保留 MediaPlayer.play()
• 同文件 :5397 之前有两处早退：:5385-5387「目前只提示 IO 报警触发，不提示 IO 报警消除」；:5389-5393「暂定对策：NVR 云 ID 报出移动侦测报警时，直接不处理此类报警」（TPS_ALARM_TST_TST_MOTION）
• 调用链：SDK 回调 → LibImpl.doMsgRspCB → onMsgAlarm → Global.saveAlarmMessage（本地 SQLite）→ AlarmMessagePageVM.requestFirstPage → WS res_pull_device_alarm_list → 空结果 → loadInitialCacheFallbackUiState（缓存兜底）。
• 关键分支（哪条路径会造成「不提醒」）：

1. 站内提醒被主动禁用：onMsgAlarm 只调 MediaPlayer.play()，不弹通知，前提是「服务端另有一条离线通知」。若服务端当日报警列表为空（本案即 deviceAlarmList=[]），这条兜底通知不存在，用户就既无弹窗也无列表项。
2. NVR 云 ID 移动侦测早退：:5389-5393 对 TPS_ALARM_TST_TST_MOTION 直接 return，注释自述是「暂定对策」。
3. 人形／车辆类型改写条件：:5374-5384 只在 dev != null && !dev.isNVR() 时把报警类型 42→82、44→90；本案设备 TS8108D35 属 NVR 系列，走 NVR 分支，类型不被改写。

• 修复方向锚点：优先核对 res_pull_device_alarm_list 服务端为 0 而设备端 TS8108D35 已鉴权成功的原因（是否因 10-29 设备被删除重建导致报警索引仍指向旧 devId）；其次为 onMsgAlarm 增加「本地已落库但远端未入库」的对账日志，并把「不弹通知」的暂定对策改为按「服务端是否已有对应通知」动态判断。

5. 根因结论

• 置信度：🟡 中。现象与代码分支两路互证（本地缓存兜底、通知被主动禁用、设备鉴权成功但远端 0 条），但缺少设备端事件证据，不能断言是设备未上报还是服务端未入库。
• 一句话根因：设备已鉴权成功，但远端报警列表返回 0 条、在线报警通道为空，页面只能回落 75 条本地缓存；而 App 侧报警提醒早被「防重复」逻辑主动关闭，两条兜底同时失效时用户表现为「完全不提醒」。
• 关键证据链：Logan deviceAlarmList=[] + uses cached fallback + notification permission granted=true + 代码 LibImpl.java:5425-5427 主动不弹通知。

6. 建议下一步

• 任务账本：T-20261101-170334-79ea（P1，captured）；另与存量任务 T-20261017-090729-9de7 同族
• 分配给：消息／报警模块 owner + 服务端报警入库 owner
• 优先处理项：

1. 用 devId=16171805 回查 2026-11-01 00:00–06:11 的服务端报警记录，确认设备端是否真的没有上报人形／车辆事件，判断是「设备未上报」还是「服务端丢弃」。
2. 核对 10-29 该设备被删除重建后，报警索引是否仍指向旧 devId，导致 deviceAlarmList 恒为空。
3. 评估把 LibImpl.java:5425-5427 的「暂定不弹通知」改为条件式，避免远端通知缺失时形成静默黑洞。

• 验证方法：同账号前台／后台／杀进程三态，各触发 10 次人形与车辆事件，统计站内列表出现率与厂商通道（小米 xm）到达率。

🟠 次级问题：Android 8.4.1.6 回放期间仍按系统设定自动息屏

存量问题延续（任务 T-20260926-170258-576a），修复位置与分支覆盖已于第 261 期四路确认，本期只补样本与正向佐证，故降为次级问题，不单独占二级结构。

1. 现象与覆盖范围

• 现象：Android 手机看回放录像，播放过程中按系统「自动锁屏」时长自行熄屏，回放随之中断。另有用户在心愿单里以「建议」口吻表达同一诉求，说明这是持续存在的体验缺口而非一次性误操作。
• 涉及反馈：
• 260731（2026-10-31 20:46:22，Android 8.4.1.6，OPPO PGFM10，陕西榆林，附 Logan）原文：「这个版本不好用，看回放会息屏，超级不方便」
• 心愿单 5614（Android 8.4.1.6）原文：「建议看回放录像的时候，手机屏幕能常亮，就和抖音等大的 App 一样，不用在手机上调熄屏时间」
• 存量延续：第 253／260／261／262 期均为同一问题。本期不新建任务，只追加样本。
• 严重度评分：60 / 100（反馈量 10 ／ 共性 20 ／ 关键度 30）。反馈量按「本期 1 条明确反馈 + 1 条心愿单」给 10 分；共性为单版本、单现象，给 20 分；回放类关键度 30。

2. 神策证据

• CloudPlayback 2026-11-01 分平台 × 版本（当日截至 17:00）：

⚠️ 该「失败占比」不可当作回放故障率使用：旧版本同样落在 33%~40% 区间，说明 is_success=0 反映的是「用户中途退出／单段播放结束」等常态，而非报错。详见文末「口径复核」。

• 与息屏直接相关的字段（屏幕常亮状态、系统息屏时刻、页面前后台切换）在 CloudPlayback 中均不存在，神策无法量化息屏发生规模，本期不引用任何成功率数字下结论。

3. Logan 关键日志

• 260731 的 Logan 已获取，但本期未逐行复核（属已知问题、修复位置已定位），日志证据沿用第 261 期结论：KEEP_SCREEN_ON／keepScreenOn／setKeepScreenOn／FLAG_KEEP_SCREEN_ON／WakeLock 全文件 0 命中，且 onAppBackToFront … action:android.intent.action.SCREEN_OFF 可复现息屏打断。
• 本期唯一新增证据是用户侧的正面诉求（心愿单 5614）：明确要求「像抖音一样常亮，不用去系统里调熄屏时间」，直接印证产品预期与当前实现不一致。

4. 代码定位（沿用并复核）

• 修复代码只存在于 8.4.2 及之后分支：
• seetong-kmp moduleBase/src/commonMain/kotlin/com/seetong/base/page/BasePager.kt:81/85 keepScreenOnWhenVisible()／syncKeepScreenOn()；modulePlayback/.../PlayBackPage.kt:204 覆写为 true。
• Seetong-App-Android kmp/src/main/java/com/seetong/kuikly/KuiklyRenderActivity.kt:84/95 setKeepScreenOn()／applyScreenAwakeRequest()。
• 对应提交：KMP f98e6f3b（2026-09-24，陈宝旺）、Android e840dc3b6（2026-09-24，陈宝旺，BUG 1015747）。
• 分支核对结论（第 261 期已确认，本期无变化）：origin/hotfix_8.4.1、origin/feature_v8.4.1、两端 origin/master 均不含上述提交；线上 8.4.1.6 正属于这条没有任何常亮逻辑的维护线。
• 修复方向锚点：把 f98e6f3b 与 e840dc3b6 成对 Backport 到 8.4.1.x 维护分支——只带 KMP 侧覆写不带宿主窗口标志等于没修。

5. 根因结论

• 置信度：🟡 中。代码与分支覆盖是强证据（第 261 期已四路互证），但本期新增样本 260731 的 Logan 未逐行复核，且神策无息屏字段可量化，故本期整体降为中。
• 一句话根因：8.4.1.x 维护分支从未合入屏幕常亮修复，回放页不向宿主申请 FLAG_KEEP_SCREEN_ON，系统按用户设置的自动锁屏时长照常息屏。
• 关键证据链：分支覆盖表 + 心愿单 5614 的正面诉求 + 本期复发 1 条。

6. 建议下一步

• 任务账本：沿用 T-20260926-170258-576a（P1，captured），不新建
• 分配给：KMP 回放负责人 + Android 宿主桥接负责人（陈宝旺）
• 优先处理项：

1. 立即把两个提交成对 Backport 到 hotfix_8.4.1，出一条 8.4.1.x 热修。
2. 复核本期 260731（OPPO PGFM10）Logan，确认是否与第 261 期的 SCREEN_OFF 链路完全一致。

• 验证方法：系统息屏 15s／30s 两档各连续回放 10 分钟，并验证退出、后台、切页后常亮成对释放。

本期扫描全量（全部沉淀到知识库）

已折叠 5 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。

合计 214 条。「反馈数」按归一化关键词簇计，同簇内的多语言网络提示模板归入第 4 行。

应用市场反馈（2026-11-01 00:00–23:59）

数据来自 skill-appstore-feedback，本期由外部脚本预采集，未重复抓取；原始数据见 knowledge/appstore-feedback/raw/2026-11-01.json。

• App Store：0 条（采集成功，当天确实无新评论）
• 华为应用市场：0 条（采集成功，当天确实无新评论）
• 应用宝：0 条（采集成功，当天确实无新评论）
• Google Play：❌ 采集失败——未配置代理，本期无任何 Google Play 信号
• 荣耀应用市场 / vivo 应用商店 / OPPO 软件商店 / 小米应用商店：⏳ 待导入——未接入自动采集，需后台导出

「采集成功但无评论」与「采集失败」性质不同，不可混为一谈；本期应用市场侧没有可用于聚类的差评。

心愿单亮点

• 5614（Android 8.4.1.6）：看回放时屏幕常亮，不用去系统里调熄屏时间 —— ⭐⭐⭐ 与次级问题同源，是常亮修复的用户侧依据
• 5626（Android 8.4.1.6）：远程网络开关机 —— ⭐⭐ 低功耗设备唤醒入口
• 5618（Android 8.4.1.6）：希望出 50 米摄像距离、更高像素机型 —— ⭐⭐ 硬件选型输入
• 5613（iOS 8.4.1.6）：球机自动巡航，预设多点位按顺序巡视 —— ⭐⭐ 工程场景常用
• 5617（Android 8.4.1.6）：工程宝不支持跨段浏览，改网段后必须开自动获取 —— ⭐⭐ 局域网发现逻辑的真实痛点
• 5610（Android 8.4.1.6）：增加火警和烟雾报警 —— ⭐ 新品类的诉求，超出当前范围

本期心愿单共 22 条，其中 12 条为空白／乱码／无意义内容，未列入。

数据源状态

接口与采集

• 自有反馈接口：✅ total=214 / fetched=214 / complete=true / pages=5
• 心愿单接口：✅ total=22 / fetched=22 / complete=true（上期 ASCII 编码异常已自愈）
• 应用市场：App Store ✅ 0 条｜华为 ✅ 0 条｜应用宝 ✅ 0 条｜Google Play ❌ 未配置代理｜荣耀／vivo／OPPO／小米 ⏳ 待导入

分析与取证

• 神策 query_sql：✅ CloudPlayback、SiotDevConnectResult、事件名模糊检索均成功
• 神策 AlarmMessage：❌ 事件不存在，报警投递／提醒链路完全无埋点，SiteMessageClick 是唯一消息类事件
• Logan：✅ 214 条反馈中 154 条带 Logan，本期 2 个问题各取到 1~2 份可读日志
• 友盟：⏭️ 未查，本期问题均非崩溃／ANR 类
• TAPD：⏭️ 未查，未发现新 BUG 单号，问题 1 为已知任务延续

口径复核：is_success=0 不构成「云回放失败率」

上期第 262 期以 CloudPlayback 的 is_success=0 占比 44.2% 判定「云回放大面积失败」，严重度记 90 并列为 🔴 问题。本期复核后确认该口径不成立：

1. 时间维度是常量不是突变：2026-10-25 至 11-01 逐日占比依次 44.95%／44.79%／44.40%／44.84%／44.69%／43.86%／43.63%／44.56%，8 天最大波动仅 1.3 个百分点，没有一天出现阶跃。
2. 版本维度不区分新旧：旧版本 8.3.14.2（40.5%）、8.3.13.3（40.3%）与主版本 8.4.1.6（45.8%）同处一个区间；若真是 8.4.1.6 引入的回归，旧版本不应同样高企。
3. 重复计数特征明显：11-01 8.4.1.6 Android 失败 61 858 次、失败用户 60 600 人，接近「一人一次」；成功侧 73 307 次对应 73 307 人。两侧重复度不对称，说明失败更像用户中途退出而非报错。

结论：后续报告不得再以该字段计算回放故障率。要真正量化回放可用性，需推动数据侧补 error_code，并区分「用户主动退出」与「播放报错」。

待补证

• 报警链路无埋点：AlarmMessage 在神策中不存在，报警是否触达、触达率、漏报率全部不可观测。建议补一条「报警下发 → 到达 → 点击」三段事件，否则后续所有报警类反馈都只能逐条翻 Logan。
• 问题 1 缺设备侧证据：devId=16171805 在 2026-11-01 00:00–06:11 是否真的产生过人形／车辆事件，需服务端报警库与设备端日志确认。本期只有客户端证据，故置信度定为中。
• 问题 1 的删除重建副作用：该设备 2026-10-29 被删除 4 次（站内信 4 条），报警日期分桶从 2026-10-26 起才有数据，更早的报警在服务端已不可见。需确认「设备删除重建 → 报警索引残留」是否为本例主因。
• 次级问题本期 Logan 未逐行复核：260731 日志已取到，下期可补一次全量关键词扫描，确认是否与第 261 期 SCREEN_OFF 链路完全一致。
• 应用市场长期盲区：Google Play 无代理、四家手商店未导入，本期应用市场信号仍为 0。App Store／华为／应用宝 连续多日为 0 条，需确认是「真实无评论」还是 RSS 拉取窗口问题。
• 心愿单质量：22 条中 12 条为空白或乱码，疑似提交入口校验缺失，可作为产品侧清理项。

下一期 = 第264期 = 2026-11-02-H17.md（明天下午 17:00；窗口 2026-11-01 17:00～2026-11-02 17:00）