How to do ADB over 'wifi' (actually in the same PC) for emulated device

Question

I'm trying to use adb over 'wifi' for my emulated device. I'm emulating a device on my computer and wanted to use Android Studio to send an APK to it but through the network sockets, not through emulated USB. I know in Android Studio everything works out of the box but I need to it in this way

I'm following this tutorial: https://developer.android.com/studio/command-line/adb.html#wireless

I start it with

~/Android/Sdk/emulator$ ./emulator -avd Pixel_XL_API_27

Then I see that USB debugging is on. I then do

./adb tcpip 5555

restarting in TCP mode port: 5555

Note that ./adb tcpip 5555 is arbitrary. I didn't even specify which device should restart and connect at 5555. What if I had 2 emulators running?

I should unplug now for a normal USB device, but then I go to developer options in my emulated phone and disable USB debugging.

I also see that the IP address in the emulated phone system settings is 192.168.232.2

then I end up with:

./adb connect 192.168.232.2

unable to connect to 192.168.232.2:5555: Connection timed out

I also done this:

./adb devices 

List of devices attached

emulator-5554
device



./adb connect 192.168.232.2:5554

unable to connect to 192.168.232.2:5554: Connection timed out

UPDATE:

According to Android Tutorial on ADB, my computer keeps a server running on port 5037. The Android device (my emulator in this case) runs a daemon and my adb script in Sdk/platform-tools is a client. If I want to run a client inside my virtual machine I must have a server running on it. But instead I can just forward the 5037 TCP port from the VM to the 5037 TCP port of the host machine. I did it with tcptunnel by doing the following:

./tcptunnel --local-port=5037 --remote-host=192.168.122.1 --remote-port=5037 --stay-alive

then if I run adb on my VM, it's going to connect to the adb daemon on my host machine which is going to talk with the adb server of my emulator. When I run adb devices in the VM without the tcp forward it tries to start a new server. If I kill this server and open th tcpforwarded and do it again, it doesn't try to create a new server. This is a good signal. However, tcptunnel gives me this:

build_tunnel: connect(): Connection refused

Something is blocking the connection

UPDATE 2:

Turns out tcptunnel isn't necessary, because adb has the H option that lets me specify the IP where the server runs. However I don't know if it's possible in Android Studio to specify it. Anyways:

./adb -H 192.168.122.1 devices

List of devices attached

* cannot start server on remote host

error: cannot connect to daemon at tcp:192.168.122.1:5037: Connection refused

— Guerlando OCs | Sources

Answer

I forgot that adb daemon binds to localhost, and I was trying to access from 192.168.122.x.

With socat I was able to redirect the ADB client from my VM to the ADB daemon on my host machine which made connection with the ADB server (my emulated phone).

My host machine was reachable at 192.168.122.1 from the virtual machine, but the adb daemon was binding to 127.0.0.1 or localhost. I just did:

#on host machine:

socat tcp-listen:5037,bind=192.168.122.1,reuseaddr,fork tcp:localhost:5037



#on virtual machine:

socat tcp-listen:5037,bind=localhost,reuseaddr,fork tcp:192.168.122.1:5037

Make sure you kill the adb server on the virtual machine doing /path/to/android/sdk/platform-tools/adb kill-server. ADB server always tries to bind on 5037 if there's nothing there, so if socat is already running on both sides and the adb server is running on the host machie, when you launch android studio on the VM, it'll automatically connect to the outside adb server, which will connect to your emulated phone.

You don't need Android Studio on the virtual machine to test. You can just do /path/to/android/sdk/platform-tools/adb devices on the virtual machine to see if socat will redirect it to the adb daemon on host, which will list the emulated phone.

— Guerlando OCs | Sources

How to do ADB over 'wifi' (actually in the same PC) for emulated device

Topics