From the adb
wiki tag :
Android Debug Bridge (adb) is a universal command line tool that allows you to communicate with an emulator instance or a connected device running Android -P. This is a client-server program, which includes three components:
- A client that runs on your development machine. You can call the client from the shell by issuing the adb command. Other Android tools, such as the ADT plugin and DDMS, are also created by adb clients.
- A server that runs as a background process on your developer's computer. The server manages the communication between the client and the adb daemon running on the emulator or device.
- A daemon that runs as a background process on each instance of an emulator or device.
The adb connect
command is used to connect the local adb
server to the adbd
daemon on a device connected to the network. But you need to connect the local adb
client to the remote (running on another system) adb
server. The default behavior of the adb
executable is to connect to a local adb
server instance. If no one finds, he will try to start one. This approach works great for most environments where all development runs on a single system. But in more complex environments, this can lead to several cases where the adb
server starts. And since the adbd
daemon supports simultaneous connection to only one adb
server, the device is recognized by one system and will be absent everywhere.
So that adb
can reliably recognize devices in these more complex configurations, you must tell adb
to stop guessing and manually specify which part of adb
(i.e. the server or client) should work on which system.
First of all, make sure that you have the same and fairly recent version of adb
installed (the latest official version of Google usually works best), installed on both local and remote systems. And that not one adb
system currently works
Then start the adb server
instance on the remote system (the one to which you will connect the devices) with this command:
adb -a -P <PORT_NUMBER> nodaemon server
Now you can force the adb
client on the local system to use a different (remote) server instead of starting its own (local) instance by adding -H <REMOTE_IP> -P <PORT_NUMBER>
to your adb
commands:
adb -H <REMOTE_IP> -P <PORT_NUMBER> devices
Alternatively, setting ANDROID_ADB_SERVER_ADDRESS=<REMOTE_IP>
and ANDROID_ADB_SERVER_PORT=<PORT_NUMBER>
client-side environment variables allows you to avoid having to specify <REMOTE_IP>
and <PORT_NUMBER>
for each adb
command.
And if omitted, <PORT_NUMBER>
will default to 5037
.
This official built-in adb
orchestration solution is not a mutually exclusive alternative to SSH tunneling - it just solves another more important issue. In addition to this, you can add tunneling to increase security or help with routing problems in a multi-site network environment. But only tunneling will not be able to solve all problems with adb
connection.
The same goes for virtualized environments - running multiple instances of adb server
between the host system and the guest system will also lead to problems with adb
connection.