Is it possible to list connected devices in a server?

[dev-stupid-codes]

I've got a use case where I need to let remote software developers access and control Android devices connected to a Ubuntu server.

These devices are POS machines and we're not able to reproduce their environment in a simulator. We do need to have them connected through ADB so we can properly debug the app.

Would it be possible to detect, list and connect devices and let everyone control them, using ya-webadb?

• can you give me some guidance so I know where to start from?
• maybe software alternatives?

@yume-chan

[yume-chan]

It depends on what you want the client to be able to do. If you expect the client to deploy and debug Apps from Android Studio, that's nearly impossible. If all features on the client side are developed by yourself, running in a Web browser (for example uploading an APK to install and control the device using Scrcpy Web client), although the code here can't do that, it's totally possible. Here are three methods you can connect to your devices over Internet.

1. The simplest method is to forward all data from/to devices over a Web-friendly protocol, and let the core library runs at the client side to handle them. It's very easy to create custom transportation adapters for it. The adapter doesn't need to understand ADB protocol, it only forwards all data it received between core and device.

   For example, nwtgck/piping-adb-web forwards ADB over WiFi TCP sockets with their own general-propose proxy protocol over HTTP. It even doesn't require connecting devices to a computer, the end for the device runs directly on it.

   For USB connected devices, you can use C and libusb library to enumerate and communicate with them, some wrappers for other languages also exists, including usb package for Node.js. It's a bit more complex than ADB over WiFi solutions, as it needs to find the USB endpoints for ADB, and send/receive packets to them, like what the WebUSB backend does (again, it doesn't need to parse or serialize ADB packets, only forwarding them).

   The downside of forwarding data blindly is that only one client can connect to a device at a time. A new connection (authentication process) will break previous connections. So a system to manage connections is also required.

2. The second method is to run the core library on your server, uses varies backends to connect to devices, and expose each feature via custom API endpoints. The WebUSB backend can run on Node.js using the usb package (the necessary code haven't been released to NPM), or a TCP backend using Node.js net module can be easily created to connect devices wirelessly. This method allows multiple clients to access one device concurrently, but requires much more custom development.

The above two methods have one same issue: they must connect to devices directly, in another word, no native ADB is running.

The ADB daemon on device can only accept one connection at a time (as discussed above), so native ADB has a server (running on the computer, started by the first client) that manages connections. Each ADB command you type in terminals spawns a ADB client. It connects to the server using TCP socket, and let the server forwards the real request to device. The protocol between client and server is slightly different from server to daemon, and is not supported by this library, so this library can't be used when native ADB is running.

So the third method is to implement this protocol between client and server using Node.js net module, again as a backend, after that it's mostly same as method 2.

Back to the beginning, if you want to let clients deploy and debug Apps from Android Studio, or use native Scrcpy client to mirror the screen and control the device, you need to forward the ADB server socket to client machine. The most commonly used method is SSH tunnel. With this method the ADB clients on client machines just works automatically.

[dev-stupid-codes]

thank you so much