Phones Cloud
A real cloud Android work phone for teams
2 followers
A real cloud Android work phone for teams
2 followers
Give remote teams controlled access to a real cloud Android device for handoffs, support troubleshooting, and QA workflows without shipping physical phones.
Short usage note with a video walkthrough:
I would test Phones-Cloud in a small workflow before treating it as a permanent device setup.
1. Open Phones-Cloud from an iPhone or web browser.
2. Start one real cloud Android device.
3. Launch the app or game flow you actually need to check.
4. Use the iPhone only as the control screen while the Android workload runs remotely.
5. Judge three things before scaling it: latency, loading behavior, and whether the account/app flow works normally.
This is not meant to replace a local device for long heavy sessions. The useful case is shorter: support reproduction, QA checks, backup Android access, or deciding whether you really need to buy and maintain another phone.
Video walkthrough:
https://x.com/phonescloud99/status/2059837030629359975
Website:
https://www.phones-cloud.com
Maker update:
We published a technical overview of what Phones Cloud is building beyond remote screen streaming.
The short version: a cloud phone is not just a video session. A real Android device keeps package state, app data, downloads, permission grants, settings, foreground activities, background processes, and vendor-specific behavior.
For the platform to be useful for support, QA, developer workflows, and AI/mobile automation experiments, the system has to handle more than pixels:
- video/audio data plane
- touch, key, screenshot, shell, and file control plane
- Relay binding between device, user, client, and session
- write deadlines, bounded buffers, and stale-session cleanup
- ordered and background command queues
- request IDs and result matching for concurrent device tasks
- device reclaim pipelines for apps, storage, permissions, and baseline state
- user-visible latency indicators
Full post:
https://www.phones-cloud.com/blog/phones-cloud-technical-capabilities-beyond-remote-phone
Chinese version:
https://www.phones-cloud.cn/blog...
Maker update: We published a technical note on the real-time control path for letting agents operate real Android devices through Phones Cloud. The short version: a useful agent interface should not be one giant "do the task" command. For mobile work, the more reliable loop is: observe the screen -> choose an action -> execute it -> read the result -> continue The note covers the primitives behind that loop: - screenshots for observation - ADB-style actions such as tap, swipe, text, keyevent, shell, and install - API-key authentication and public device IDs for target selection - Relay routing so actions reach the correct live device - request IDs for matching screenshot, shell, and file-oriented results - Shell Extension queues for immediate, ordered, and background work - timeouts, output limits, process cleanup, and concurrency boundaries This is the layer we think matters if a real Android device is going to be useful for scripts, QA workflows, and agent experiments instead of just being a remote screen. Full note: https://www.phones-cloud.com/blo... Chinese version: https://www.phones-cloud.cn/blog...
Maker update: Today I wrote a short technical note on one platform capability behind Phones Cloud: multi-device control. Controlling one Android device remotely is only the starting point. A real cloud phone platform also needs to keep many devices online, route each user session to the correct device, isolate control channels, and release stale state after disconnects. The user sees one cloud Android phone. The platform has to maintain device identity, session binding, stream routing, cleanup, and resource delivery across a pool of real Android devices. This matters for the use cases we care about: QA reproduction, support handoff, team access to shared Android environments, and automation systems that need a real mobile execution layer. This is still a technical platform note, not a new feature promise. I am using these updates to explain the infrastructure direction behind Phones Cloud more clearly.
Maker update: Today’s technical note is about resource placement in cloud phone infrastructure. A cloud phone is easy to describe from the user side: open a real Android device from a browser, iPhone, or other client. The platform side is different. Once there are many devices and many sessions, the system has to decide: - which Android devices are online - which devices are available or already occupied - which resource pool has usable capacity - whether the media/control route is acceptable for a live session - whether a finished device can be safely returned to the pool - how to isolate unhealthy devices or resource pools That is why multi-site or multi-region resource capability matters. It is part of turning real Android devices into schedulable cloud resources, not just remote screens. For Phones Cloud, this is the infrastructure direction we want to explain more clearly: device registration, online state, assignment, remote connection, session lifecycle, release, reclaim, and failure isolation all belong to the same platform layer. This is a technical positioning note, not a new feature promise.
We published a technical note on the transport layer behind cloud Android phones. The user sees one remote Android screen, but every tap goes through a full real-time path: input, network, platform control, Android-side execution, screen capture, video encoding, return transport, client decoding, and display. If one part is slow, the phone feels like a video player instead of an interactive device. Phones Cloud publicly describes low-latency transport work plus H.264/H.265 video stream support. We see this as infrastructure, not polish: compatibility across iOS/Web/other clients, bandwidth efficiency, stable playback, and predictable control feedback all matter for QA reproduction, support handoff, shared Android workspaces, and agent-assisted mobile workflows.