From 44b58db58a674103cee4394edb399b42d0930f36 Mon Sep 17 00:00:00 2001 From: AskaEth Date: Mon, 5 Oct 2026 13:13:05 +0800 Subject: [PATCH] =?UTF-8?q?docs(05):=20=E9=94=9A=E7=82=B9=E8=A1=A5?= =?UTF-8?q?=E8=AE=B0=E5=85=AB=E2=80=94=E2=80=94=E5=88=86=E4=BA=AB=E8=B7=AF?= =?UTF-8?q?=E5=BE=84=E8=AE=BE=E5=A4=87=E9=AA=8C=E8=AF=81=E6=88=90=E7=BB=A9?= =?UTF-8?q?=E5=8D=95=EF=BC=88=E6=96=87=E6=9C=AC=E7=83=AD/=E5=86=B7?= =?UTF-8?q?=E5=90=AF=E5=8A=A8=E3=80=81=E8=B6=85=E9=95=BF=E8=B5=B0=E6=96=87?= =?UTF-8?q?=E4=BB=B6=E4=B8=89=E6=9D=A1=E9=80=9A=E8=BF=87=EF=BC=9B=E5=9B=BE?= =?UTF-8?q?=E7=89=87=E5=8F=97=E9=98=BB=E4=BA=8E=E5=B7=A5=E5=85=B7=EF=BC=89?= =?UTF-8?q?+=20W37=20=E8=AF=B4=E6=98=8E=20+=20=E4=B8=89=E6=9D=A1=E6=96=B0?= =?UTF-8?q?=E7=8E=AF=E5=A2=83=E5=9D=91=EF=BC=88=E9=BB=91=E5=B1=8F/adb=20ro?= =?UTF-8?q?ot=20=E5=86=B2=E6=8E=89=20reverse/system=5Fserver=20=E5=B4=A9?= =?UTF-8?q?=EF=BC=89+=20=E5=B9=B6=E8=A1=8C=E8=AF=AF=E6=A0=87=E9=97=AE?= =?UTF-8?q?=E9=A2=98=E7=9A=84=E5=8F=96=E8=AF=81=E7=BB=93=E8=AE=BA?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 把「adb 造不出带授权的 URI intent，别再花时间」与「黑屏会让 input tap 全部落空、先确认屏幕是亮的」写成纪律。 --- devdocs/05-开发进度与交接.md | 43 ++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/devdocs/05-开发进度与交接.md b/devdocs/05-开发进度与交接.md index ff0c8e1..db8e3fc 100644 --- a/devdocs/05-开发进度与交接.md +++ b/devdocs/05-开发进度与交接.md @@ -745,3 +745,46 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \ > - 假后端**用完即关**（本次已关，18099 已释放）；别长期占 18080/18081/18083/18099。 > - worktree 纪律照旧（合并当场 `rm -rf` + `prune`）；本批 W35/W36 都已执行，`git worktree list` 只剩主树。 > - **动 `02` 之前先 `git status`**：本批 `02` 一直带着后端会话的在途追加，处理手法 = 先存他们的补丁 → `git checkout --` 还原 → 只提交我的 → 再把他们的贴回末尾。两边都没丢。 + +> ## ★★ 锚点补记八（2026-10-05 傍晚 · 分享路径设备验证的成绩单 + W37 + 三条新环境坑） +> +> ### 状态 +> - `android` = `origin/android` = **`a2350a6`**（含 W37 的合并提交），**1084 测试 / 0 失败 / 0 错误 / 0 跳过**（主树实测）。 +> - W37 `6cdf111`（分享：认下字符串形态的 `EXTRA_STREAM` + 消灭静默失败）已合并、已推送、**worktree 已清**。 +> - `02` 里已回后端**回执十九**（`0764bc2`）：给出那次分享失败的**精确时间锚点**与「无 `error` 帧 ⇒ 帧根本没发出」的证据链。 +> +> ### ✅ 分享路径：三条通过 +> | 场景 | 结果 | 证据 | +> |---|---|---| +> | 纯文本・**热启动**（连接正常） | ✅ | 库内 `clientMsgId=share-5f65cb44…` + 正文 `share one`；气泡挂 **`[用户分享]`** 角标 | +> | 纯文本・**冷启动** | ✅ | App 被 ANR 杀掉后由分享冷启动，`share two` 照样落库（`share-ea81310c…`） | +> | **超长正文（4200 rune）→ 文件** | ✅ | 后端 `POST /api/v1/documents 201`；库内 `content_len=0`、`documents=[{…txt, size:4200, chars:4200, status:"extracted"}]`；她回「人家打开你发来的那个文件了」 | +> +> ### ⛔ 分享路径：**图片（单图/多图）没拿到设备证据** —— 原因是工具，不是产品判定 +> **`adb shell am` 造不出「带授权的 URI 分享」**，两条都试过： +> - `--esa`（`String[]`）：类型不对 ⇒ `Cannot cast [Ljava.lang.String; to android.net.Uri`（**W37 已让它不再静默**）； +> - `--eu`（单 `Uri`）+ `-f 0x00000001`：**没有 ClipData ⇒ 授权传不到目标应用** ⇒ App 打不开那个 `content://` ⇒ 静默无反应（同一处缺陷）； +> - **`am` 帮助里确认没有 ClipData 选项**（只有 `--eu/--esa/--grant-*`），所以这条路在 adb 上封死。 +> **真路径**是：相册（或任何真实发送方）→ 分享面板 → Cyrene。我试过，但今天 UI 驱动不可靠（见下面三条坑 + 模拟器 `system_server` 崩过一次）。 +> ⇒ **要么主人在真机上装最新 debug APK 试一次「相册多选 → 分享」，要么等下次环境稳定再做**。**不要再花时间用 adb 造 URI intent。** +> +> ### 🔧 W37 修了什么（都是今天实机暴露的） +> 1. **字符串形态的 `EXTRA_STREAM` 现在认了**（`String[]` / `ArrayList`，历史遗留与跨壳应用常见），**只接受 `content://`**（`file://`/`http(s)://` 一律拒，理由写在 `stringStreamUri` 的 KDoc）；非法项逐条跳过，不整体失败。 +> 2. **消灭静默失败**：`EXTRA_STREAM`/`ClipData` 里**确实有内容迹象**却一条都读不进来 ⇒ 给一条**柔和告知**「这次分享的内容没能读进来，没有发送任何内容…」（刻意不写「发送失败」）。 +> **边界**：`EXTRA_TEXT` 与 `EXTRA_STREAM` 都为空 ⇒ **仍然静默**（两条判据同源）。 +> +> ### ⚠️ 今天新踩的三条环境坑（比代码更耽误时间） +> 1. **模拟器会自己黑屏**，而 `svc power stayon true` **不一定挡得住**。后果极坏：黑屏下的 `input tap` 全部落空 ⇒ 我会误判成「点了没反应 / 长按不生效 / 焦点乱跑」。**开测前先 `input keyevent 224` + `82` 唤醒并截图确认屏幕是亮的**，另加 `settings put system screen_off_timeout 1800000`。 +> 2. **`adb root` 会重启 adbd，把 `adb reverse` 全部冲掉**。之后 App 就「无法连接到服务器」。**`adb root` 用完必须补回 `adb reverse tcp:10942 tcp:10942`。** +> 3. **模拟器的 `system_server` 会崩**（症状：`Can't find service: window`、`am` 报 `Failure calling service activity: Broken pipe`、负载飙到 11）。**此时除了重启模拟器没有别的办法**；别把这类现象当 App 的问题。 +> +> ### 📌 主人问的「开了并行之后连串行消息都成了并行处理？」—— 结论：**不会**，今天的数据里也没有发生过 +> 三条证据： +> 1. **服务端有硬门**：`session_orchestrator.go:300` 的 `if st.mode != ModeIdle` —— **会话空闲时根本不进并行分支**，无论客户端声明什么都不可能开第二路（空闲只有一条串行路）。 +> 2. **客户端只在忙时声明**：`parallelForSend(mode, busy) = busy && mode.wireParallel`（`InterruptScope.kt:65`），空闲时三档**逐字节相同**。 +> 3. **今天全部日志（含轮转备份）里 `parallel leg started` 只有 1 条**：`turn-4743035881e410af leg=2 active_turns=2`（`11:56:39`）—— 正是我做并行实测时**故意**制造的。 +> ⇒ **最可能的真相**：主人手机上装的是 **W36 之前**的 APK，于是**任何会话的第 2 条及以后的消息**都会被误挂「并行路 N」（`leg` 是「本会话第几条路」，不是并行与否）——**已修为 `39a63f8`，请装最新 debug APK 再看**。 +> ⇒ 若看到的其实是**底栏那句**「正在思考… 并行 N 路」：那句来自 `ChatUiState.activeTurns > 1`（`ChatScreen.kt:863`），是**另一个信号**；服务端 `session_idle` 用 `busyPayload(…, ModeIdle, 0)` 发 0（`session_orchestrator.go:455`）⇒ 正常情况下会清掉。**若仍能看到，请告诉我，我按 activeTurns 陈旧这条线单独查。** +> +> ### 最新 debug APK +> `app/build/outputs/apk/debug/app-debug.apk`（由 `a2350a6` 构建；**含 W35 分享角标 / W36 角标闸 / W37 字符串形态与告知**）。