Phones Cloud - A real cloud Android work phone for teams
by•
Give remote teams controlled access to a real cloud Android device for handoffs, support troubleshooting, and QA workflows without shipping physical phones.
Replies
Best
Hunter
📌
Hi Product Hunt,
We built Phones Cloud for teams whose mobile workflows still depend on one physical Android phone.
That phone becomes a bottleneck when a teammate works remotely, takes leave, changes roles, or needs to hand a workflow to someone else.
Phones Cloud gives teams controlled access to a real cloud Android device for:
- remote handoffs
- outsourced operations
- customer support troubleshooting
- QA reproduction for Android-only issues
- shared mobile workflows that should not live on personal devices
What it is not:
- not an emulator
- not an automation platform
- not built for policy-evading multi-account use
- not a promise that every third-party app will work
We are looking for feedback on trust, permissions, compatibility, onboarding, and pricing.
If your team still ships physical phones for mobile workflows, we would love to hear how you handle handoffs today.
Report
Hunter
Small maker update for Phones-Cloud: We are focusing the product around real Android devices as remote workspaces, not emulator-style virtual phones. The use cases we care most about right now are: - reproducing mobile app issues on real Android hardware - handing a device session from support to QA or engineering - checking workflows that are awkward to verify on an emulator - separating mobile accounts without carrying multiple phones - giving AI testing agents a real device environment to execute steps The website for the English launch is: https://www.phones-cloud.com/ I would love feedback from Android developers, QA teams, support teams, and anyone who has had to manage a stack of test phones.
Report
Hunter
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.
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
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...
Report
Hunter
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.
Report
Hunter
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.
Report
Hunter
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.
Report
Hunter
Maker update: Today’s technical note is about device allocation and reclaim in cloud phone infrastructure. A cloud phone looks simple from the user side: open a real Android device from iPhone, Web, or another client. The platform side has a different job. Each Android device needs a lifecycle: - registered - online - idle - assigned - in session - ready to release - reclaimed - available again If every device has to be manually selected, cleaned, handed off, and returned to the pool, the service becomes hard to scale. That is why assignment and reclaim are control-plane capabilities. The platform needs to know which devices are online, which are actually usable, which user owns a session, when a device should be released, and whether it is safe to return that device to the pool. For Phones Cloud, this is part of the infrastructure direction we want to explain more clearly: real Android devices should behave like schedulable cloud resources, not isolated remote screens. This is a technical positioning note, not a new feature promise.
Report
Hunter
Maker update: Today’s technical note is about clipboard sync in a cloud Android workflow. It sounds small, but it changes how useful a remote device feels. Streaming lets you see Android. Touch input lets you control it. Clipboard sync lets short text move between your local machine, iPhone, and the cloud phone. That matters for support replies, QA notes, links, order IDs, test accounts, and script-generated text that still needs to enter a real Android app. We treat clipboard sync as part of the device data path, alongside video, audio, control messages, and session management.
Replies
Small maker update for Phones-Cloud: We are focusing the product around real Android devices as remote workspaces, not emulator-style virtual phones. The use cases we care most about right now are: - reproducing mobile app issues on real Android hardware - handing a device session from support to QA or engineering - checking workflows that are awkward to verify on an emulator - separating mobile accounts without carrying multiple phones - giving AI testing agents a real device environment to execute steps The website for the English launch is: https://www.phones-cloud.com/ I would love feedback from Android developers, QA teams, support teams, and anyone who has had to manage a stack of test 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.
Maker update: Today’s technical note is about device allocation and reclaim in cloud phone infrastructure. A cloud phone looks simple from the user side: open a real Android device from iPhone, Web, or another client. The platform side has a different job. Each Android device needs a lifecycle: - registered - online - idle - assigned - in session - ready to release - reclaimed - available again If every device has to be manually selected, cleaned, handed off, and returned to the pool, the service becomes hard to scale. That is why assignment and reclaim are control-plane capabilities. The platform needs to know which devices are online, which are actually usable, which user owns a session, when a device should be released, and whether it is safe to return that device to the pool. For Phones Cloud, this is part of the infrastructure direction we want to explain more clearly: real Android devices should behave like schedulable cloud resources, not isolated remote screens. This is a technical positioning note, not a new feature promise.
Maker update: Today’s technical note is about clipboard sync in a cloud Android workflow. It sounds small, but it changes how useful a remote device feels. Streaming lets you see Android. Touch input lets you control it. Clipboard sync lets short text move between your local machine, iPhone, and the cloud phone. That matters for support replies, QA notes, links, order IDs, test accounts, and script-generated text that still needs to enter a real Android app. We treat clipboard sync as part of the device data path, alongside video, audio, control messages, and session management.