🎯 Seetong 问题雷达 17:00 第234期

🟠 问题 1：Android 8.4.1.6 回放页「不常亮 + 时间轴不同步 + 缩放不生效」同源聚集 ｜ 负责人：唐胜、陈宝旺、谭伟

1. 现象与覆盖范围

• 现象描述：用户在 KMP 回放页看到三类表现同时存在——(a) 观看回放时手机不保持屏幕常亮，屏幕会自行熄灭；(b) 拖动时间轴时画面时间与时间轴状态不同步；(c) 双指放大回放画面后，画面变换未跟随缩放，左下角仍有残留画面。
• 涉及反馈：257450（Android 8.4.1.6 / realme RMX3461 / 江苏苏州常熟 / 15:58:32，Logan 可读）、257394（Android 8.4.1.6 / Redmi M2012K11AC / 广东江门 / 10:57:09，Logan 可读）、257383（Android 8.4.1.6 / OPPO PHJ110 / 河南开封 / 10:00:07，Logan 可读，「设备没法回放」）、257446（Android 8.4.1.6 / vivo V2164A / 山东临沂 / 15:16:27，Logan 无有效内容）
• 覆盖维度：1 平台（Android）× 1 版本（8.4.1.6）× 4 机型（realme / Redmi / OPPO / vivo）× 3 地区（江苏 / 广东 / 河南）＝ 3 个维度
• 时间分布：4 条分散在 10:00 ~ 15:58 之间，非单点突发
• 严重度评分：62 / 100（反馈量 20 / 共性 20 / 关键度 30）
• 反馈量 20：窗口内 4 条回放类反馈（3～5 条档），其中 3 条为可读 Logan 的独立样本
• 共性 20：4 机型 × 3 地区 × 1 版本（2 维）
• 关键度 30：录像回放类，取 30（低于设备掉线/远程查看的 40）

2. 神策证据（核心数据源）

• 事件可用性核验：

• 关键缺口：回放链路的屏幕常亮动作没有任何服务端埋点。Logan 中 KuiklyRenderActivity.setKeepScreenOn 已在客户端打日志（SCREEN_AWAKE_TAG），但该日志不上报神策，因此无法从服务端回答「有多少回放会话请求过常亮、多少被拒绝」。这是本期最重要的证据边界。
• 趋势判断：无法下趋势结论。NvrDeviceVideoPlayback 的日均 1~5 次量级不足以支撑任何趋势或分布推断，禁止用该事件的口径代表线上回放整体情况。

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

• 反馈 257450（realme RMX3461 / 江苏苏州，405567 bytes / 21127 行，覆盖 10-15 全天含 15:29 时段）
• 该用户当日多次进入 KMP 回放页：[L5256] KMP_SCAN_TRACE-onCreate page=PlayBackPage、data={"devId":"9388193-CH-2",...,"fromPreviewPlayback":true,"canRotate":true}
• 回放正常启动并出首帧：

> [L5411] 2026-10-15 10:04:44.640 RecordPlayerView-startReplay: devId=9388193-CH-2, date=20261015090444, recordType=268435455 this=224737753 oldViewId=-1 oldOwner=null renderer=42987422
> [L5419] 2026-10-15 10:04:45.123 LibImpl-onNvrReplayResp, act=0,have audio=1,video codec=H264
> [L5425] 2026-10-15 10:04:45.715 RecordPlayerView-onRecvFirstFrame: devId=9388193-CH-2 this=224737753 viewId=29 owner=42987422 renderer=42987422 isOwner=true

• 常亮证据（关键）：全份 21127 行日志中 Screen awake 命中 0 次。代码里 KuiklyRenderActivity.setKeepScreenOn（KuiklyRenderActivity.kt:84）必然打印 "Screen awake requested=..." 与 "Screen awake applied=..."（:90 / :96），未打印即表示该回放会话从未发起常亮请求。
• 同一 Activity 内其其它 KMP 页面确实发起过请求：[L2647] Screen awake requested=false, page=DeviceListPage（DeviceListPage 的关闭请求存在，说明桥接链路本身可用），反衬回放页没有对应请求。
• 时间轴不同步证据（关键）：

> [L5430] 10:04:47.749 timeline time changed, source=portrait, timeSec=32958, text=09:09:18, stateTimeSec=32690
> [L5432] 10:04:47.767 timeline time changed, source=portrait, timeSec=33053, text=09:10:53, stateTimeSec=32690
> [L5434] 10:04:47.786 timeline time changed, source=portrait, timeSec=33115, text=09:11:55, stateTimeSec=32690
> [L5436] 10:04:47.801 timeline time changed, source=portrait, timeSec=33165, text=09:12:45, stateTimeSec=32690
> [L5438] 10:04:47.814 timeline time changed, source=portrait, timeSec=33249, text=09:14:09, stateTimeSec=32690
> [L5440] 10:04:47.833 timeline time changed, source=portrait, timeSec=33299, text=09:14:59, stateTimeSec=32690
—— 在 98 毫秒内 timeSec 从 32958 变到 33299（跨 341 秒），而 stateTimeSec 始终冻结在 32690。这与用户原话「回放时间转换不同步」逐字对应。

• 非预期事件：同会话内 receive playback play failed event, result=0 反复出现（[L5418]、[L5424]），result=0 表示非失败码，属误报回放失败，与任务 T-20261014-090647-bbbe（startReplay 与失败事件竞态）同族，本期作为同页并发问题记录。
• 反馈 257394（Redmi M2012K11AC / 广东江门，覆盖 09:13 ~ 09:1x）
• 回放正常启动出首帧：[L7893] RecordPlayerView-startReplay: devId=45809651 ... viewId=29、[L7915] receive playback play failed event, result=0
• 缩放不生效证据（关键）：

> [L8288] 09:14:01.326 track playback event elementId=playback_card_timeline_zoom_long_press_in
> [L8289] 09:14:01.329 PlayBackPage:applyZoomToTimeline, zoomIn=true, fullscreen=false, immediate=true
> [L8292] 09:14:01.382 PlayBackPage:applyZoomToTimeline, zoomIn=true, fullscreen=false, immediate=true
> [L8295] 09:14:01.441 PlayBackPage:applyZoomToTimeline, zoomIn=true, fullscreen=false, immediate=true
而画面变换日志全程为：
> [L7557] 09:13:48.957 RecordPlayerView-updateTransform scale = 1.0---offsetX = 0.0---offsetY = 0.0
> [L8417] 09:14:04.973 RecordPlayerView-updateTransform scale = 1.0---offsetX = 0.0---offsetY = 0.0
> [L9081] 09:14:18.766 RecordPlayerView-updateTransform scale = 1.0---offsetX = 0.0---offsetY = 0.0
—— applyZoomToTimeline 已连续下发 3 次 zoomIn=true，updateTransform 的 scale 始终为 1.0、偏移始终为 0.0，即缩放事件未传递到视口变换层。这正是用户「回放放大左下角有画面」的直接机制。

• 反馈 257383（OPPO PHJ110 / 河南开封，覆盖 09:04 ~ 09:42）
• 回放链路成功：[L16555] searchNvrRecByTimeEx ... devId=[31668148] 20261015 → [L16631] startReplay: devId=31668148, date=20261015072835 → [L16636] onNvrReplayResp, act=0, audio=1, video codec=H265 → [L16643] mark card playback first frame（约 880 ms 出首帧）
• 该用户在本份日志内两次回放均成功出首帧，与反馈「设备没法回放」不一致。判定为失败瞬间未被 Logan 覆盖（日志起点 09:04，用户 10:00 提交反馈），不作根因使用。
• 反馈 257446（vivo V2164A / 山东临沂，82310 bytes / 3927 行）：日志内无任何回放页记录，为无效样本，标「Logan 未覆盖问题时段」。
• Logan 结论：257450 与 257394 两份样本同时覆盖了问题发生的动作时刻，且分别精确对上用户的 (a)(b) 与 (c) 两类描述——本问题的两条主证据链均来自 Logan 直证，置信度因此为「中」而非「弱」。

4. 代码定位（详细）

• 涉及模块：KMP 回放页（Android 宿主）— Seetong5.0ForSeetong/Seetong5.0/kmp/ 与 Seetong5.0ForSeetong/Seetong5.0/app/
• 关键类与锚点：

1. 常亮桥接（链路完整但无人调用）

• KuiklyRenderActivity.kt:84-92（setKeepScreenOn(pageName, enabled)，入参落到 screenAwakeRequested 并打印 SCREEN_AWAKE_TAG）
• KuiklyRenderActivity.kt:94-102（applyScreenAwakeRequest()：window.addFlags(FLAG_KEEP_SCREEN_ON) / clearFlags，受 isActivityResumed && screenAwakeRequested 联合约束）
• KMPBridgeModule.kt:108-113（原生桥接方法 "setKeepScreenOn"，从 params 取 pageName / enabled）
• 结论：宿主侧接口齐备，但全仓库 setKeepScreenOn 的调用者只有这一处桥接分发（KMPBridgeModule.kt:108），KMP 页面侧不存在调用点。 即回放页从未发起常亮请求——与 257450 日志零 Screen awake 完全吻合。
• ⚠️ 需注意：本仓库工作区为裁剪视图，KMP 前端页面（Kotlin/JS 侧的 PlayBackPage 实现）不在当前工作区，「调用点完全不存在」需 owner 在前端页面仓库复核；但不改变「257450 该次回放确实没有发起常亮请求」这一事实。

2. 视口变换 / 缩放链路（事件到达被丢弃）

• PlayBackPage.applyZoomToTimeline（前端页面侧，日志可见 zoomIn=true, fullscreen=false, immediate=true 连续下发）
• RecordPlayerView.updateTransform（RecordPlayerView.kt 内，日志固定输出 scale = 1.0 offsetX = 0.0 offsetY = 0.0）
• RecordPlayerView.startReplay（RecordPlayerView.kt:220-259）：device.m_view_id = playbackWindowId（:243）、device.m_video = openglesRender（:245）、IO 线程 startNvrReplay + 重试 + onReplayError（:249-258）

3. 时间轴状态同步

• KMPTimelineView.getCurrentScale（KMPTimelineView.kt，日志 scale=10.0）
• PlayBackPage.timeline time changed（timeSec 与 stateTimeSec 两个字段分离上报）
• 调用链：AlarmFragment2 / 预览页 → PlaybackPageRouter.openPlaybackPage（PlaybackPageRouter.kt:43-80）→ shouldOpenCrossPlatformPlayback()（:84-96，读 crossPlatformConfig.and）→ openKmpPlaybackPage（:101-141）→ Kuikly PlayBackPage → KMPPlayBackVideoView.playVideoByTime（KMPPlayBackVideoView.kt:223-229）→ RecordPlayerView.startReplay → LibImpl.startNvrReplay
• 关键分支：
• openKmpPlaybackPage 构造页面参数时 isCloudReplay 一行仍处于注释状态（PlaybackPageRouter.kt:120，//put("isCloudReplay", isCloudReplay)），KMP 侧以默认值消费 → 与原生 legacy 路径行为分叉（本期新增关键证据：该注释由 sheng.tang 于 2026-07-27 提交 e65cbfa20 引入，提交信息为「安卓跳转回放参数不携带进入的tab，让KMP控制」，属于有意为之的参数移交，需确认 KMP 侧是否已真正接管该语义）
• 257450 日志 resolveSavedPlaybackTabForCurrentDevice, devId=9388193-CH-2, supportCloud=false, savedTabIndex=1, targetTabIndex=1 表明切页逻辑已由 KMP 接管，但 savedTabIndex 与 supportCloud=false 的组合语义待确认
• 修复方向锚点：

1. 优先：在 KMP 回放页进入/退出时补齐 setKeepScreenOn(pageName="PlayBackPage", enabled=true/false) 调用（宿主侧 KuiklyRenderActivity.kt:84 已就绪，无需改动宿主）
2. 排查 applyZoomToTimeline(zoomIn=true) 到 RecordPlayerView.updateTransform 之间的变换参数传递，确认 scale 是否被硬编码为 1.0 或被后续事件覆盖
3. 收敛 stateTimeSec 与 timeSec 的双字段语义：拖动过程中 stateTimeSec 应随松手提交更新，而非冻结
4. 修正 receive playback play failed event, result=0 的误报过滤（result=0 不应作为失败事件广播）

5. 根因结论

• 置信度：🟡 中
• 一句话根因：Android KMP 回放页的三处页面级状态没有被正确下发/承接——常亮请求从未发起（宿主接口空置）、缩放事件在通往视口变换层时被丢弃、时间轴 stateTimeSec 冻结在拖动起始值；三者同属「KMP 页面状态 → 原生播放器渲染」这一条状态同步链路的系统性缺失，而非三个独立 Bug。
• 关键证据链：257450 的 Logan 同时提供「零 Screen awake 且同 Activity 其它页有该日志」+「timeSec 98 ms 内跳 341 秒而 stateTimeSec 冻结」；257394 的 Logan 提供「zoomIn=true 三次而 updateTransform 恒为 1.0/0.0/0.0」；两条样本与用户原话逐条对应，且跨 4 机型 3 地区聚集。
• 明确不成立的推断：不得写成「8.4.1.6 回放完全不可用」——257383 的 Logan 显示另有一路回放在约 880 ms 内成功出首帧（mark card playback first frame），说明初始化链路本身可用。

6. 建议下一步

• 分配给：唐胜（RecordPlayerView.kt / KMPPlayBackVideoView.kt 与 PlaybackPageRouter.kt 近期主要提交者，2026-07-10 26da460ac、2026-07-27 e65cbfa20）；常亮桥接侧可一并知会 陈宝旺（KuiklyRenderActivity.kt 2026-10-14 855b1fe6 维护者）
• 优先处理项：

1. 补齐回放页 setKeepScreenOn(enabled=true) 调用（最小改动、收益最直接），并为该桥接补埋点，否则下期仍无法从服务端量化
2. 复核 applyZoomToTimeline → updateTransform 的变换参数链路

• 验证方法：真机连续回放 10 分钟确认不熄屏；双指放大后核对 updateTransform 的 scale/offset 是否变化；拖动时间轴后确认 stateTimeSec 随松手更新。回归范围覆盖「卡回放 / 云回放」两种进入方式。

🟠 问题 2：HarmonyOS 1.1.1.11 端回放/预览不可用（第 13 期零 Logan）

1. 现象与覆盖范围

• 现象描述：用户在 HarmonyOS 端进入回放或实时画面看不到内容；同窗口还有「设备离线什么原因」「无缘无故乱扣费」等相邻表述，指向端侧整体可用性体感偏低。
• 涉及反馈：257443（Harmony 1.1.1.11 / HUAWEI CHZ-AL00 / 重庆 / 15:10:21，「看不到」）、257411（Harmony 1.1.1.11 / HUAWEI / 辽宁大连 / 12:47:20，「设备离线什么原因」）、257393（Harmony 1.1.1.11 / HUAWEI / 河南商丘 / 10:37:54，「无缘无故乱扣费」）
• 覆盖维度：1 平台（HarmonyOS）× 1 版本（1.1.1.11）× 3 地区（重庆 / 辽宁 / 河南）＝ 2 个维度
• 版本占比：本窗口 85 条中 HarmonyOS 1.1.1.11 占 15 条（17.6%），为占比第二高的版本（Android 8.4.1.6 为 60 条）
• 严重度评分：60 / 100（反馈量 10 / 共性 20 / 关键度 30）
• 反馈量 10：窗口内直接同类反馈 1 条，相邻可用性反馈 2 条
• 共性 20：3 地区 × 1 版本（2 维）
• 关键度 30：回放/监控可用性，取 30
• 降级说明：本问题因 Logan 零覆盖，子项评分已按最低档保守取值；置信度只能给「弱」。

2. 神策证据（核心数据源）

• 本期未取到 HarmonyOS 专属回放事件的有效数据：NvrDeviceVideoPlayback 近 7 天全平台仅 3 天有量（日均 1~5 次），无法按平台拆分；UCCloudPlayBackResult 返回 0 行。
• 证据缺口说明：神策侧无法回答「HarmonyOS 回放请求数 / 失败数 / 失败码分布」，本问题的神策段结论为空，置信度随之下调。不得用 Android 回放事件的口径代替 HarmonyOS 结论。

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

• 反馈 257443 / 257411 / 257393 三条的 loganFileDownloadUrl 全部为空字符串，按 skill 规则「Logan 未提供」处理，跳过下载，不阻塞报告。
• 本期窗口 HarmonyOS 反馈 15 条 / Logan 0 条，连续第 13 期零覆盖（上一期 2026-10-15-H09 为第 12 期）。
• 影响：HarmonyOS 侧任何问题都只能靠反馈文案聚类，无法定位类名、错误码、状态机分支，也无法区分「网络不可达」「首帧超时」「解码失败」「权限异常」中的哪一种。这已从「数据盲区」升级为结构性产品风险。

4. 代码定位（详细）

• 涉及模块：HarmonyOS 宿主 + KMP 共享层
• 可定位的共享锚点（与问题 1 同一套 KMP 渲染/回放代码）：
• KMPPlayBackVideoView.playVideoByTime（KMPPlayBackVideoView.kt:223-229）→ RecordPlayerView.startReplay（RecordPlayerView.kt:220-259）
• LibImpl.startNvrReplay / onNvrReplayResp（回放应答与 ret 返回）
• HarmonyOS 端专属代码未在工作区定位（当前工作区为 Android 裁剪视图），按 skill 规则标「代码待定位」，不阻塞报告。
• 调用链（推断，未经日志验证）：HarmonyOS 页面 → KMP 共享回放视图 → startNvrReplay → 首帧回调。中间任一环失败均无法从现有证据区分。
• 修复方向锚点：

1. 前置阻塞项：先修复 HarmonyOS Logan 上报链路（任务 T-20261008-142800-9c1e），否则后续所有修复都无法验证
2. 为 HarmonyOS 回放链路补首帧超时兜底与显式失败提示（与任务 T-20260926-170258-2226 的验证方法合并执行）

5. 根因结论

• 置信度：🔴 弱
• 一句话根因：无法给出根因。HarmonyOS 端连续 13 期零 Logan，叠加神策侧缺失可用的 HarmonyOS 回放失败事件，本问题当前只能确认「有用户报看不到」，不能确认失败环节。
• 关键证据链：仅有一条弱证据——1.1.1.11 版本在本窗口反馈占比 17.6% 且含回放类表述；证据不足以支撑任何根因判断。
• 明确不成立的推断：不得写成「HarmonyOS 1.1.1.11 回放功能损坏」；也可能是个别设备离线、网络受限或用户操作问题。

6. 建议下一步

• 分配给：HarmonyOS 端 owner（待定，需按 Logan 上报链路修复的归属确定）；上报链路问题建议由 位冬 牵头推动提级
• 优先处理项：

1. 把 Logan 零覆盖从 P1 提级为团队级阻塞项（已连续 13 期，该条建议自第 12 期起提出，本期无进展）
2. 回访 257443（重庆 / CHZ-AL00）确认「看不到」的入口与复现步骤

• 验证方法：修复 Logan 上报后，取 3~5 名反馈用户复现，按 AddWatchEx 返回值 / 连接类型 / 首帧回调串联核对

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

Markdown 里保留全部反馈（含 -102 等网络问题）；HTML 呈现时渲染器会自动折叠 🟣 普遍性网络问题

（含中/英/俄/法/西/葡/土/阿/日多语言网络提示模板），只展示更有价值的条目，无需在本段手工删减。

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

本期重点反馈明细（非网络类，按时间倒序）

HarmonyOS Logan 覆盖情况（第 13 期连续零覆盖）
本窗口 HarmonyOS 反馈 15 条，Logan 提供数 0 条（0 / 15）。较上一期的 0 / 16 无改善，T-20261008-142800-9c1e 自第 12 期起建议提级，本期仍无进展。

任务账本联动

说明一：问题 1 未新建任务，因其为 T-20260926-170258-576a（熄屏）与 T-20260922-170415-9496（时间轴）的同一期同页双证，而非新形态；新增的「缩放不生效」如在下期复现，即独立建单。

说明二：问题 1 新增的关键事实——PlaybackPageRouter.kt:120 的 isCloudReplay 注释并非遗留调试，而是 sheng.tang 2026-07-27 e65cbfa20「参数不携带进入的tab，让KMP控制」的有意移交——该结论已在本期更正，第233期「需 owner 确认意图」一项已闭环。

数据源状态汇总

心愿单亮点

本期心愿单接口认证失败（invalid_grant），未取到数据，故本段空缺。下期恢复后补。

待补证

1. 回放屏幕常亮缺服务端埋点（问题 1 最大盲区）：KuiklyRenderActivity.setKeepScreenOn 只在客户端打 SCREEN_AWAKE_TAG 日志，未上报神策。需在该方法内补一条事件（建议字段：page_name / enabled / applied），否则无法从服务端回答「多少回放会话请求过常亮、多少被拒绝」。
2. KMP 前端页面调用点需在前端仓库复核：当前工作区为 Android 裁剪视图，setKeepScreenOn 仅见原生桥接分发（KMPBridgeModule.kt:108-113）。「KMP 页面侧完全无调用点」这一结论需 owner 在前端页面仓库确认；但 257450 该次回放确实未发起常亮请求这一事实不受影响。
3. 缩放链路的具体断点：applyZoomToTimeline(zoomIn=true) → RecordPlayerView.updateTransform（恒为 scale=1.0）之间的参数为何丢失，需 owner 读代码确认是硬编码、被后续事件覆盖，还是两个独立变换体系。
4. stateTimeSec 语义未确认：拖动过程中 stateTimeSec 冻结在起始值是设计如此（松手后才提交）还是缺陷，需 owner 明确后才能定修复方案。
5. HarmonyOS Logan 零覆盖连续 13 期：需服务端 / 客户端共同定位上报链路断点，提级建议已连续 2 期未落地。
6. 心愿单接口认证失败：login_and_get_wish_list 返回 invalid_grant: 用户名或密码错误，需核对 ~/.openclaw/secrets.json 中 seetong-feedback 凭据；反馈列表接口同期使用相同凭据正常，故疑为心愿单接口单独鉴权变动。
7. isCloudReplay 移交后的语义未验证：e65cbfa20 明确把 tab 选择权移交 KMP，但 257450 日志 resolveSavedPlaybackTabForCurrentDevice ... supportCloud=false, savedTabIndex=1, targetTabIndex=1 的组合在 supportCloud=false 时是否合理，需 owner 确认。

下一期 = 第235期 = 2026-10-16-H09（明天早上 9:00；窗口 今日 17:00 ~ 明日 09:00）