Seetong · Report

🎯 Seetong 问题雷达 第267期

时间窗口：2026-11-04 17:00:00～2026-11-05 17:00:00

📌TL;DR 核心要点

  • 🔴 鸿蒙预览/回放后转后台，系统音效被锁成静享，须杀进程才恢复（严重度 62，置信度 中）
  • 🟠 iOS 一键重置密码 74 秒后提交必报 token 过期，流程无重取无法自愈（严重度 62，置信度 强）
  • 现象描述：用户在鸿蒙 7（华为 Mate 80）上播放实时监控或回放后把 App 切到后台，系统的音效设置（如「静享模式」切换）失效；把 Seetong 从后台杀掉后立即恢复；只要 Seetong 留在后台，就一直无法切换系统音效。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-11-05）。

#问题（严重度降序）严重度平台版本负责人问题原因
1HarmonyOS `1.1.2.3` 多用户离线与核心视频链路失效
18 期 · 139 条反馈
100Android · HarmonyOS1.1.1.11 / 1.1.2.3 / 8.4.1.6冉博麟、唐胜、陈宝旺、李国涛HarmonyOS 客户端把 P2P 瞬时离线写成本地持久状态，并在后续在线判断中优先使用这个旧值，可能导致设备已恢复在线却仍显示离线；回放离线态和播放错误透传不足则放大了用户的“看不到画面”体验。
2云回放大面积失败——看不了、卡顿、黑屏
12 期 · 22 条反馈
90Android · HarmonyOS · iOS8.4.1.6 / 8.4.1 / 8.4.2唐胜、陈宝旺、谭伟、许源云回放链路在 8.4.1.6 / 1.1.2.3 版本上出现系统性失败，三端失败率均超 34%，且与入口场景无关，指向服务端回放接口或 KMP 共享回放层的共性问题
3多端回放功能异常——无录像、无法播放、回放入口消失
4 期 · 9 条反馈
90Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11 / 1.1.2.3唐胜、张威、陈宝旺回放功能异常呈多端多发态势，症状涵盖录像缺失、入口消失、播放失败三类，指向服务端录像存储/检索链路或近期版本变更引入的回归
4Android `8.4.1.6` HEVC 预览以零宽高启动解码器
1 期 · 3 条反馈
90Android8.4.1.6张威、唐胜、谭伟Android 8.4.1.6 在首次 TPS_AddWachtRsp 尚未提供有效 HEVC 宽高时，仍立即调用 OpenStreamAgent 创建 MediaCodec，系统以 BAD_VALUE 拒绝零宽高配置，而客户端没有等待后续媒体参数或建立明确失败终态。
5Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6唐胜、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
6HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
7Android 实时预览无首帧却被标记为“视频播放中”，并无限重试
7 期 · 22 条反馈
80Android · iOS8.4.1.6 / 1.1.2.3 / 8.1.1.11唐胜、陈宝旺、欧阳荣、谭伟预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。
8iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算
2 期 · 8 条反馈
80Android · iOS8.4.1.6 / 8.3.11.3 / 8.4.106陈宝旺、欧阳荣、谭伟iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
9iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
10Android `8.4.1.6` 在线状态不一致导致卡录像无法打开
1 期 · 1 条反馈
80Android8.4.1.6张威客户端继续使用一份已陈旧约 8 小时的在线缓存，同时又允许单次 P2P 离线事件直接覆盖设备状态；状态模型没有区分云端心跳、P2P 连通和播放出帧，导致用户看到“在线但录像打不开”，且回放页缺少可恢复路径。

🔴 问题 1：HarmonyOS 预览/回放后转后台，系统音效切换失效并被锁成「静享模式」 ｜ 负责人：冉博麟、李国涛、feiwangey、18671356032

1. 现象与覆盖范围

  • 现象描述：用户在鸿蒙 7（华为 Mate 80）上播放实时监控或回放后把 App 切到后台，系统的音效设置（如「静享模式」切换）失效；把 Seetong 从后台杀掉后立即恢复；只要 Seetong 留在后台，就一直无法切换系统音效。
  • 涉及反馈：1 条（261587），HarmonyOS 8.4.2.4、HUAWEI VYG-AL00（Mate 80 系）、简体中文、已登录用户 15800008454、2026-11-05 13:32:10、广东深圳罗湖，无 Logan、无 fileUrl。
  • 附加线索：心愿单 5694 为同一用户在同一时段提交的同一问题，附系统设置截图，描述更完整（「导致手机音质变为静享模式」）。两条按同一问题计，不重复计数。
  • 严重度评分：62 / 100（反馈量 10：24 小时内 1 条 + 心愿单 1 条同类；共性广度 22：覆盖 1 个机型、1 个版本、1 个地区，但问题跨越「后台态」这一全局场景；业务关键度 30：不误伤视频预览与回放本身，但污染系统全局音频与用户其它 App 体验，属跨应用副作用）。
  • 去重判定：检索近 10 期雷达与任务账本，无同类问题记录（「音效」「静享」为首次出现）。本期新建任务 T-20261105-170712-b346。

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

  • 后台保活规模（决定性分母）：MonitorWatchStep 在 HarmonyOS 上近 17 天稳定在单日 5.5 万～6.0 万次、3.2 万～3.5 万人，无跳变、无缺口（10-20 至 11-05 逐日；11-05 为当日部分数据 37,523 次 / 23,466 人）。说明「鸿蒙端后台挂着监控」是常态化行为，不是个别用户的操作异常——问题一旦成立，暴露面就是全部后台保活用户。
  • 版本分布：MonitorWatchStep 当日（11-04～11-05）HarmonyOS 侧以 8.4.1.6 51,643 次 / 27,698 人、8.4.2.4 37,416 次 / 20,194 人为主。8.4.2.4 已是鸿蒙端第二大活跃版本，本反馈正落在这个版本上。
  • 预览/回放进入频次：PlayingPopup 同日 HarmonyOS 8.4.1.6 125,806 次 / 15,451 人、8.4.2.4 79,346 次 / 12,239 人；近 17 天鸿蒙端持平在 12.9 万～13.6 万次/日，无异常抬升。
  • 神策侧无法直接量化本问题：系统「音效切换失效」发生在 App 之外，客户端没有任何事件能观测到（既无音频焦点丢失事件，也无系统音效设置变更回读）。本节数据只能证明「后台保活规模足够大、暴露面真实存在」，不能用来估算发生率。报告不据此给出任何百分比。

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

  • 反馈 261587 未提供 Logan，fileUrl 也为空，无法从运行时日志确认音频资源生命周期。
  • 尝试替代样本：下载 261629（2fdce4bb…）时返回 HTTP 500 / 10050099 从OBS下载文件失败，该条并非同一用户，取到也不能归因，遂放弃。按 SKILL 规则标「Logan 未提供」，不阻塞报告。

6. 代码定位（详细）

  • 涉及模块：~/seetong-app-harmony（HarmonyOS 端），音频资源集中在 basic 与 feater/playDevice 两个模块。
  • 关键类 / 文件：
  • PlayAudioRenderer（basic/src/main/ets/utils/playPcmUtils.ets:13-199）：鸿蒙端唯一的 audio.createAudioRenderer 封装，audioRendererInfo.usage 固定为 STREAM_USAGE_VOICE_ASSISTANT（:33）。
  • customSound.ets（feater/playDevice/src/main/ets/setting/customSound.ets）：PlayAudioRenderer 的唯一使用方——报警提示音录制/试听/文字转语音试听。
  • ReplayPage.ets / SdCardRePlayPage.ets / LPDeviceRePlayPage.ets / PlaybackNVR.ets：回放页音频开关，全部走 setReplayVideoAudioEnable → TSNapi.ts_P2PSetNVRReplayAudioEnable（DeviceServiceImpl.ets:934-943），即 SDK 私有通道，不经鸿蒙系统播放器。
  • ViewPage.ets:73 @State monitor: boolean = true、:583-587 setMonitor()、:747-749 checkMonitor()：预览页「监听」开关，走 setVoiceDetect → TsNativeUtils.setVoiceDetect（DeviceServiceImpl.ets:621-628），同样是 SDK 通道。
  • 调用链（本反馈最可能的路径）：ViewPage（预览）或 ReplayPage（回放）启动音频 → 用户切后台 → ViewPage.ets:591-596 的 appRunStatueEventCallback 在 RUN_STATE_BACKGROUND 只处理了「正在通话则关闭通话」，未关闭监听 → 若 monitor 为 true（checkMonitor 默认值 true，ViewPage.ets:747），setVoiceDetect(devId, true) 保持开启 → 音频会话在后台持续持有。
  • 关键分支与证据缺口（必须说清「不确定」的部分）：
  • SDK 走的是私有协议还是 AudioRenderer，TSNapi 是 native 层封装，ArkTS 侧看不到它用的是 AudioRenderer 还是 OHAudio，也没看到任何 audioInterrupt / InterruptEvent 监听、AVSession 注册或 backgroundTaskManager.startAudioPlayback。全仓检索 avSession 只有 PlaybackNVR.ets:52 一行 import、无任何调用，属死代码。
  • 若播放确实落到 PlayAudioRenderer，其 usage: STREAM_USAGE_VOICE_ASSISTANT 在鸿蒙上会参与系统音频场景切换与音效（音频效果模式）管理；aboutToDisappear（customSound.ets:119-123）与切 Tab（:525-529）都只调 destroy()，而 destroy()（playPcmUtils.ets:147-176）在状态为 STATE_RELEASED / STATE_NEW 时直接 return 且不置空静态引用，audioPlayer 这一 static 字段会一直指向已释放实例，后续 start()（:132-145）的状态守卫又允许在 STATE_STOPPED 上重启——存在「重复 init → 旧实例未释放 → 会话残留」的结构性风险。
  • 结论性质：代码侧存在明确的资源回收缺陷与后台音频不释放路径，但「是不是这两处导致系统音效锁死」尚未被运行时日志证实，故置信度只到「中」。

7. 根因结论

  • 置信度：🟡 中
  • 一句话根因：鸿蒙端把音频播放职责全部交给了 SDK 私有通道与一个 STREAM_USAGE_VOICE_ASSISTANT 的全局单例 PlayAudioRenderer，切后台时既不关闭预览监听、也不释放音频会话、更不监听系统音频中断，导致 App 在后台长期占用音频会话，进而劫持系统的音效（静享/音效切换）设置。
  • 关键证据链：用户原话「结束后台后音效切换功能恢复」（= 因果锁定在进程存活期）+ 神策证明后台保活是常态（暴露面成立）+ 代码证明 appRunStatueEventCallback 后台分支未关监听、destroy() 不置空静态引用、全仓无 audioInterrupt / AVSession 注册（机制成立）。三者指向同一方向，但缺运行时日志这一环。

8. 建议下一步

  • 分配给：鸿蒙端负责人（ViewPage.ets 预览监听生命周期、playPcmUtils.ets 音频会话回收），协同 SDK 侧确认 setVoiceDetect 的底层播放实现。
  • 优先处理项：
  1. ViewPage.appRunStatueEventCallback 的 RUN_STATE_BACKGROUND 分支补 setVoiceDetect(currentDevId, false)，并在回前台时按用户设置恢复；回放页同样处理。
  2. PlayAudioRenderer.destroy() 在 release 成功后把 PlayAudioRenderer.audioPlayer 置 null（当前是静态字段，永不置空），并给 init() 增加「已存在实例先销毁」的前置判空。
  3. 确认 SDK 侧 setVoiceDetect / SetNVRReplayAudioEnable 是否使用 AudioRenderer；若是，补 audioInterrupt 注册与 AVSession 正确释放（当前 PlaybackNVR.ets:52 的 import 是死代码，要么补齐要么删除）。
  • 验证方法：Mate 80（鸿蒙 7）真机，覆盖「预览停留 1 分钟 → 后台 30 分钟 → 切系统静享/音效」与「回放 → 后台」两条路径，各 10 轮；验收标准为切后台 5 秒内系统音效切换恢复可用、App 回到前台后预览声音可正常恢复；同时回访 15800008454 确认修复。

🟠 问题 2：iOS 一键重置密码停在填写页约 1 分钟后提交必报 30000126（token 已过期），且无自动重取 ｜ 负责人：欧阳荣、谭伟、位冬

1. 现象与覆盖范围

  • 现象描述：用户走「一键重置密码」流程，系统已校验手机号并下发 checkCode，在设置新密码页面停留约 74 秒后点击「重置密码」，服务端直接返回「授权 token 已过期」；页面只弹出「重置密码失败(30000126)」，用户不知如何继续；重试一次仍失败。
  • 涉及反馈：1 条（261627），iOS 8.4.1.6、iPhone（phoneType 记为 26.0，即 iOS 26.0）、简体中文、江苏南通海门、2026-11-05 16:07:18，有 OBS 日志包 + 完整 Logan。
  • 严重度评分：62 / 100（反馈量 10：24 小时内 1 条，但属流程性硬阻塞；共性广度 20：1 端、1 版本、1 地区；业务关键度 32：重置密码是账号找回的唯一自助路径，走到最后一步失败且无引导，用户只能放弃或转客服）。
  • 去重判定：30000126 在 2026-11-01-H17、2026-10-22-H17、2026-10-15 两期均有出现，均按「单点、转客服」处理，从未做过日志级根因定位；任务账本中已有 T-20261015-090316-0dda（同一账号找回链路），但当时无 Logan，本期首次拿到直接证据。不重复建单，已更新原任务的下一步与证据锚点。

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

  • 本期神策未取该链路的事件分布：password-reset 三端并未单独埋点成功/失败事件，可用事件不支持按 checkCode 生命周期拆解。不做硬凑，本节如实标注「神策无对应事件口径」。
  • 可间接参照：同期 SiotDevConnectResult、DeviceConnectResult 等平台事件量与 7 日均值持平，说明不是 iOS 端整体服务异常或发布抖动，问题局限在账号找回链路。

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

  • 反馈 ID：261627（clientId 8C4D4EA5-C993-40B7-AAF7-18FBA3499B95），日志共 1,146 行。
  • checkCode 取得（14:57:34.482 请求 → 14:57:34.848 响应 200）：
path=/seetong-client/password-reset/local-number/check  ret=200
{"code":200,"success":true,"msg":"操作成功","data":{"checkCode":"0fea343976bf41c7d524239a0f7d0467"}}
  • 提交重置（16:07:01.727 请求 → 16:07:01.936 响应）：
POST /seetong-client/password-reset/local-number
{"checkCode":"0fea343976bf41c7d524239a0f7d0467","password":"81877245393C68BF88DA6D2F54186BD5"}
{"code":30000126,"success":false,"msg":"授权token已过期","rid":"e346557206254fa89e8f498d2a1620ed"}
ret=30000126
  • 用户重试 8 秒后（16:07:09.715）：请求体逐字节相同（同一个 checkCode、同一密码 hash），服务端仍返回 30000126，rid=37cfdb0185c247798d3aa94c9dc34e6f。
  • 关键推算：checkCode 取得于 14:57:34.848，提交于 16:07:01.936，间隔 69 分 27 秒（约 4,167 秒）。两次失败说明该 checkCode 已被服务端一次性消费或已过有效期，而客户端在拿到 200 后没有任何过期计时，也没有在失败时重新走 /local-number/check。
  • 日志侧另有一处 16:07:01.727 之前的 local-number/check 请求（L963 同一条链路的更早记录），说明用户从进入页面到提交之间停留时间很长——这不是弱网或服务端抖动，而是「页面停留时长 > token TTL」的确定性失败。

6. 代码定位（详细）

  • 涉及模块：~/Seetong-App-iOS，Seetong5.0_ios/Seetong_tps/Classes/Login/。
  • 关键类：
  • STLoginViewController（STLoginViewController.m:261-300）：shanYanOneKeyResetPasswordWithToken: 先 POST kAPIResetPwdNumberCheck（参数 token + thirdParty=chuanglan），成功后从响应 data.checkCode 取出码，赋给 vc.token 并 push 到填写页。取码后无任何 TTL 记录、无定时刷新。
  • STOneKeyResetPwdViewController（STOneKeyResetPwdViewController.m:132-149）：shanYanOneResetPasswordWithToken: 直接用 self.token 作为 checkCode 提交 kAPIResetPwdLocalNumber；onSuccess 里也没有任何「码是否还新鲜」的校验（写的是「重置成功」分支）。
  • 失败分支（STOneKeyResetPwdViewController.m:170-196）：只把 30000126 拼成「重置密码失败(30000126)」弹 QMUITips，没有针对该错误码的重取逻辑；对比 STLoginViewController.m:1364 与 TPS_CommonUtil.m:281 里对同一错误码的语义化处理（「token 失效」），重置页这一处是漏网的。
  • 调用链：手机号一键校验 → /password-reset/local-number/check（得 checkCode）→ push STOneKeyResetPwdViewController → 用户输入新密码 → /password-reset/local-number（用 checkCode）→ 30000126 → 仅 Toast。
  • 关键分支：唯一失败分支就是「checkCode 过期/已消费」，且被归并进通用 else，与网络失败、参数错误共用同一提示。
  • 修复方向锚点：STOneKeyResetPwdViewController.m:132-149（拿到 30000126 时立即重新发起 /local-number/check 并静默重试一次提交）、:170-196（为该码单列分支，提示「验证已过期，正在重新验证」）；STLoginViewController.m:285-290（记下 checkCode 的取得时间，超过阈值在进入填写页时就预刷新）。

7. 根因结论

  • 置信度：🟢 强
  • 一句话根因：一键重置把 checkCode 当作永久有效凭据保存，而服务端对它有有效期/一次性消费约束；页面停留超过 TTL 后提交必然 30000126，且失败分支既不重取也不提示原因，用户陷在死循环里。
  • 关键证据链：Logan 两次请求体完全相同 + 服务端两次同码 30000126 + 取码与提交相隔 69 分钟 → 排除弱网、排除密码错误、排除服务端抖动；代码确认取码后无 TTL、失败后无重取。

8. 建议下一步

  • 分配给：iOS 账号模块负责人（STOneKeyResetPwdViewController.m），服务端确认 checkCode TTL 与一次性消费语义。
  • 优先处理项：
  1. 失败分支对 30000126 做专门处理：自动重新 /local-number/check 拿新码后重放提交（最多 1 次），仍失败再提示「请重新获取手机验证」。
  2. 客户端记录 checkCode 取得时间，超过 TTL 的 80% 时提前静默刷新，或在进入页面时就按服务端返回的 expireIn 起倒计时。
  • 验证方法：iPhone 26.x + iOS 8.4.1.6，分别停留 1 / 30 / 60 / 90 分钟后再提交，各 10 次，要求全部成功或给出可继续的明确引导；同时回归「验证码已消费后再提交」「连续点击重置 3 次」两个场景。

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

本期自有反馈 217 条（total=217 / fetched=217 / complete=true / pages=5），应用市场 0 条。下表按关键词归并，条数为该簇内反馈数。
#关键词反馈数分类处置
2鸿蒙后台占用音频会话致系统音效失效1（+心愿单 1）🔴 进雷达详细分析见问题 1
3重置密码 300001261🔴 进雷达详细分析见问题 2
4设备离线／掉线／连不上／无画面8🟡 单点或配置261608／261557／261551／261487／261485／261483／261478／261420，跨 3 端 8 个不同设备与地区，无版本共性；261485／261483 为同一用户两次提交；已有任务 T-20260923-063223-0103、T-20261027-171012-5d00 覆盖，不重复建单
5硬盘损坏／录像缺失／回放不了5🟡 单点261581（iOS 8.4.2.5，硬盘损坏或丢失）／261529（iOS 8.4.2.5，某时刻后视频丢失，有时间点）／261467（Android 8.4.1.6，硬盘错误+回放不了）／261537（Android 8.4.1.6，录像断续）／261494（HarmonyOS 1.1.2.3，断断续续录像）。两版本分散、无跨端同建房共性，转设备侧核查；已有任务 T-20260926-170258-2226 覆盖回放链路
6云台调不动1🟢 重复261480（HarmonyOS 1.1.2.3，HUAWEI ALN-AL10）与第 266 期问题 1 同一能力位差异路径，已在任务 T-20261104-170817-4c2e 覆盖，本期不重复深挖
7设备时间不正确导致不能回看1🟢 重复261452（Android 8.3.0.7）命中第 266 期问题 2 同一根因，任务 T-20261104-170824-8265 已在办
8画质／夜视／马赛克4🟡 单点261508（双摄夜间抽帧、重影、马赛克）／261583（图像与录像偏黑）／261543（夜间分辨率差+误报警）／261542（监控灯光关不掉）；均单条、无 Logan 交叉证据，指向设备端成像与补光，转设备侧
9权限／分享／解绑咨询3⚙️ 客服工单261636（不允许非分享设备登录）／261626（怎么解除绑定）／261548（找不到安装工程师），转客服
10功能诉求（两镜头独立视角、摄像头隐藏、误删恢复等）3🟤 心愿单261455／261473／261479，已收录
11无信息量／测试内容／乱码6🟢 用户操作261625／261611／261549／261536／261493／261472
12状态正常或信息量不足的短反馈4🟢 用户操作261438（「我家摄像头没视频」，无上下文无 Logan）／261519（WiFi 连接未连上，属配网操作）／261506／261501 等描述笼统，无法构成可复现线索，转客服回访
13综合报障（多问题一句话）2🟡 单点261543（「设置不合理、随意乱报警、晚上分辨率差」与第 8 行重复计，不另计）／261599（格式化后离线且打不开视频，兼含存储与离线），已有任务 T-20261101-170334-79ea、T-20260926-170258-2226 覆盖相关链路
已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
口径说明：第 1 行 177 条为同一网络提示模板（含中文、英文、俄文等本地化文案），按 SKILL 规则整簇排除；它们在 HTML 中会自动折叠。第 2～13 行为 40 条「非网络提示」的具体反馈：其中 2 条进雷达、2 条判为重复跳过、其余按上表处置；同一关键词被两行引用的条目（261543、261599）在合计中只计一次。

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

商店评论数差评数主要问题分类处置
华为应用市场00—采集成功，本窗口无评论
应用宝00—采集成功，本窗口无评论
App Store———采集失败（Apple 限流，未配 ASC Key）
Google Play———采集失败（未配置代理）
荣耀 / vivo / OPPO / 小米———待导入（本窗口无后台导出文件）

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

采集状态：华为应用市场 0 条｜应用宝 0 条｜App Store 失败（RSS 返回空 feed，疑似限流；ASC 未配置）｜Google Play 失败（本机网络不可达，需配置代理）｜待导入：荣耀应用市场/vivo 应用商店/OPPO 软件商店/小米应用商店

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

数据源状态

数据源状态说明
自有反馈接口oktotal=217 / fetched=217 / complete=true / pages=5；窗口 2026-11-04 17:00:00～2026-11-05 17:00:00
心愿单接口部分可用total=5698 / fetched=1000 / complete=false（按 1000 条安全上限截断），仅取本窗口新增；本期新增含问题 1 的同一诉求 5694
应用市场（华为 / 应用宝）ok0 条评论
应用市场（App Store）失败RSS 返回空 feed（疑似限流）；ASC Key 未配置
应用市场（Google Play）失败本机网络不可达，未配置代理
应用市场（荣耀 / vivo / OPPO / 小米）待导入需人工导出
神策部分可用MonitorWatchStep / PlayingPopup / MonitorFrameResult 等事件查询成功；无音频会话、无音效、无密码重置链路事件，两问题均无法用神策量化发生率
Logan部分可用261627（问题 2）完整可解析 1,146 行，证据充分；261587（问题 1）无 Logan、无 fileUrl；补充下载 261629 时返回 HTTP 500 / 10050099 从OBS下载文件失败
友盟未查本期两问题均非崩溃/ANR
TAPD未查功能性根因分析阶段不查历史 Bug，避免干扰判断

待补证

  • 问题 1（音频会话）：需要一条鸿蒙 7 + 8.4.2.4 的操作日志。261587 的 clientId 为 5f67916a-f827-70e7-9403-04fdfc22977d，建议回访 15800008454，引导「预览 1 分钟 → 切后台 → 尝试切换静享模式 → 再回前台」后重新提交日志；补采后需能看到「切后台时 setVoiceDetect 是否被调用为 false」「SDK 侧音频通道是否仍在运行」两项。
  • 问题 1（SDK 实现）：需 SDK 侧确认 ts_P2PSetReplayAudioEnable / setVoiceDetect 在鸿蒙上的音频输出实现（AudioRenderer / OHAudio / 直通），以及是否有 backgroundTaskManager 声明——这决定修复点落在 ArkTS 还是 native。
  • 问题 2（服务端语义）：需服务端给出 checkCode 的有效期（TTL）与是否一次性消费，以确定客户端应「预刷新」还是「失败后重取」。
  • 应用市场：App Store 需配置 ASC Key；Google Play 需配置代理；荣耀/vivo/OPPO/小米四个商店需人工导出。四者同缺时应用市场侧整体是盲区。
  • 心愿单：本期 fetched=1000 未覆盖全量 5698 条，仅能捕捉本窗口新增；如需历史诉求趋势，需按时间分段拉取。

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

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-11-05 17:07 · 数据以同名 Markdown 原始报告为准