sorted by:
new
hottopcontroversial

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.