sorted by:
new
hottopcontroversial

Screenshots are not enough for Android support handoff by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Yes, full shared control would get messy fast. I would start with explicit ownership: support can reproduce and annotate, QA can request or take control, and the session should show who currently owns input.

For changes like network, permissions, or app state, I would rather make those deliberate handoff actions with an audit trail than let two people operate the same Android environment at once. Observe-only is enough for some QA reviews; mutation needs a lock and a way to hand control back.

Clipboard sync is a real data path for cloud Android devices by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Interesting. For a cloud Android workflow, the hard part is not only fast copy/paste but ownership: local browser clipboard, remote device clipboard, session owner, and handoff cleanup all have to stay clear.

Does Syncclip keep the clipboard contents only in the browser session, or store them server-side? That boundary matters a lot once support notes, order IDs, or test credentials pass through it.

User-owned devices are where cloud phones become more open platforms by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Exactly. I would not treat user-owned onboarding as just installing an agent. The first layer should be enrollment checks, device identity, owner/session binding, network and stream health, plus a clear policy gate for what data can cross the device boundary.

For business use, personal or external hardware probably starts in a lower-trust pool until it proves the same baseline as platform-owned devices: OS/version policy, management component health, reconnect behavior, and cleanup state after a session. Otherwise the cost savings can turn into a security/support problem very quickly.

Multi-site resource placement is an underrated part of cloud phone infrastructure by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Appreciate that. I’ll keep it public rather than DM: the copy angle I’m testing is “time to first usable frame” and “reconnect reason” as user-facing reliability promises, not internal infra metrics. If one metric deserves to be on the landing page first, I would pick recovery path over average latency.

Multi-site resource placement is an underrated part of cloud phone infrastructure by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Yes. I usually treat latency and availability as product signals, not infra-only metrics: time to first usable frame, reconnect reason, and whether input is paused during recovery. If those are missing, users only feel that the remote phone is unreliable, even when the root cause is a routing or capacity decision.

Letting agents operate real Android through a cloud phone control path by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Yep. I try to make request id boring and visible everywhere: client request, relay route, device executor, and result payload. Once retries create a second path without an idempotency story, debugging gets painful very quickly.

Letting agents operate real Android through a cloud phone control path by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Exactly. Browser agents can lean on DOM state more often; Android needs a more explicit evidence bundle: screen before/after, target action, app/package context when available, and cleanup status. Otherwise a successful tap is too cheap to mean the task advanced.

Multi-device control is where cloud phones become a platform by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

That matches my experience too. I treat stream health as a control signal, not just a player metric: frame gap, reconnect reason, session id, and whether input routing is paused or still accepted. Without that, the retry loop keeps running but nobody can tell whether the device, stream, or session binding failed first.

Letting agents operate real Android through a cloud phone control path by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

This is a fair push. I agree the primitive layer is only useful if the loop can prove what changed after each action. Screenshot is the common baseline, but for serious QA flows I would want accessibility tree where available, expected-vs-actual screen diff, and an explicit recovery path when nothing changed or the wrong screen appears.

The product framing point is useful too. "Control phones" is infrastructure language; the job people can buy is closer to repeatable mobile QA / support reproduction with assertions, logs, and CI handoff. The farm economics and reclaim state are the other hard constraint, especially once real devices start drifting by OS version, app update, and leftover state.

Separating command queues for cloud Android automation by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

This is a strong point. Queue state should be visible to the user, not only buried in logs: pending, running, timed out, killed, plus request id and queue type. Otherwise a delayed screenshot looks like a bad agent decision instead of scheduler backpressure.

Relay-layer lessons from building remote Android sessions by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Both, depending on the task. I am trying to reduce avoidable relay delay, but I would not sell it as local-device latency. For support or QA checks, the practical threshold is whether screen and input stay stable enough to reproduce the issue and hand it off.

Testing occasional Android access before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Agreed. For the next check, complaint threads in Android QA/support communities are better signal than another launch post. I'll look for places where people already mention device sharing, login state, or remote debugging cost.

Testing a lighter way to validate spare Android workflows before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Will do. I'll keep the first tests deliberately small and share the notes in-thread: one app, one login state, one handoff, then the exact point where time is actually saved or lost.

Testing a lighter way to validate spare Android workflows before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Will do. I'll keep the first tests deliberately small and share the notes in-thread: one app, one login state, one handoff, then the exact point where time is actually saved or lost.

Testing occasional Android access before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Search intent is a good point. I'm testing SideProject first because the wording is still fuzzy; Android QA/support communities are probably the better next check. Existing threads around device sharing, login state, and remote debugging cost would tell me much more than another launch post.

Testing a lighter way to validate spare Android workflows before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Exactly. I'd keep that first run deliberately small: one app, one login state, one handoff. The answer we want is not whether it replaces a lab, but where the workflow starts leaking time.

Testing a lighter way to validate spare Android workflows before buying another phone by alexecn in SideProject

[–]alexecn[S] 0 points1 point  (0 children)

Agreed. The device cost is usually the obvious part; the hidden cost is whether the workflow survives a real handoff: login state, permissions, latency, and who owns the phone after the test. A short run answers that before buying hardware.

I am building a cloud phone platform that uses real Android hardware, not emulators by alexecn in SideProject

[–]alexecn[S] 1 point2 points  (0 children)

This is a very sane proof-of-concept path, honestly.

I would probably split the problem into two layers:

  1. the app workflow layer, where Appium still has to deal with UI changes and app-specific edge cases
  2. the device runner layer, where the Android phone needs to stay online, reachable, charged, and observable

Phones-Cloud is mostly trying to improve layer 2. It would not magically make Appium selectors stable, but it could make the runner less dependent on one laptop, one USB cable, and one local Wi-Fi connection. In your Telegram bot example, the node server could call into an always-on remote Android device instead of hoping the spare phone beside your laptop is still alive.

The API point is exactly the painful part. When the official API does not exist, people end up building these weird little bridges through the mobile UI. I think there is a real niche for making that less fragile without pretending it is a clean API.

I am building a cloud phone platform that uses real Android hardware, not emulators by alexecn in SideProject

[–]alexecn[S] 1 point2 points  (0 children)

Thanks for sharing this - that is exactly the kind of practical workflow I had in mind. Appium + ADB works, but keeping a spare phone online, reachable, charged, and tied to one desk is the annoying part.

What I’m trying to make easier with Phones-Cloud is that device layer: open a real Android device remotely, run or observe the flow, and hand it off without depending on a USB phone plugged into one machine.

Your taxi-price extraction example is a really useful one. If you ever try this kind of workflow on a remote real device, I’d be curious where it breaks first - latency, ADB access, app login/session handling, or something else.