[Ashena1017]

现象

Android 12 / SDK 31 的华为设备（HarmonyOS 4.2，系统 WebView com.huawei.webview 14.0.2.316）上，首次安装与「更新运行时」固定停在维护页并报 TRIAL_TIMEOUT:RENDERING；同一份 APK 在 Android 16 设备上正常。关联 issue #167（HONOR Android 12，Standard 与 Low 均复现）。

现场证据（未 root，adh shell uid=2000）

• 设备侧 logcat 由华为 WebView 进程持续输出：

  hwschromium-11270: [INFO:network_service_network_delegate.cc(242)]
    final url ***, error_code -173(net::ERR_WS_UPGRADE), duration_time(ms) 10
  

  约每 9 秒一次，与「重新连接中」的重连节奏一致，说明页面的 /api/remote.mux WebSocket 升级请求被服务端以非 101 响应拒绝，ready && opened && message 里的 opened/message 永远不成立。

• 用 PC 经 adb forward 直接对该 dsh 实例发起升级请求，可复现服务端的两种拒绝：无凭据 → 401 unauthorized；Origin 与 Host 不一致或为 null → 403 forbidden。导航与静态资源正常，所以页面本身能渲染。

• 因此失败点在网页侧握手，而当前试运行只在成功时才上报，TRIAL_TIMEOUT:RENDERING 的失败记录里没有任何 ready/transport/socket 状态，无法判断是脚本没跑、页面没启动完成，还是 mux 升级被拒。

改动

只增加诊断，不改变成功判定：

• runtime-trial-page.js：记录 [data-dsh-boot] 遮罩是否仍在、mux socket 的 connecting/open/closed/error 状态与关闭码；页面运行 4 秒后按 2 秒节流上报进度（kind: "progress"）。成功确认（kind: "ack"）与致命失败（kind: "fail"）的上报路径、重试节奏与 clearInterval 时机保持不变。
• runtime-trial-plugin.js：收到上报后按状态变化写出一行 DSHA_TRIAL_PAGE_STATE {...} 到进程输出。宿主 RuntimeTrial.Output 已把 stdout 尾巴写进失败记录的 output，因此下一次失败会直接带上握手卡在哪一步。同时把 renderer 改为只置真，避免后到的进度上报把它从 true 覆盖回 false。
• tools/test-runtime-trial.mjs：合成夹具补三项用例（进度上报字段、socket 关闭码、2 秒节流），原有五项不变式保持通过。

改动只涉及字段白名单（布尔/短枚举/整数关闭码），不写入 cookie、token、URL 或页面内容。

验证

在 Windows / Node v24.19.0 上：

• node --check 通过（两个资产文件）。
• 从 tools/test-runtime-trial.mjs 抽出浏览器握手段落，用仓库里的真实 runtime-trial-page.js 跑合成夹具：原有 5 项 + 新增 3 项全部 PASS（含 foreign_socket_cannot_acknowledge_trial、wrong_trial_home_cannot_acknowledge 等不变式）。
• 对 reportPage() 做独立行为检查：首次上报、状态去重、字段裁剪、null/非对象忽略、renderer 只置真。
• python tools/check-source-hygiene.py PASS；python tools/run-host-tests.py --check-manifest PASS（157 项）。

未验证：没有离线 rootfs 资产与发布证书，未在本机构建或安装 APK，也没有跑 :app:testStandardDebugUnitTest / Release Lint。真机 APK 行为需要仓库维护方在打包后复核。

期望产出

打包后在同类设备上重跑一次维护，失败记录的 output 里应出现 DSHA_TRIAL_PAGE_STATE 行。据此可区分三种根因并决定真正的修复：

1. 完全没有该行 → 注入脚本没执行（CSP/注入位置或 WebView 脚本错误）；
2. ready:false 或 boot:true → 页面没启动完成；
3. ready:true, transport:false + socket.state → mux 升级被拒（本次最可能），再看是 401（cookie 没随升级请求发送）还是 403（Origin 校验）以决定改成 query 凭据与 Origin 放行的哪一侧。

[Ashena1017]

补一条真机验证结果，说明这套诊断在同类设备上能看到什么，也给后续修复一个方向。

验证环境

HUAWEI NOH-AN00（Mate 40 Pro）/ HarmonyOS 4.2.0 / Android 12（SDK 31）/ 系统 WebView com.huawei.webview 14.0.2.316；App 为 build 170 的 Standard 与 Low 两个包，覆盖安装，未 root。

结果

组合	隔离试运行	logcat
Standard（系统 WebView）	TRIAL_TIMEOUT:RENDERING	hwschromium-11270 … error_code -173(net::ERR_WS_UPGRADE)，约每 9 秒一次
Low 包 + 「自动选择内核」	TRIAL_TIMEOUT:RENDERING	同上（仍是系统 WebView，没有走 Gecko）
Low 包 + 网页内核设为 Gecko	18.9 秒通过，环境 READY、端口 3080，网页正常连接	无 ERR_WS_UPGRADE

试运行期间抓运行中窗口的无障碍树，能看到完整 DSH 前端（新建会话/全局面板/插件/设置等），说明页面已加载并渲染，缺的只有 mux 的 opened / message。另外用 PC 经 adb forward 直接向该 dsh 实例发升级请求：无凭据返回 401，Origin 与 Host 不一致或为 null 返回 403 —— Chromium 对非 101 的升级响应统一报 ERR_WS_UPGRADE，所以本 PR 记录的 socket.state / 关闭码能把这两种情况区分开。

对上游的建议

1. 合并本 PR 后，失败记录的 output 里会出现 DSHA_TRIAL_PAGE_STATE，可区分"脚本没执行 / 页面没启动完 / mux 升级被拒"三类原因。
2. 若确认是 mux 升级被拒，考虑在 WebView 路径失败后自动回退随包 Gecko 并明确提示，而不是要求用户自己把「网页内核」改成 Gecko；这一项对 Huawei/HONOR 设备是决定性的。
3. Low 包默认仍是「自动选择内核」（PreviewFallback.preferred() 只在偏好为真或取不到 WebView provider 时选 Gecko），文档里"Low 同样失败"的说法容易误导排障者。

说明：本 PR 未在本地构建 APK（缺少离线 rootfs 与发布证书），Java 侧行为需要维护方打包后复核；上面的真机结论针对的是当前已发布 build 170，用来证明诊断字段的必要性。