Repository navigation
Releases: doublepi123/and-chamber
Releases · doublepi123/and-chamber
Release list
AndChamber v0.0.38
v0.0.38 — 浮窗不再闪、打开即用、授权所有 App
Steady capsule, open-and-use launch, and an "all apps" scope.
改进
- 浮窗不再时隐时现:截图时不再把浮窗整个拆掉重建,只是临时设为不可见,截完立即恢复。读页面这类耗时步骤也挪到隐藏之前和恢复之后进行,每次截图浮窗只消失大约半秒,以前要好几秒。进展文字固定占两行高度,浮窗不会因为文字行数变化而跳动。
- 打开 App 就能用:按“最近用过”的规则自动进入实例:上次用的是远程实例就进远程,否则自动启动并进入本机 OpenChamber 的聊天。以前停留在手机控制页时点桌面图标没有反应,现在也会正常跳转。
- 自动连上手机:以前打开过手机控制的话,进入本机实例的聊天后,App 会等手机工具准备好,然后在后台自动连接手机,不需要打开手机控制页。从远程实例切回本机时同样会自动连接。无线调试关闭时保持未连接,不弹出错误。
- 授权所有 App:在“选择应用”里新增“所有 App”开关,打开后包括系统设置、支付、银行、密码类 App 和 AndChamber 自己。开启前需要你确认一个单独的高风险提示。开启后代理能看到可启动 App 的列表;每个任务仍只操作一个 App;系统界面和锁屏仍然不允许操作。
- 系统设置这类会隐藏浮窗的 App:如果当前任务要操作的 App 会强制隐藏第三方浮窗(例如系统设置),这个任务会自动改用通知栏里的停止入口;通知停止入口不可用时仍然拒绝操作。
- 操作 AndChamber 自己:可以操作 AndChamber 的首页和聊天页,但打开手机控制页时仍会收回授权。手机控制页正在显示时请求操作 AndChamber,会返回
PHONE_SCREEN_OPEN,提示你先离开这个页面再重试。 - 更稳定:输入法、启动画面这类临时窗口占据焦点时,按“窗口变化”自动重试,不再报
DRIVER_UNAVAILABLE。授权被撤回后,读取操作会立即让出,下一次请求不会再误报BUSY;一次失败的启动也不会再把后续请求卡住。
验证范围
- 在模拟器(API 35 / x86_64)上用独立测试包、真实浮窗和测试 App 验证:截图时浮窗每次隐藏约 0.2–0.4 秒、过程中从未被拆掉;冷启动自动进入本机聊天,约 40 秒内在后台自动连上手机,全程没有打开手机控制页;“所有 App”下代理能打开系统设置并读屏(通知栏停止入口一直在);代理能操作 AndChamber 首页,打开手机控制页后授权被收回;手机控制页打开时请求操作 AndChamber 返回
PHONE_SCREEN_OPEN。真实浮窗安全测试全部通过。 - 2,147 项 JVM 测试、361 项 Node 测试(360 项通过、1 项原有跳过)、72 项 Python 测试通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上复测;验证过程中模拟器本身的图形组件崩溃过几次,属于电脑端模拟器问题,App 没有崩溃。
Improvements
- Steady capsule: capture makes the same window invisible instead of removing and re-adding it, and the slow page reads run before the hide and after the restore, so the capsule is hidden only around the screenshot itself. The running capsule reserves a fixed two-line progress height.
- Open and use: launch follows the most recent instance (remote stays remote; otherwise the local chat starts and opens), including from the phone page.
- Automatic phone reconnect for a previously configured phone link when the local chat is in front, after this launch's phone tool is ready; silent when wireless debugging is off; never opens the phone page.
- All apps scope (opt-in with a separate high-risk confirmation): includes Settings, payment/bank/password apps and AndChamber itself; the model sees the launchable app list; still one app per task; system UI and keyguard stay refused.
- Targets that hide overlays (e.g. Settings) switch that task to the verified notification stop entry; otherwise refused.
- AndChamber as a target works on Home/chat; the phone-control page still revokes, and a request while it is open returns
PHONE_SCREEN_OPEN. - Robustness: IME/splash focus is a retryable window change, read-only calls release their slot immediately on revoke, and a failed start no longer leaves a halt that blocks the next request.
Verification scope
- API 35 / x86_64 emulator with a separate test package, the real overlay and a synthetic target, as described above; real-overlay safety instrumentation passed.
- 2,147 JVM, 361 Node (360 passed plus one existing skip) and 72 Python tests, Android lint and debug/AndroidTest packaging passed.
- Not re-tested on a real phone.
AndChamber v0.0.37
v0.0.37 — 读屏不再因为多带一个参数而报 HTTP 400
A snapshot no longer fails with HTTP 400 because of one extra field.
修复
- 多带了参数就整个调用失败:模型调用读屏(
snapshot)时,常会把刚从状态里看到的epoch一起带上。以前手机工具把多出来的参数当成错误整个拒绝,模型只看到 “HTTP 400”,于是一直卡在读不了页面这一步。现在epoch、observationId这类从上一步抄过来的参数,用不到的动作会直接忽略,不再拒绝。 - 参数真错了也能看懂原因:参数确实不对时,不再返回 HTTP 400,而是返回普通的错误结果
INVALID_REQUEST,并说明各个动作需要哪些参数,模型能据此改正后重试。什么操作都不会执行。
验证范围
- 在模拟器(API 35 / x86_64)上直接调用真实的手机工具接口:带
epoch的snapshot不再被拒绝;带epoch的status正常返回;真正不合法的参数返回 HTTP 200 和INVALID_REQUEST。 - 2,103 项 JVM 测试和 361 项 Node 测试(360 项通过,1 项为原有跳过)通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上复测。
Fixes
- One extra field failed the whole call: models often copy
epochfromstatusintosnapshot. The tool refused the call and the model only saw "HTTP 400". Copied context fields (epoch,observationId) are now ignored by actions that do not use them. - Readable refusals: a genuinely invalid call returns HTTP 200 with
INVALID_REQUESTand a fixed message listing each action's fields, instead of a bare HTTP 400. Nothing is executed.
Verification scope
- On an API 35 / x86_64 emulator, against the real tool endpoint:
snapshotwithepochis no longer refused,statuswithepochsucceeds, and an invalid field returns HTTP 200 +INVALID_REQUEST. - 2,103 JVM and 361 Node tests (360 passed plus one existing skip) passed, with lint and debug/AndroidTest packaging.
- Not yet re-tested on a real phone.
AndChamber v0.0.36
v0.0.36 — 浮窗常驻、自动让开、直接看进展
The capsule stays visible, moves out of the way, and shows progress.
改进
- 浮窗一直显示:以前每次读屏前都会把浮窗隐藏,读完再显示,所以操作过程中浮窗会时隐时现。现在读屏时浮窗一直保持显示,只有截图时才会短暂隐藏,避免截图里带上你写的任务说明和聊天提醒。
- 浮窗挡住目标时自动让开:如果代理要点、要滑或要输入的位置正好被浮窗挡住,浮窗会先自动收起,移到屏幕另一侧或离目标远的位置,确认不再挡住后才执行操作。实在让不开时只拒绝这一下,任务不会停。自动让开不会改掉你自己拖好的位置。
- 浮窗上直接看进展:运行中的胶囊显示简短状态、已发出的操作数,下面最多两行显示最新一步(例如已读屏、已点按,或者代理说的话)。接管按钮改成圆形手掌图标,触控区域仍不小于 48dp。读屏时 TalkBack 能读出完整内容,但不会每走一步就自动播报。
- 去掉“未核实”标记:浮窗、停止卡片和完成提示里,代理说的话不再加“未核实 / 未核验”。你主动结束、接管,或结果说不准时,仍会显示完整的核对卡片,避免重复提交。
- 任务结束后,别的聊天可以直接用手机:以前第一次使用手机控制的聊天会一直占着手机,其他聊天会提示被占用。现在只有任务进行中或等你处理时才会拒绝其他聊天;任务结束后,同一个 OpenChamber 里的任何聊天都可以直接发起新任务,不用重新设置。
验证范围
- 在模拟器(API 35 / x86_64)上,用独立测试包、测试 App 和真实浮窗验证了:浮窗被拖到 Next page 按钮上方后,代理点击这个位置,浮窗自动移开,点击成功并进入第二页,整个过程中浮窗一直显示(抽样 56/56 次都在);胶囊进展行能完整读出,没有被导航栏挡住;A 聊天任务进行中时 B 聊天被拒绝,A 结束后 B 能直接开始并完成点击,B 进行中时 A 被拒绝。
- 真实浮窗安全测试(读屏时浮窗保持显示、截图不含浮窗、点在浮窗上被拒绝、浮窗移动后按新位置判断、目标 App 要求隐藏浮窗时拒绝操作)和读屏/点击/返回/输入的端到端检查都通过。
- 全部 JVM、Node、Python 测试通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上复测;没有验证大字号、横屏、TalkBack 的实际朗读和中文排版。
Improvements
- The capsule stays visible: hierarchy reads no longer hide and re-add the overlay; only screenshots hide it briefly.
- Automatic make-way: when a tap, swipe or input focus would hit the capsule, it collapses and moves aside once, is re-verified from the real window frame, and only then is the action sent; otherwise just that action is refused as
OVERLAY_OBSTRUCTED. The automatic move is not saved as your own position. - Progress on the capsule: a short status, dispatch count and up to two lines of the latest step or agent note; Take over is a 48dp icon button; TalkBack reads the full text without announcing every step.
- No "not verified" labels on agent notes; person ends, take-overs and uncertain stops keep the full check card.
- Other chats after a task ends: another chat is refused only while a task is live or waiting; afterwards any chat on the same runtime may start the next task.
Verification scope
- API 35 / x86_64 emulator with a separate test package, synthetic target and the real overlay: a tap under the capsule made it move away and succeed with the overlay visible throughout; the progress line was fully readable; the A/B chat handoff behaved as above. Real-overlay safety instrumentation and real-driver end-to-end checks passed.
- All JVM, Node and Python tests, Android lint and debug/AndroidTest packaging passed.
- Not re-tested on a real phone; large font, landscape, TalkBack speech and Chinese layout were not checked.
AndChamber v0.0.35
v0.0.35 — 浮窗不再把代理“误停”
The progress capsule no longer stops the agent by mistake.
修复
- 浮窗内容一更新,代理就被停下:以前浮窗只要有一点变化,比如聊天里来了一条新提醒、浮窗被展开或收起、被拖动了位置,代理的下一次操作就会被当成“浮窗可见性无法确认”。结果是代理被停下,还被标成“结果未知”。这正是“浮窗可见性无法确认 / 操作已发出,但没能确认是否生效”的主要来源。现在这类显示上的变化不再中断任务:每次操作前都会重新读取浮窗的真实位置,再做判断。
- 点到浮窗上只拒绝这一下:如果代理要点的位置、滑动的路线或要输入的框正好被浮窗挡住,现在只拒绝这一个操作,并返回新的
OVERLAY_OBSTRUCTED,告诉代理换个位置或先滚动页面。任务不会被停下,也不会被标成结果未知。 - 真正的风险仍然会停下:浮窗被隐藏或无法确认是否可见、换成了另一个浮窗、屏幕方向或尺寸变化,仍按原来的规则停下。截图时仍会先隐藏浮窗。
验证范围
- 在 API 35 / x86_64 模拟器上,用真实的系统浮窗跑了浮窗安全测试:截图里不会出现浮窗;点在浮窗上被单独拒绝,点在浮窗外正常执行;浮窗被移动、放大后,按它新的真实位置判断;目标 App 要求隐藏浮窗时仍然拒绝操作。读屏、点击、返回、输入的端到端检查也全部通过。
- 2,080 项 JVM 测试、361 项 Node 测试(360 项通过,1 项为原有的跳过)通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上复测。
Fixes
- Capsule updates no longer stop the agent: any display change (a chat notice, expand/collapse, a drag) bumped the capsule revision, and the next action treated it as "overlay visibility could not be confirmed", stopping the agent with an unknown outcome. The revision is no longer part of the observation identity; each action re-reads the real capsule frame and checks against it.
- Hitting the capsule refuses only that action: a point, swipe or input focus on the visible capsule now returns
OVERLAY_OBSTRUCTEDwithout stopping control or marking anything unknown. - Real risks still stop: a hidden or unverifiable overlay, a new display owner/generation, or a rotation/display change still fail closed. Capture still hides the capsule.
Verification scope
- Real-overlay safety instrumentation on an API 35 / x86_64 emulator: capture self-exclusion, inside-capsule refusal with outside taps sent, a moved/expanded capsule checked against its fresh frame, and target-requested overlay hiding still refused; the real-driver observe/tap/back/input checks also passed.
- 2,080 JVM and 361 Node tests (360 passed plus one existing skip) passed, with lint and debug/AndroidTest packaging.
- Not yet re-tested on a real phone.
AndChamber v0.0.34
v0.0.34 — 代理说完成,不再弹大卡片
An agent's own finish shows a light note instead of a full check card.
改进
- 代理自己报告完成时,只显示一条小提示:以前每个任务结束后,手机操控页都会被一张“已结束 · 请核对结果”的大卡片占满,必须点“关闭”才能回到正常页面。现在,如果是代理在正常授权下自己报告完成(没有停手、没有结果不确定的操作),只在页面顶部显示一行“代理报告已完成”,并说明“结果未自动核实”。可以点“打开 App”去看一下,也可以直接点“知道了”。页面其他部分保持正常可用。状态条显示为“已完成(未核实)”。
- 你主动结束、接管或结果不确定时,仍显示完整的核对卡片:这些情况更可能出现重复提交或操作只做了一半,所以仍然提醒你去核对。
- 旧的结果卡不再挡住自动恢复:OpenChamber 重启后,一张没关的结果卡不再被当成“还有任务没处理完”,不会阻止“已暂停”自动解除。
验证范围
- 模拟器(API 35 / x86_64)上的独立测试包和测试 App:代理报告完成后,只显示一条小提示,页面仍是“可以在聊天里使用”;点“知道了”后提示消失,任务状态清空。你在原生页面结束任务时,仍显示完整的“待核对”卡片。
- 2,079 项 JVM 测试通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上复测。
Improvements
- An agent's own finish shows a light note: a task the agent itself reported finished, on a clean live grant (no stop, nothing uncertain), no longer takes over the phone-control screen with a full "check the results" card. A one-line "The agent reported it's done — not verified automatically" note appears above the normal page with "Open app" and "Got it"; the status line says "Done (not verified)".
- Person stops, take-overs and uncertain ends keep the full check card, since those are where a repeated or half-done action is most likely.
- An old result card no longer blocks the automatic resume after an OpenChamber restart.
Verification scope
- On an API 35 / x86_64 emulator with a separate test package and the synthetic target: after a model finish only the light note appears and the page stays ready for chat; "Got it" clears it and the retained task. A native End still shows the full check card.
- 2,079 JVM tests passed, with lint and debug/AndroidTest packaging.
- Not yet re-tested on a real phone.
AndChamber v0.0.33
v0.0.33 — 页面一直在变也能点
Taps work on pages that keep changing.
修复
- 页面内容变化不再拦住点击:以前读屏后,页面上任何文字或位置变了(倒计时、轮播图、价格、角标),点击都会被拒绝,返回
WINDOW_CHANGED。电商这类页面几乎一直在变,导致点击几乎总是失败。现在只要求仍是同一个真实窗口(同一个界面、同一个应用、方向和屏幕尺寸不变),页面内容的正常变化不再拦住操作。 - 按元素点击仍会核对目标:通过元素编号点击时,要求读屏时的那个元素仍在原来的位置。元素已经消失或移动时,仍然拒绝,避免点错。
- 仍然会拒绝的情况:切换到新界面或弹出新窗口、切到别的应用、旋转屏幕、屏幕尺寸变化。截图、浮窗遮挡和授权检查不变。
验证范围
- 模拟器(API 35 / x86_64)上运行了真实驱动的端到端检查:同一窗口内容变化后,截图和点击可以继续;元素不在原位置的点击被拒绝;新界面仍会让旧读屏失效;返回和输入正常。
- 2,075 项 JVM 测试、361 项 Node 测试(360 项通过,1 项为原有跳过)通过,lint 和 debug/AndroidTest 打包通过。
- 还没在真机上的电商页面复测这一版。
Fixes
- Content changes no longer block taps: any change in text or position after a snapshot (countdowns, carousels, prices, badges) used to refuse an action with
WINDOW_CHANGED, so constantly updating pages could almost never be tapped. Actions now require only the same real window (same activity, app, rotation and display size). - A tap by element still checks its target: the observed element must still be live at exactly the same bounds; a moved or missing element is refused.
- Still refused: a new activity or dialog window, another app, rotation or a display-size change. Capture, overlay and authorization checks are unchanged.
Verification scope
- Real-driver end-to-end checks on an API 35 / x86_64 emulator: capture and taps continue after a same-window content change, a tap whose element is not at its observed bounds is refused, a new activity still invalidates the old snapshot, and back/input work.
- 2,075 JVM and 361 Node tests (360 passed plus one existing skip) passed, with lint and debug/AndroidTest packaging.
- This build has not yet been re-tested on a real phone with a shopping page.
AndChamber v0.0.32
v0.0.32 — 读屏不再误报“设备不可用”
Reading the screen no longer reports "unavailable on this device" by mistake.
修复
- 读屏偶发空结果会自动重读:在一台真实的 Android 17 手机上,如果上一次读屏还没在手机上结束,下一次读屏会什么都读不到(系统提示 UiAutomation 已被占用)。以前这会被当成驱动故障,报
DRIVER_UNAVAILABLE。现在会在同一次调用的时间限制内,每隔一小段时间重新读,最多 6 次;只读,不点击、不输入。 - 一直读不到时,报“页面暂时读不到”:重读后仍为空,返回
HIERARCHY_NOT_IDLE。按已有规则,这会保留原任务和授权,不会被当成需要人工处理。 DRIVER_UNAVAILABLE的提示更准确:不再说“此设备不可用”,而是说明这次读取的内容无法解析,不代表设备不支持或断线,也不能证明之前的操作是否已经生效;不要重复执行改动类操作,先重新读屏。
验证范围
- 在一台真实的 Android 17 / arm64 手机上做了只读采样:前台应用的页面结构能正常读取;两次读屏重叠、或刚放弃一次读屏后马上再读,都能稳定复现空输出,等上一次结束后再读就恢复正常。模拟器上也能复现同样的重叠现象。
- 2,074 项 JVM 测试、361 项 Node 测试(360 项通过,1 项为原有的跳过)、72 项 Python 测试全部通过,lint 和 debug/AndroidTest 打包也通过。
- 尚未在真机上安装新版本完整复测;上一次读屏为什么会被放弃,没有在真机上单独验证。
Fixes
- An empty screen read is re-read: on a real Android 17 phone, a hierarchy read that overlaps an earlier on-device read still running returns nothing (UiAutomation is already registered). It used to be reported as
DRIVER_UNAVAILABLE. The read is now retried a bounded number of times (at most six) within the same call deadline. It only reads; it never taps or types. - A read that stays empty is
HIERARCHY_NOT_IDLE: under the existing rules this keeps the original task and grant and is not a reason for a person handoff. - Accurate
DRIVER_UNAVAILABLEmessage: it no longer says the device is unsupported. It says this call's output could not be parsed, which proves neither an unsupported device nor a lost connection, and does not confirm whether an earlier action applied. Do not repeat a mutating action; take a fresh snapshot.
Verification scope
- Read-only sampling on a real Android 17 / arm64 phone: the foreground app's hierarchy reads normally; overlapping reads, or a read right after an abandoned one, reproducibly return empty output, and reads recover once the earlier one finishes. The same overlap reproduces on the emulator.
- 2,074 JVM, 361 Node (360 passed plus one existing skip) and 72 Python tests passed, with Android lint and debug/AndroidTest packaging.
- The new build has not yet been installed for a full re-test on the phone, and why the earlier read was abandoned was not separately verified on the device.
AndChamber v0.0.31
v0.0.31 — 少打断、原任务接着做
Fewer interruptions, finish the original task.
修复与改进
- “等你处理”和“你主动接管”不再混淆:等待人工处理时保留原任务,不再误显示成“已结束”,并显示等待原因和继续入口。
- 聊天能分清“没有活动授权”和“任务仍保留”:新增只读字段
taskRetained、taskState、continuationState、continuationFailure;原taskPresent仍只查询当前授权编号。这些状态不会赋予操作权限,也不包含任务标识或页面文本。 - 继续失败后能再次确认:尚未尝试唤醒聊天,且没有恢复授权或已确认撤销本次授权时,显示
NOT_RESUMED和真实技术原因。原任务、历史和会话保持不变;处理原因后可再次确认继续,不必重说任务、重新配对或重设范围。 - “已恢复,但聊天提醒未确认”单独处理:
FAILED保守表示这次唤醒结果未确认,不重复投递同一次唤醒,也不会仅凭“当前没有授权”就允许重试。如果授权已恢复,仍可回聊天发起新的读取,无需再次授权。 - 必要的停手保护保留:锁屏、断线、敏感确认和结果不确定时仍停手,不自动重连或恢复,也不重放已发送或结果不确定的操作。继续只对同一运行环境和会话有效;App 或进程重启不会自动恢复旧任务。
- 继续按钮首屏可见:浮窗的继续入口不会再被通知和最近记录挤到下面;未恢复时先显示原因和“再次确认继续”,不重复要求完成旧人工步骤。浮窗仍只打开原生确认,确认后才恢复授权;正在恢复时,停手按钮仍优先可见。
- 减少无谓的人工接管引导:普通加载、窗口切换和暂时读不到稳定页面时,应保留有效的原任务,并有限地重新读屏;普通聊天提问、表单和 OpenCode 权限回复不等于手机交接。真正需要在手机上手动处理的步骤仍使用受保护的接力流程。未新增控制动作、请求参数或权限;工具说明和文案测试不能保证所有真实模型都不再误中断。
验证与重要边界
- 真实 API 35 / x86_64 独立 debug App + synthetic fixture:旧 v30 baseline 复现了 status 假阴性、保留任务被显示 Ended/You took over,以及继续失败按钮 no-op。新构建在 waiting 状态显示
taskRetained=true/WAITING_USER/NO_GRANT,原任务保留。 - busy 30 的第一次继续:在 wake 前返回
NOT_RESUMED+SCREEN_NOT_IDLE,没有发送 wake,仍是同一任务;页面稳定后第二次 person confirm 真正进入 fresh native epoch/route/Observe,原会话 fixed wake 恰好 1 次,request tool count 仍为原任务的 1,tap 1 次,独立读回Saved为 1。最终 layout 的源码 APK 也用同一负例重跑成功。 - 普通运行中的 busy snapshot:返回
HIERARCHY_NOT_IDLE,但 phase 仍READY、同一 epoch/grant、connected、未 block,task 仍ACTIVE;没有新增need_user。页面稳定后同一 epoch 的新 snapshot 成功,不需要额外 native confirm。这证明 native 不会自动升级成 need-user,不代表真实模型一定遵守 DESCRIPTION。 - 第二次 manual stop 与 wake fault:第二次 manual stop 把先前的
DELIVERED重置为IDLE。native 恢复后,隔离的 wake HTTP fault 产生FAILED,但 phase 仍READY/ACTIVE、connected、未 block;原会话 fixed wake 计数 before 1 / after 1,故障规则已清理。显式打开 chat 做只读 snapshot 不需要再次授权,仍是同一 grant;FAILED仍保守不可重发。显式 model finish 进入ENDED_PENDING_CHECK,native Close 后taskRetained=false。 - 发布前全量:2,070 JVM 项,0 失败/错误/跳过;Node 361 项(360 通过、1 项既有跳过);Python 72 项;Android lint、debug 与 AndroidTest APK packaging 通过,保留 warnings/information,不声称零 warning。末次 description copy 用完整 Node 361 项加 APK asset build 复核。
- 证据范围:未新增 device instrumentation、未使用真机、未覆盖 API 37/arm64、large font、landscape 或 TalkBack。新 layout 只有默认 English、当前 phone viewport 的视觉证据;旧证据没有被扩大。持续动态 hierarchy 仍不支持,Unicode 输入限制未改。正式 App 未被触碰;测试任务、权限、AppOps、overlay mode、无线调试、owned forwards、fixture wrapper、model server、inspector 和 fault 均已恢复/清理。
Fixes and improvements
NeedUseris separate from a personTakenOver: an agent request for a person is no longer shown as “you took over”. A retained native task is not labelled Ended merely because a needs-check record exists; while waiting, the original task, the waiting reason and its Continue entry remain visible.- Read-only handoff status:
taskPresentremains the strict live-epoch boolean;taskRetained,taskState,continuationStateandcontinuationFailurecome from the same bound task store and screen facts. They grant nothing, resume nothing, and expose no task key or page text. - A technical failure before recovery can be confirmed again: a continuation that fails before native readiness and before any wake, with no new grant (or a confirmed exact rollback), records
NOT_RESUMEDwith a fixed reason. The same task key, history, latest attempted epoch and native stop receipt are kept. The task is not abandoned; a person may confirm again and enter a fresh grant/Observe without retelling the task, reconfiguring the scope or resetting it. Failedstays conservative and the same wake is never re-sent: only a real recovery that reached the chat wake can becomeFAILED, meaning that one wake was not confirmed. That same wake is not retried automatically or manually, and a missing grant alone never turns an oldFailedinto a retry. If recovery is established and only the wake failed, the grant stays active; an explicit read-only read in the chat does not require another authorization.- Hard stops and boundaries are unchanged: unknown outcomes, a newer owner, screen lock, connection loss and sensitive confirmation remain hard stops. There is no automatic scope recovery, reconnect or replay of sent results. An original task is valid only for the same runtime/session; an App or process restart never restores an old task automatically.
- The UI entry is direct: the primary CTA stays visible on the first screen and is not pushed out by chat notices/Recent.
NOT_RESUMEDshows the fixed technical cause and Confirm again instead of repeating the old manual step. Overlay Continue still only navigates to the native confirmation dialog; a grant appears only after the person confirms, and no overlay authorization was added. Stop controls stay ahead ofSENDING/DELIVERED/FAILED. - Guidance covers only confirmed handoffs: ordinary busy/window/stale states get a bounded fresh read-only observation on the same live grant and never become an automatic
need_user. A handoff is for genuine manual phone work such as login, captcha, payment, phone permission or unsupported input. Ordinary chat questions, forms and OpenCode permission replies do not need a phone handoff. No tool input action or schema was added; a SENT/UNKNOWN mutation is never replayed. Guidance/copy tests are not real-model compliance and cannot guarantee that every automatic interruption is eliminated.
Verification and limitations
- Real API 35 / x86_64 independent debug App + synthetic fixture: the old v30 baseline reproduced the false status, the retained task shown as Ended/You took over, and the no-op continue button. The new build reports
taskRetained=true/WAITING_USER/NO_GRANTwhile waiting and keeps the original task. - First continue under 30-second busy: it returned
NOT_RESUMED+SCREEN_NOT_IDLEbefore any wake, sent no wake and kept the same task. After the page stabilized, a second person confirmation entered a fresh native epoch/route/Observe; the original session received exactly one fixed wake, the request tool count stayed at the original task's one, one tap was made, and an independent read-back sawSavedexactly 1. The final-layout source APK repeated the same negative-then-success run. - Ordinary running busy snapshot: it returned
HIERARCHY_NOT_IDLEwhile phase stayedREADY, the epoch/grant stayed the same, the connection stayed connected and unblocked, and the task stayedACTIVE; noneed_userwas created. A fresh snapshot after the page stabilized succeeded on the same epoch without another native confirmation. This shows native behavior, not a guarantee that a real model follows the description. - Second manual stop and wake fault: a second manual stop reset the previous
DELIVEREDstate toIDLE. After native recovery, an isolated wake HTTP fault producedFAILED, but phase stayedREADY/ACTIVE, connected and unblocked; the original session's fixed-wake count was before 1 / after 1 and the fault rule was cleaned up. An explicit read-only chat snapshot needed no new authorization and stayed on the same grant;FAILEDremained non-retryable. Explicit model finish reachedENDED_PENDING_CHECK, and native Close settaskRetained=false. - Pre-release full checks: 2,070 JVM tests with no failures, errors or skips; 361 Node tests (360 passed plus one existing skip); 72 Python tests; Android lint, debug and AndroidTest APK packaging passed with retained warnings/information, not a zero-warning claim. The final description copy was rechecked with all 361 Node tests and an APK asset build.
- Evidence limits: no new device instrumentation, no physical device, no API 37/arm64, large-font, landscape or TalkBack coverage. The new layout has visual evidence only for the default English current-phone viewport; earlier evidence is not expanded. Dynamic hierarchy remains unsupported and Unicode input limits are unchanged. The production App was not touched; test tasks, permissions, AppOps, overlay mode, wireless debugging, owned forwards, fixture wrapper, model server, inspector and fault were all restored/cleaned.
Verify the download with the attached .sha256 file.
AndChamber v0.0.30
修复与改进
- 启动观测不再由下一次读取掩盖首因:旧启动观测只有 5 秒,而 AOSP
uiautomator的 idle 等待是 1 秒 quiet / 10 秒全局上限。忙目标上 App 自己的读 watchdog 先到期并关闭本地连接,随后一次 Observe 只看到NOT_CONNECTED,首个真实原因被覆盖。现在启动/续接观测共享一个最多 15 秒的预算(包含 overlay surface 等待和真实剩余时间),fatal 结果不再盲重试;固定HIERARCHY_NOT_IDLE/READ_TIMEOUT及startFailureStage保留首个 typed 原因。普通调用的 15 秒上限没有被延长;driver 只在原预算内预留不超过 500 ms 的上报余量,外层先到期仍可是普通DEADLINE。 - 忙层级与读超时按固定原因安全拒绝:层级输出只有在整体 trim 后精确等于 AOSP 固定 idle 句时才是
HIERARCHY_NOT_IDLE;合法 XML 里出现同样文字不会被误标,partial/invalid/unknown 仍 fail-closed。READ_TIMEOUT覆盖 read-service 的open与read:表示该事务已放弃 exact connection,core 在同一次 execute 内发布 logical disconnect/revoke,保留 unknown,并用 connection owner fence 保护更新连接;不声称物理 socket close 已完成。原有 hard watchdog 仍会关闭 stream 和 connection,没有 stream-only 保活。 - 启动窗口的 null 字段只做有界重试:窗口管理器输出中只有完整官方字段行
mCurrentFocus=null或mFocusedApp=null且对应 match 缺失时,才归类为NOT_READY并映射为WINDOW_CHANGED,且只在既有 shared startup 预算内重试明确 window transition。缺字段、截断、超出 cap、坏 package/activity 或未知格式仍 fail-closed;不产 partial window/target nodes,capture/mutation 的两侧窗口核验以及 sensitive/overlay/target 安全都不放宽。 - 取消与未知结果语义不变:grant 之后的 cancel 仍精确回滚该 epoch/task 并传播原
Cancelled,不会影响更新的 owner;touched/afterWrite的结果仍是UNKNOWN,不会自动重放。旧的 scope 与 person resume 路径保持不变。 - bounded-busy 钩子只在独立 test APK:默认值为 0,不新增权限或服务,也不属于生产后台功能。
验证与重要边界
- 在 API 35 / x86_64 模拟器的独立安装包与 deterministic protocol fixture 上,四组真实流程全部通过:
- static 0:正常 request/tap/read-back,
Saved恰好 1; - 6 秒 bounded busy:页面稳定后成功启动,
Saved恰好 1,connected true;完整场景还包含后续 read-back,不是观测预算被延长; - 30 秒持续 busy:返回
HIERARCHY_NOT_IDLE/OBSERVATION,noGrant/noTask,connected true;只有一次 terminal,没有盲重试; - forced read fault:返回
READ_TIMEOUT/OBSERVATION,logical connected=false、NO_GRANT、grant 0、taskPresent=false、Saved0,专属故障规则已清理。
- static 0:正常 request/tap/read-back,
- 发生上述故障后,由人员显式重新连接可以恢复,没有自动创建 task。所有 clean build 均未包含临时 probe;baseline 的固定 enum 日志也已移除。
- 发布前全量检查通过:2,035 项 JVM,0 失败、错误或跳过;Node 360 项(359 通过、1 项既有跳过);Python 72 项通过。Android lint、debug 和 AndroidTest APK 构建通过,保留既有 lint warnings/information。本轮没有新增 device instrumentation,也没有使用真机。
- 本轮测试环境已清理,未触碰正式 App。
- 证据仍仅覆盖 API 35 / x86_64 模拟器;模型端是 deterministic fixture,不代表真实模型推理。不要据此声称已证明用户手机现场根因、排除所有 OEM 差异或支持持续动态页面;持续 busy 页面仍不能提供有效层级,因此是安全拒绝。
Fixes and improvements
- The first startup-observation failure is no longer masked by the next read: the old startup observation had only 5 seconds, while AOSP
uiautomatorwaits 1 second of quiet and up to 10 seconds globally for idle. On a busy target the App's own read watchdog expired first and closed the local connection; a later Observe then saw onlyNOT_CONNECTED, hiding the real first cause. Startup/continuation observation now shares one budget of at most 15 seconds (including the overlay-surface wait and real remaining time), and a fatal result is not retried blindly; the fixedHIERARCHY_NOT_IDLE/READ_TIMEOUTandstartFailureStagekeep the first typed cause. Ordinary calls keep their existing 15-second bound; the driver only reserves at most 500 ms of the original budget as a reporting margin, so an outer win can still be an ordinaryDEADLINE. - Busy hierarchy and read timeout are refused with fixed reasons: hierarchy output is
HIERARCHY_NOT_IDLEonly when the whole trimmed output is exactly the AOSP fixed idle sentence; a valid XML page containing the same words is not misclassified, and partial/invalid/unknown output stays fail-closed.READ_TIMEOUTcovers bothopenandreadof a read service: the transaction has abandoned the exact connection, the core publishes a logical disconnect/revoke in the same execute, keeps unknown, and fences the revoke to that connection owner so a newer connection survives; it does not claim the physical socket close completed. The existing hard watchdog still closes the stream and connection, with no stream-only keepalive. - Null startup window fields get only a bounded retry: a complete official
mCurrentFocus=nullormFocusedApp=nullfield line with its matching window missing is typedNOT_READYand mapped toWINDOW_CHANGED, retried only for explicit window transitions inside the existing shared startup budget. Missing fields, truncation, over-cap output, bad package/activity or unknown formats stay fail-closed; no partial window/target nodes are produced, and both-side window verification plus sensitive/overlay/target safety are not relaxed. - Cancel and unknown semantics are unchanged: a post-grant cancel still rolls back exactly that epoch/task and propagates the original
Cancelledwithout affecting a newer owner;touched/afterWriteresults remainUNKNOWNand are never replayed. The existing scope and person-resume paths are unchanged. - The bounded-busy hook exists only in the independent test APK: its default is 0, it adds no permission or service, and it is not a production background feature.
Verification and limitations
- Four real flows passed with an independent package and the deterministic protocol fixture on the API 35 / x86_64 emulator:
- static 0: a normal request/tap/read-back with
Savedexactly 1; - 6-second bounded busy: a stable page then a successful start with
Savedexactly 1 and connected true; the complete scenario also includes a later read-back and is not an observation-budget extension; - 30-second sustained busy:
HIERARCHY_NOT_IDLE/OBSERVATION, noGrant/noTask and connected true; exactly one terminal attempt, with no blind retry; - forced read fault:
READ_TIMEOUT/OBSERVATION, logical connected=false,NO_GRANT, grant 0, taskPresent=false andSaved0; the dedicated fault rule was cleared.
- static 0: a normal request/tap/read-back with
- After those failures, an explicit person reconnect recovered the connection; no task was created automatically. Every clean build was free of temporary probes, and the baseline fixed-enum logging was removed as well.
- Pre-release full checks passed: 2,035 JVM tests with no failures, errors or skips; 360 Node tests (359 passed plus one existing skip); and 72 Python tests. Android lint, debug and AndroidTest APK packaging passed with existing lint warnings/information. No new device instrumentation was executed, and no physical device was used.
- The test environment was fully cleaned up without touching the production App.
- The evidence remains API 35 / x86_64 emulator only, with a deterministic protocol fixture rather than real model reasoning. Do not claim that a user's on-device root cause has been proven, that all OEM differences are excluded, or that continuously dynamic pages are supported; a sustained busy page still cannot provide a usable hierarchy and is therefore refused safely.
Verify the download with the attached .sha256 file.
AndChamber v0.0.29
修复与改进
- 修复“原生显示 Ready,但新 request 返回 STANDING_BLOCKED”:此前 UI 没有把 core 的 standing pause 显示为真实暂停原因,runtime 重启后又可能既没有任务、也没有恢复入口。现在原生页显示实际的 Paused 原因,并提供“恢复聊天”;该恢复使用明确的人员确认框。既有 standing scope 与永久时限保持不变。
- 仅允许显式的人员无任务恢复:只有在没有活动任务、授权、停止记录、在途操作或待核对的未知结果,且连接、tool 和前台 stop entry 都已就绪时,人员确认才可解除该暂停。确认本身不创建 grant、不启动应用、不发送 wake prompt、不重放旧操作,也不修改 scope deadline 或 session binding。打开原生页、重新连接或 RPC Ready 都不会自动清除 block;旧 halted task 继续保留原有 Continue,不会仅因 Paused 被禁用;未知结果仍需核对,scope 恢复不能绕过它。
验证与重要边界
- 已在 API 35 / x86_64 模拟器的独立测试包中复现并验证真实交互:使用 scope 一次、finish 后从首页 Stop/Start,关闭已结束任务,再 Find and connect 时,旧界面显示 Ready,但状态为
RUNTIME_CHANGED,新 request 返回STANDING_BLOCKED。修复后同一路径显示真实 Paused;选择 Cancel 保持 block、epoch 和无任务状态;确认后变为 Ready,解除 block,不产生 grant 或任务,epoch 不变;持久化的 standing config 完全相等;上下文与模型 transcript 计数不变,确认没有发送 prompt;随后新 request 正常 Running,tap/readback 后 Saved 计数为 1。 - 已回归停止任务的原有 Continue beside the chat…:
need_user后仍可确认继续,由原生只发一次继续提示,同一会话完成输入并独立读回。暂停页、确认框、恢复后页面的实际截图也已核对。 - 发布前全量检查通过:1,970 项 JVM,0 失败、错误或跳过;Node 359 项(358 通过、1 项既有跳过);Python 72 项通过。Android lint、debug 和 AndroidTest APK 构建通过,保留既有 lint warnings/information。
- 本轮回归只覆盖 API 35 / x86_64 模拟器。模型端仍是确定性协议夹具,不代表真实模型推理或自主规划;平板、厂商系统、TalkBack 和多窗口差异未覆盖,本轮未新增设备 instrumentation 执行。
- 仍保持默认关闭、仅适用于可信整个本机 runtime 的既有边界;不声称此修复消除了所有暂停、未知结果或厂商差异问题。
Fixes and improvements
- Fixed “native Ready but a new request returns STANDING_BLOCKED”: the UI previously did not surface the core standing pause as its real pause reason, and a runtime restart could leave neither a task nor a recovery entry. The native page now shows the actual Paused reason and offers Resume chat through an explicit person confirmation dialog. Existing standing scopes and permanent durations are unchanged.
- Explicit person-confirmed no-task resume only: the pause can be cleared only when there is no live task, authorization, stop record, in-flight operation or unresolved unknown result, and the connection, tool and foreground stop entry are ready. Confirmation does not create a grant, launch an app, send a wake prompt, replay an old action or change the scope deadline/session binding. Opening the native page, reconnecting or RPC readiness never clears the block automatically. An old halted task keeps its original Continue path and is not disabled merely by Paused; unknown outcomes still require checking, and scope resume cannot bypass that check.
Verification and limitations
- The real interaction was reproduced and verified with an independent test package on the API 35 / x86_64 emulator. Baseline: use the scope once, finish, Stop/Start from Home, close the ended task, then Find and connect showed UI Ready while the status was
RUNTIME_CHANGEDand a fresh request returnedSTANDING_BLOCKED. After the fix the same path showed the real Paused state; Cancel kept the block, epoch and no-task state; Confirm became Ready, cleared the block, created no grant or task and left the epoch unchanged; the exact persisted standing config was unchanged; conversation context and model transcript counts stayed unchanged, confirming no prompt was sent. A subsequent fresh request ran normally, and tap/readback kept the Saved count at 1. - The existing stopped-task Continue beside the chat… path also passed: after
need_user, native confirmation sent exactly one continuation prompt, and the same session completed an input verified by independent read-back. Actual paused, confirmation and resumed-screen screenshots were reviewed as well. - Pre-release full checks passed: 1,970 JVM tests with no failures, errors or skips; 359 Node tests (358 passed plus one existing skip); and 72 Python tests. Android lint, debug and AndroidTest APK packaging passed with existing lint warnings/information.
- This regression is covered only on the API 35 / x86_64 emulator. The model remains a deterministic protocol fixture, not real reasoning or autonomous planning. Tablet, vendor systems, TalkBack and multi-window differences are not covered, and no new device instrumentation was executed.
- The existing default-off and trusted-whole-local-runtime boundaries remain. This fix does not claim to eliminate every pause, unknown-outcome or vendor difference.
Verify the download with the attached .sha256 file.