feat(android): add ADB over TCP/IP support for remote debugging#258
feat(android): add ADB over TCP/IP support for remote debugging#258mogilevich wants to merge 2 commits intoshamanec:developfrom
Conversation
|
@mogilevich, why do you need a temporary ADB over LAN connection only when using a device? What’s the use case? |
|
@gifflet The use case is remote developers who need to connect a device to their local ADB and debug applications via Android Studio without physical access to the device. ADB over TCP/IP allows them to attach the remote device as if it were plugged in locally, enabling full debugging capabilities (breakpoints, logcat, profiler, etc.) through their IDE. |
|
Sounds reasonable, I haven't checked the code yet though. @mogilevich what are your expectations on the UI side for this? Also I assume (without having checked the code) that this would work only on a local network? @gifflet we could check this out and merge it for a new version after v5.0 release, what do you think? |
DisableAdbTcpIp was unconditionally running `adb usb` which restarts the ADB daemon and kills the H.264 stream. Hub calls this endpoint on every WebSocket disconnect, causing a loop: stream dies → WS closes → disable called → daemon restarts → stream dies again. Now checks `adb get-serialno` first — if the serial doesn't contain ":" (ip:port format), the device is already on USB and we skip.
|
UI: Current implementation is API-only — Network: Correct, works within the same network or over VPN. ADB TCP/IP listens on port 5555 on the device IP. |
|
I have tested and validated that remote debugging is working fine. At the beginning of the tests, I encountered an error when trying to connect to the device (connection reset error), but it is not happening anymore. @shamanec, since we have some open PRs that might be worth merging before releasing v5, such as #261, #263, and shamanec/GADS-hub-ui#25, what do you think about merging these, releasing v5, and then continuing work on this PR and the UI side? |
|
Yep, that makes sense 👌 We might even think about proper remote adb communication sharing over websocket through the hub for example, this would require another |
|
@mogilevich I did some experimenting for this with a separate GADS client cli that authenticates and goes through the hub and it seems to be working fine, I will do a bit more testing and let you know when its ready for testing :D |
Summary
Allow users to connect to Android devices directly via ADB over Wi-Fi while GADS manages the USB connection.
Flow: take device → enable ADB TCP/IP → get
adb connect IP:5555command → work remotely → release device → provider auto-restores USB mode.Changes
POST /device/:udid/adb-tcpip/enable— enables TCP/IP mode on port 5555, returns device IP and connect commandPOST /device/:udid/adb-tcpip/disable— restores USB-only modeadb tcpip/adb usbAdbTcpIpTransitioningflag on device prevents false device resets while ADB daemon is intentionally restartingreconnectStreaminwriteFrames)enableis gated — only works when device is actively in use by the requesting userdisableis gated — only the session owner can disable (or anyone when device is free)