🎯 Seetong 问题雷达 第266期

🔴 问题 1：HarmonyOS 云台变倍在鸿蒙 6/7 下不生效，且松手可能不停止 ｜ 负责人：冉博麟、谭伟、唐胜、陈宝旺

1. 现象与覆盖范围

• 现象描述：一名 HarmonyOS 用户明确反馈「云台在鸿蒙 6 和 7 操作系统下不能变倍」；另有同一窗口内的独立反馈「云台调整摄像头方向，转不动」，指向云台控制整体在鸿蒙新系统上不可用。
• 涉及反馈：2 条独立反馈（261394、261308），同一时间窗口、同一操作系统家族、不同手机型号。
• 261394：HarmonyOS 8.4.2.4、HUAWEI ALN-AL10、简体中文、2026-11-04 13:07:00、已登录用户，无 Logan、无 fileUrl。
• 261308：HarmonyOS 1.1.2.3、HUAWEI BRA-AL00、2026-11-03 20:00:19，无 Logan、无 fileUrl。
• 版本口径注意：这两条虽同为 HarmonyOS 平台，但 App 版本分属 8.4.2.4（KMP 大版本）与 1.1.2.3（旧鸿蒙独立线），不能合并成一个版本故障；共同点只有「鸿蒙新系统 + 云台」。
• 严重度评分：68 / 100（反馈量 10：24 小时内 2 条同类；共性广度 20：覆盖 2 个 App 版本线 + 2 个机型 + 鸿蒙 6/7 两代系统；业务关键度 25：云台属于远程查看的核心操作，缺失即无法调方向与变倍）。
• 去重判定：检索近 10 期雷达，云台仅在第 259 期以「单点」被归入排除项，从未做过变倍链路深挖；任务账本中也没有 HarmonyOS 云台任务。本期新建 T-20261104-170817-4c2e。

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

• 本期未取得可归因的神策证据，原因写清楚，不硬凑：
• 云台方向与变倍指令走 SDK 私有协议（iotP2PDevPTZControl / nvrP2PDevPTZControlActionWithPte），不上报独立事件；神策侧没有「云台指令下发成功率」这类事件。
• 两名反馈用户均未携带 Logan，无法用 clientId 关联到具体会话；261394 的 clientId 为 57a3c930-9669-b57d-821c-ad5d49d5e42b，可留作下期按 ID 反查 PlayingPopup / MonitorFrameResult 的锚点。
• HarmonyOS 端在神策的覆盖率本来偏低（前几期已记录），即便有事件也难构成有效分母。
• 可用的间接口径：本窗口 HarmonyOS 后台登录活跃正常（Token登录 成功路径当日 18,053 次），说明不是「鸿蒙端整体不可用」——变倍失效是局部能力问题，不是平台崩坏。
• 结论：本问题以代码链路为主证据、反馈原话为现象证据，神策在本期不提供成败率，置信度因此不能给「强」。

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

• 两名用户均未提供 Logan（loganFileDownloadUrl 与 fileUrl 皆为空字符串），属已知的 HarmonyOS 日志缺失模式，不是下载失败。
• 因此本节没有可引用的类名:行号级运行时日志，根因推断改由代码静态链路完成（见第 6 节），并在「待补证」给出补采方案。

4. 代码定位（详细）

涉及仓：~/seetong-app-harmony（宿主 UI 与桥接）+ ~/seetong-kmp（摇杆组件）。

• 入口 A（界面已显式支持的方向控制）：PtzControlView
• moduleBase/src/commonMain/kotlin/com/seetong/base/view/PtzControlView.kt:145-166：把触点按三等分区域映射成 up/down/left/right，抬指走 handleTouchEnd()。
• 同类 :169-171：handleTouchEnd() 把 currentCmd 清空、摇杆回中，并 event.directionHandler?.invoke("stop")。
• 也就是说，方向和停止语义在 KMP 组件里是完整的，问题不在摇杆本身。

• 入口 B（横屏电子变倍按钮）：FullElectronicZoom
• feater/playDevice/src/main/ets/view/videoPreview/comp/FullComp.ets:192-201 setZoom(value, isLong)：
• isLong=false → 直接 ToastUtil.showToast('长按后触发') 并 return，单击变倍被设计成不可用；
• 只有 value != PTZ_CMD.PTZ_STOP 才震动；
• 末行无条件下发 this.devService?.setElectronicZoom(this.devId, value)。
• :215-219 与 :230-234：放大/缩小两个按钮各自是 GestureGroup(Exclusive, TapGesture, LongPressGesture{repeat:false,duration:200})，onAction 下发 zoomtele/zoomwide，onActionEnd 下发 PTZ_STOP。
• :185-189 capacityChange()：isSupport 只由 DeviceUtils.isSupportDigitalZoom(this.capacity) 决定，而 :243 的 .visibility() 依赖 isSupport——能力判定不通过就整组按钮不显示。

• 关键缺陷 1：stop 指令永远下发不出去
• feater/playDevice/src/main/ets/service/DeviceServiceImpl.ets:2115-2130 setElectronicZoom(devId, cmd)：

"<cmd>" + cmd + "</cmd>" + "<duration>3000</duration>" + "<panspeed>5</panspeed>" + "<tiltspeed>5</tiltspeed>"

cmd 被原样拼进 <cmd>，而形参类型是 PTZ_CMD，合法值包含 PTZ_STOP = "stop"、PTZ_ZOOM_TELE = "zoomtele"、PTZ_ZOOM_WIDE = "zoomwide"。

• 松手时传进来的 "stop" 会变成 <cmd>stop</cmd>，而这条 XML 依然带着 <duration>3000</duration>——即使设备端认可 stop，也会被组件自身的 3 秒持续语义与 setTimeout(resolve,1000) 掩盖；
• 更关键的是 setElectronicZoom 没有任何 checkIsSupportPTZ 或指令白名单校验，directionHandler 传入空串时同样会拼出 <cmd></cmd> 下发。
• 后果两种，取决于设备固件如何处理 stop：能识别 → 恰好停止；不能识别 → 忽略未知 cmd，继续按上一个 duration=3000 匀速变倍直到设备端超时。用户感知就是「松手了还在变倍」或「一变就失控」。
• 对照 :1940-2017 的其它云台方法：setLinkagePosition / setCurrentDigitZoom 都显式拼了合法 cmd 名（setCurPos、x、y、mul），只有 setElectronicZoom 把枚举当字面量直接用，这是实现上的破例。

• 关键缺陷 2：两套能力判定口径不一致
• basic/src/main/ets/utils/DeviceUtils.ets:927-933 isSupportDigitalZoom()：要求 ipc_IsSupportPTZ 且 is_iot_ptz_control_bigball（能力位 iot_ptz_232_support）。
• basic/src/main/ets/utils/DeviceUtils.ets:566-571 is_SupportDigitZoom()：只要求能力位 iot_ptz_dig_scale。
• feater/playDevice/src/main/ets/view/ViewPage.ets:652-680：页面主链路（capacityChange 里的 zoomModel）用 is_SupportDigitZoom（iot_ptz_dig_scale），横屏按钮用 isSupportDigitalZoom（iot_ptz_232_support）。
• 结论：同一台设备可能「页面侧认为支持、横屏按钮侧认为不支持」，表现为 261394 所述「不能变倍」（按钮根本不显示），或反过来显示了但 ndk 侧无 232 支持导致指令石沉大海。

• 关键缺陷 3：能力集取不到时静默降级
• basic/src/main/ets/utils/DeviceUtils.ets:668-678 ipc_IsSupportPTZ()：capacity 为空或 undefined 时返回 true（乐观放行）。
• feater/playDevice/src/main/ets/view/ViewPage.ets:620-636：getDeviceCapacity 两条路径都 catch 后返回 ''，只打 =-=获取设备能力集报错，不重试、不提示。
• 叠加后：鸿蒙 6/7 上若能力集拉取失败 → 按钮按「支持」显示（因为 ipc_IsSupportPTZ('')=true）但 isSupportDigitalZoom('') 在 :928 直接 return false，两者矛盾时按钮隐藏；若能力集「拉到了但缺 iot_ptz_232_support」→ 按钮同样隐藏。用户看不到入口，也拿不到任何解释——与 261394 的措辞完全吻合。

• 修复方向锚点：

1. DeviceServiceImpl.ets:2115 增加 cmd 白名单 + 区分「启动变倍」与「停止变倍」两条分支；停止必须走不带 duration 的短指令或专用停止命令。
2. FullComp.ets:192-201 的 setZoom 里，PTZ_STOP 必须是独立分支（不受 isLong 拦截），且 onActionEnd 无论长按是否成立都要尝试停止，避免手势被打断后指令悬挂。
3. FullComp.ets:185-189 与 ViewPage.ets:652 统一到同一能力判定函数（建议以 iot_ptz_dig_scale 为准，iot_ptz_232_support 只作增强），并把空能力集的乐观放行改为「隐藏入口 + 可重试」。
4. ViewPage.ets:620-636 能力集失败补一次重试与超时后置文案，禁止静默返回空串。

5. 根因结论

• 置信度：🟡 中（代码链路证据清晰，但缺运行时日志与神策分母）
• 一句话根因：横屏电子变倍把平台枚举 PTZ_CMD 当字面量拼进 <cmd>，导致 stop 与空指令都变成非法命令；同时横屏按钮与页面主链路使用两套不一致的能力位判定，使部分鸿蒙 6/7 机型要么看不到入口、要么下发后不停止。
• 关键证据链：261394 原话「鸿蒙 6 和 7 下不能变倍」→ FullElectronicZoom 的能力判定只认 iot_ptz_232_support，比页面主链路窄 → 按钮被 visibility 隐藏 → 用户认为「功能没了」；261308「云台转不动」→ doCommand 走 ipc_IsSupportPTZ 乐观放行 + SDK 下发，若指令非法则设备静默丢弃 → 表现为无反应。两条链路都指向「指令与能力判定不严谨」，而非网络或权限。
• 明确不下的结论：不判定为「鸿蒙 6/7 系统 API 兼容性故障」——目前没有一条日志能证明是 setElectronicZoom 被系统拦截；也不把 1.1.2.3 与 8.4.2.4 合并为一个版本缺陷。

6. 建议下一步

• 分配给：HarmonyOS 端负责人（FullComp.ets / DeviceServiceImpl.ets 云台桥接），协同 KMP 摇杆侧确认 directionHandler 的 stop 消费方。
• 优先处理项：

1. 落实「修复方向锚点 1、2」——停止指令必须可下发、必须区别于启动指令；
2. 统一能力判定口径，并让能力集失败可见、可重试。

• 验证方法：鸿蒙 5 / 6 / 7 × 球机 / 枪球 / 带电子变倍球机共 6 组，每组「按住放大 1s / 3s / 10s」「按住缩小 1s / 3s / 10s」「快速点按 10 次」「按住后手指划出按钮再抬起」各 10 轮；验收标准：松手后 200ms 内收到停止指令、倍率不再漂移、能力集缺失时有明确提示。

🟠 问题 2：实时画面叠加的日期/时间与手机时间不一致，且客户端没有自动校时 ｜ 负责人：张威、许源、唐胜

1. 现象与覆盖范围

• 现象描述：用户反馈「监控实时画面日期不对」，即画面左上角叠加的 OSD 时间与真实时间不符。这是监控类应用里最直接影响取证可信度的缺陷之一——画面上的时间就是事后举证的时间。
• 涉及反馈：1 条直接反馈（261383：Android 8.4.2.4、realme RMX5062、中国河北保定、2026-11-04 11:44:50，携带 Logan 与 fileUrl）。
• 严重度评分：60 / 100（反馈量 10：本窗口 1 条，但属跨版本长期易感类型；共性广度 20：涉及客户端版本 × 设备时区/夏令时 × 校时模式三个维度；业务关键度 30：时间错误直接削弱录像与报警的取证价值，介于「回放/报警」与「UI」之间）。
• 去重判定：近 30 天雷达没有「画面时间/OSD 时间」专题；第 262 期曾以「报警推送时间快约 60 分钟」建过 T-20261024-170425-9d21，但那是推送侧 alarmTime，与本节「实时画面 OSD」不是同一链路，不合并、不重复计分。本期新建 T-20261104-170824-8265。

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

• 客户端确实预留了「设备时间异常」的观测口径，但它在结构上不可能为真：
• PreviewSessionSummaryEvent.checkTimeAbnormal()（lib_base/src/main/java/com/seetong/lib_base/utils/sensors/PreviewSessionSummaryEvent.kt:540-550）的判定逻辑是：

if (bean.enterPreviewTimestampMs <= 0L || currentTimeMs >= bean.enterPreviewTimestampMs) return

currentTimeMs 来自 :234 的 System.currentTimeMillis()，而 enterPreviewTimestampMs 是同一台手机在进入预览时记录的毫秒时间戳——正常时序下 currentTimeMs 永远大于等于它，所以第一行就直接 return，timeAbnormalFlag 恒为 false。

• 更要紧的是：这里传入的是手机系统时间，全程没有任何设备 OSD 时间输入。也就是说，即便逻辑写对，它检测的是「手机时间倒流」，根本不检测设备画面时间。
• 当日既有日志佐证该字段恒定为假：反馈 261415 的 PreviewSession save 快照里 "timeAbnormalFlag":false,"timeAbnormalGapMs":0，且温度检查同样发生在 onAction（即用户点击）时——不点击就没有任何采样。
• 因此神策侧没有可用的「画面时间异常率」，本节明确标注该指标当前不可信，不能用 time_abnormal_flag 证明「时间异常很少」。
• 可用的旁证：本窗口 Login 事件里 Token登录 的 SA105003（自动登录超时）在三端占比稳定在 44%～47%（Android 94,208/241,372、HarmonyOS 19,185/47,658），为长期常量，与本节无关，列出仅为说明「登录链路数据完好、可作为时间基线参照」。

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

• 反馈 261383 的 Logan 已下载（7,619 行、110,394 字节，Error stats: {'-102': 5, '-101': 2, 'EXCEPTION': 75}），覆盖 08:49:47 起的一次完整冷启动 + 进入预览。
• 关键引文：
• 08:49:48.077 SIOT: Send handshake message: {"accessId":"…","userId":"53185388_realme_8.4.2.4","token":"…","keyVersion":2,"timestamp":1793753388062}

→ 1793753388062 换算为 2026-11-04 00:49:48 UTC = 08:49:48 北京时间，与日志行时间完全一致，说明手机时钟本身正确，问题不在手机端时区。

• 08:49:48.077 setDeviceListToSDK->content cache:[{… "devId":10933358, … "devIsOnline":1, … "devNetType":0, "devSn":"07F55F3485182753", … "lastHeartTime":1793710649000, "p2pLastHeartTime":1793719488000, …}]

→ lastHeartTime = 2026-11-03 12:57:29 UTC（20:57:29 北京时间），p2pLastHeartTime = 2026-11-03 15:24:48 UTC（23:24:48 北京时间）。设备在当时已经近 9 小时未刷新主心跳，设备侧的时间基准与在线状态都需要独立核对。

• 08:49:48.075 lowPowerDevice-awakenRightNow-->4,engineer:false,ws:false、08:49:48.129 ConnectPoolManager AddSession 10933358, poolSize=1

→ 该设备属于低功耗唤醒型，唤醒后首个会话由 App 主动建立；唤醒链路正常，排除「设备完全失联导致时间不刷新」。

• Logan 中没有任何 OSD 时间、设备时间设置（SET_SYSTEM_TIME / 1005）、时区配置（CMD_SET_SYSTEM_TIME_CONFIG）相关记录——说明该用户此前的操作路径里，App 从未向该设备下发过校时或时区配置。

4. 代码定位（详细）

涉及仓：~/Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0。

• 时间语义来源：OSD 时间由设备侧叠加，客户端只负责透传画面。因此「画面日期不对」只有三条可能：①设备时钟漂移；②下发了错误的时区/夏令时；③下发了错误的时间。
• 缺陷 1：云同步模式下仍强行覆盖设备时间
• app/src/main/java/com/seetong/app/seetong/ui/TimeZoneUI.java:317-357 saveData()：
• :328-332 按下拉项设置 TimeMode：位置 0 → "MANUAL"，否则 → "SEETONG"（云时间同步）；
• :340 无条件下发 SetDevConfig(m_dev, CMD_SET_SYSTEM_TIME_CONFIG, xml)；
• :347-352 无论 TimeMode 是哪一个，都继续构造 SimpleDateFormat("yyyyMMdd HH:mm:ss")，把 m_time 拼成

<REQUEST_PARAM Time="…" TimeZone="tz" />

并下发 SET_SYSTEM_TIME（1005）。

• 对照 :465-469 refreshTimeTableRow()：「如果为 Seetong 云时间同步方式，不能对时间进行修改」——UI 已经明确告诉用户云同步模式下时间不可改，代码却仍然把本地算出来的时间强制写进设备。这是口径与行为直接矛盾的一处。
• 而 m_time 来自 :244-255 getLocalTime()，其中注释自述「其实这里不用减，直接设置 SimpleDateFormat 的时区为选择的时区…就好了」，实现上还保留了一段 (c - p + z) 的补偿运算。当设备时区与手机时区不一致（如设备在中国、手机在海外，或夏令时切换）时，这段补偿会把偏差直接写进设备。

• 缺陷 2：不存在自动校时路径
• 全仓检索 SET_SYSTEM_TIME 只有两处调用：TimeZoneUI.java:351（用户手动保存时区页）与 WifiEtcUI_STEP4.java（配网最后一步）。冷启动、首次连上设备、每天定时都，没有任何自动校时。
• 结论：设备一旦漂移（断电久置、无 NTP、更换电池），App 端不会自愈，只能靠用户自己找到「设备设置 → 时区」再保存一次——而这正是 261383 这种用户不会做的事。

• 缺陷 3：埋点检测器结构错误（已在第 2 节说明）
• PreviewSessionSummaryEvent.kt:540-550 比较方向写反且无设备时间输入；:229-236 只在 onAction 采样。
• 叠加后果：线上「画面时间异常」既没有修复路径，也没有观测口径，两头都空。

• 修复方向锚点：

1. TimeZoneUI.java:340-352：TimeMode == "SEETONG" 时禁止下发 1005，只下发时区/夏令时配置；MANUAL 时才允许写时间，且写入值必须以「设备当前时区」解释，不再叠加 (c - p + z) 补偿。
2. 新增自动校时：设备上线/唤醒后读取设备时间（GET_TIME_PARAMETER，1048），与手机时间比对，差值超过阈值（建议 60 秒）时按当前 TimeMode 提示或自动校正；注意 SiotDevConnectResult 每设备只埋一次，不能拿它当触发源。
3. PreviewSessionSummaryEvent.checkTimeAbnormal：改为「设备 OSD 时间 − 手机时间」，且采样点从 onAction 扩展到首帧到达与退出预览。

5. 根因结论

• 置信度：🟡 中
• 一句话根因：客户端在云时间同步模式下仍无条件下发 1005 强行覆盖设备时间，且全链路没有自动校时与设备时间读取，设备时钟一旦漂移就无法自愈；同时埋点检测器既不读设备时间、比较方向也写反，使该问题长期不可观测。
• 关键证据链：261383 明确反馈「画面日期不对」+ Logan 证明手机时钟正确（握手 timestamp 与日志时间一致）且该会话内无任何校时下发 + 代码证明云同步模式下仍会写时间、平时完全不写 → 偏差只能来自设备自身漂移或被历史错误写入，且不会被修正。
• 明确不下的结论：不把本次偏差归因为「服务端时间下发错误」——Logan 里没有 1005 的响应包，也拿不到设备侧时间；不与第 262 期「报警推送时间快 60 分钟」合并，两者链路不同。

6. 建议下一步

• 分配给：Android 设备设置负责人（TimeZoneUI.java）+ SDK 侧（张威）配合设备时间读取能力。
• 优先处理项：

1. 先堵住「云同步模式下强写时间」这条；这是唯一能主动制造错误时间的路径。
2. 补自动校时与漂移告警。

• 验证方法：8.4.1.6 / 8.4.2.4 × 中国 / 海外 × MANUAL / SEETONG 共 8 组，每组 10 台；人为把设备时间拨快/拨慢 1 小时、3 天、跨时区，验证：云同步模式不再覆盖、手动模式写入值等于设备时区当前时间、漂移超阈值有提示。

本期扫描全量

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

反馈接口返回 total=150 / fetched=150 / complete=true / pages=3。上表按主问题唯一归类，合计 148 条排除 + 2 条进雷达 = 150 条。261303 与 261302 为同一用户（vivo V2354A）5 分钟内连续提交，按 1 名用户观察。

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

数据来自 skill-appstore-feedback 预采集；本窗口无评论。

差评原文摘录：本窗口无采集到任何评论，因此无差评原文可摘录。

采集状态：华为应用市场 0 条｜应用宝 0 条｜App Store 失败（Apple 限流，未配 ASC Key）｜Google Play 失败（未配置代理）｜待导入：荣耀应用市场/vivo 应用商店/OPPO 软件商店/小米应用商店

口径说明：华为与应用宝的「0 条」是采集成功且确实无评论；App Store、Google Play 是采集失败，四个手商店是待导入——后两者都是数据盲区，不能读作「没有反馈」。

数据源状态

待补证

• 问题 1（云台变倍）：需要一条鸿蒙 6/7 + 8.4.2.4 的操作日志。261394 的 clientId 为 57a3c930-9669-b57d-821c-ad5d49d5e42b，建议回访该用户并引导「进入预览 → 按住放大 3 秒 → 松手」后重新提交日志；补采后需能直接看到 iotP2PDevPTZControl 实际下发的 XML，验证是否出现 <cmd>stop</cmd> 或 <cmd></cmd>。
• 问题 1（能力集）：需要鸿蒙 6/7 真机上该用户设备的 capacity_set 原文，确认 iot_ptz_dig_scale 与 iot_ptz_232_support 的实际有无，以判断「按钮隐藏」还是「指令无效」是主因。
• 问题 2（画面时间）：需要设备 10933358 的当前时间与时区配置（服务端 GET_TIME_PARAMETER 或现场核对 OSD）。另外需确认该设备近 30 天内是否被写过 1005，以区分「历史误写」与「自然漂移」。
• 问题 2（观测口径）：time_abnormal_flag 修复前，任何基于该字段的「时间异常率」结论都不可用，简报与质量日报中若引用需一并标注。
• 应用市场：App Store 需配置 ASC Key；Google Play 需配置代理；荣耀/vivo/OPPO/小米四个商店需人工导出。四者同缺时应用市场侧整体是盲区。

下一期 = 第267期 = 2026-11-05-H17.md（明天下午 17:00）