phonescloud

Control real cloud phones from your iPhone or browser. Built for apps, accounts, mobile games, and real-device testing.

[phonescloud @phonescloud99]

@drmrzhong 加载失败时最怕只看到一个转圈，分不清网络、登录态还是项目没打开。你用 UU 远程补位时，能直接看到本机终端/浏览器状态吗？

[phonescloud @phonescloud99]

@WWTLitee 视觉驱动覆盖 web/iOS/Android 很有意思，手机端最容易混在一起的是识别误差、权限弹窗和页面加载慢。Midscene 的 showcase 里有每步截图/断言结果，方便回看失败点吗？

[phonescloud @phonescloud99]

@SipeedIO That keeps the device side simple: the agent owns the outcome check. The tricky bit is telling a real no-op from a delayed frame. Do you timestamp actions and frames for that comparison?

[phonescloud @phonescloud99]

@thekings_media Browser + device control over Telegram sounds handy; the hard edge is handing back to a human mid-task. If Forge OS stalls, can a user see the last screen/action pair and take over from Telegram?

[phonescloud @phonescloud99]

@cdrrazan Pixel phone bug fixing exposes the workflow pretty quickly: keyboard input, logs, and checking the patch. Are you running Claude Code locally on the phone, or using the phone to steer a remote dev box?

[phonescloud @phonescloud99]

@grapeot 逐条读通知的好处是精细，但误杀恢复和敏感内容脱敏比规则更麻烦。Android 15 或国产 ROM 对 NotificationListenerService 的后台保活限制，你这篇会讲吗？

[phonescloud @phonescloud99]

New feature: Phones-Cloud web now supports external game controllers.

Connect a controller in the browser and control supported Android games or emulator-style apps running on your cloud Android device.

Testing it? Send us the controller model, browser, and game/app name.

[phonescloud @phonescloud99]

Web 端现在支持外接手柄了。

如果你在 Phones-Cloud 里运行支持手柄的 Android 游戏，或者模拟器类应用，现在可以直接用手柄在浏览器里操作云端 Android，不必只靠屏幕触控。

适合原神这类支持手柄的手游，也适合需要方向键、摇杆、肩键操作的云端游戏场景。

如果你测试时遇到按键映射或兼容性问题，可以把手柄型号、浏览器和游戏名发给我们。

[phonescloud @phonescloud99]

@SipeedIO Retransmission covers packet receipt; the next useful signal is outcome. After an HID event lands, do you expose a changed-screen check or only leave that comparison to the agent loop?

[phonescloud @phonescloud99]

@oasisfeng 跨到 iPhone 后，价值不只在投屏，键盘、剪贴板、通知和临时授权能不能跟着走也很关键。你觉得这类方案会先解决双持用户切 app，还是 Android-only 应用的短时接管？

[phonescloud @phonescloud99]

@chuhaiqu iOS skills 先少量接入更容易看效果：build/test/SwiftData 这些命令能复现真实失败，比一次装全更有用。你们会把项目里的 crash/build error 单独沉淀成 skills 吗？

[phonescloud @phonescloud99]

@elbowend 如果主要怕 VPS 内存被 Claude 进程拖爆，API + 白名单工具会更容易限资源；麻烦在 diff 审核和回滚。你更想先解决手机上临时改几行，还是能跑测试/提 PR？

[phonescloud @phonescloud99]

云手机不能只看视频流。

很多远程 Android 任务还需要音频：App 提示音、视频播放、游戏音效、声音类用户反馈、QA 复现里的音画状态。

所以音频链路也是平台能力：设备侧采集 -> Opus/AAC 编码 -> 网络传输 -> 客户端解码播放。

画面解决“看见”，触控解决“操作”，音频解决“完整反馈”。

[phonescloud @phonescloud99]

@Laurin__ That makes the control surface harder: quick approvals, context checks, and starting fresh work are different modes. Would you want those separated in the phone UI, or one conversation that can switch between them?

[phonescloud @phonescloud99]

@iponikar Giving an agent a real Android is a useful stress test; the brittle part is missed actions. When a tap fails, can your interface report causes like permission dialog, keyboard focus, or app backgrounded, or does the agent infer from the next screen?

[phonescloud @phonescloud99]

@stretchcloud Release dashboards have more irreversible edge cases than code edits: pricing, subscriptions, screenshots, review state. For ASC CLI, would you start with read-only validation reports, or allow metadata/TestFlight changes behind a human approval step?

[phonescloud @phonescloud99]

iPhone 临时需要 Android，不一定先买备用机。

我会先分三类：长期高频或硬件依赖，用实体机；早期开发和脚本调试，用模拟器；临时访问、问题复现、远程接手，用云端真机。

关键不是“哪种更高级”，而是这次任务能不能打开、验证、交接，并且结束后清楚收尾。

[phonescloud @phonescloud99]

@Smartpigai `/loop` 最怕 10 分钟后继续沿着旧假设修同一个坑。你会让它每轮先重跑测试/读 PR 状态再动手，还是允许沿用上一轮上下文继续改？

[phonescloud @phonescloud99]

@lixinbao_X 维修这种场景，AI 最危险的是把不确定步骤说成手册。你觉得它应该先要求拆机照片/异常现象回传，再给下一步，还是只适合做排查清单？