I was connected to my Android device's shell (by doing adb shell in my computer's shell) and without realizing, I typed adb devices. Instead of giving me a command not found error or something, it actually listed one device! The output:
$ adb devices
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
List of devices attached
emulator-5554 offline
Why does my phone have an adb command, and what is the emulator device?
EDIT: I tried it again and it still works, though now the list of devices it gives is empty. The only difference between when I did it just now and when I did it before is that before, I was doing the bridge wirelessly and now I'm doing it through a wired connection. I know that it's not running the adb command on my computer, because in both cases when I run it on my computer I get a different output.
Some phones do include the adb binary. Some for a specific purpose, others just because the manufacturer was too lazy to edit the default makefile.
Also adb devices listing an offline instance of an "emulator" does not mean that there's an emulator running on the device, just that there is an open tcp port in the range that adb scans when looking for emulator instances. Just ignore it.
Don't worry about emulator.Emulator creates a virtual android device. By using this facility a programmer can test his code on computer without connecting any device.
You can read about emulator from https://developer.android.com/training/basics/firstapp/running-app.html#Emulator.
A whole line of tablets don't show at ADB devices anymore (they worked just fine one week ago). Other Android devices do work (like my Nexus 5 phone). This is first time I face this problem. I've read and tried most solutions I've found at SO and other sites to no avail. Here's the situation:
They show in lsusb as Bus 010 Device 004: ID 18d1:dddd Google Inc..
Created/edited /etc/udev/rules.d/51-android.rules and added SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", MODE="0666" (and several other attribute combinations here).
Restarted udev via sudo service udev restart.
Restarted ADB server via adb kill-server; adb start-server`.
Tried all USB ports on PC.
Tried another USB cable.
Restarted PC and tablet.
A strange thing is that even if I empty /etc/udev/rules.d/51-android.rules file and restart the udev daemon, adb still detects my Nexus 5 phone.
Changes I remember I did before this problem started to happen:
Started using Android Studio instead of Eclipse (although I'm using the same ADK) and tools)
Upgraded Ubuntu to latest version 14.04 (maybe some udev changes/problem here?)
Any further suggestions are welcome, thanks in advance.
EDIT: When running lsusb -v as suggested in the comments, I can see this description:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 1 Mass Storage
while the Nexus 5 shows as
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 4 MTP
EDIT: The tablets are working perfectly through ADB in other computers (Windows and Linux). So it must be a problem with my box.
EDIT: As suggested in the comments, I tried ADB in TCP mode and works fine. After running dmesg I can see the system is trying to load the Windows driver for ADB using ndiswrapper
[277701.803751] usb 1-4: reset high-speed USB device number 48 using ehci-pci
[277701.952803] ndiswrapper (load_wrap_driver:103): couldn't load driver android_winusb; check system log for messages from 'loadndisdriver'
This message doesn't show on the other Linux boxes where ADB works fine through USB.
Since the same devices work on other PCs, you can already rule out hardware issues on the tablets' side. Further things to check are:
USB permissions on the PC: Though other devices work, you might still have insufficient permissions to access the tablets using adb. The udev rules you've mentioned are vendor-specific, and sometimes also device-specific. The only way to rule permissions out as a problem is to start adb as the root user. adb forks a daemon, so you've got to kill any instances of adb before attempting to do that:$ pkill adb$ sudo adb devicesIf the device does show up in the list, you've got to adjust the udev rules. Temporarily, you can continue to use adb normally - it will connect to the service that is now running as root and therefore working as expected.
Driver issues: In the developer menu on your tablet, you can select "adb over tcp" as an option. Enable it and then connect to it from your PC. If this works, the debug bridge itself is fine and the USB connection must therefore be the source of the issue. We can already rule out a defective cable, because the device does show up in lsusb and other functionality works as expected. Running dmesg should give you the required information to solve your problem, likely it's an interfering device driver. Try unloading it using rmmod/modprobe.
A difference since 12.10+ is MTP support. I know 14.04 uses it automatically as soon as a phone is plugged in. This is supposed to be a faster and more simpler than "Mass Storage". Perhaps it's getting in your way and you should find a way to disable it either from the PC end or on the device?
I just did a factory data restore so that I could use my phone for testing.
But now I am trying to use the adb tool to put a new .apk on the device using my usb, and it says device not connected.
The phone is displaying this message: MTP: server status: connecting to computer...
But it is never able to fully connect.
I tried to go to Wireless & Networks, and enable Internet pass-through, but that option is also "Turning on..." for the last 5 minutes.
Any idea why I am not able to connect?
What kind of device is it? Make sure you have the development USB settings set under Settings, Development. Also ensure it's not a USB Drive but in USB Debugging mode.
Furthermore, if it's a device driver issue, here is an article for the HTC Thunderbolt and Windows/Eclipse:
http://www.nodans.com/index.cfm/2012/2/1/Getting-USB-Device-Drivers-Working-for-HTC-Android-Development
For OSX, Motorola has a USB Link DMG, I'm not sure about HTC though.
Maybe you show give us more information, like
What OS are you using (Windows, Mac, Ubuntu)
Is USB debugging switched on?
Did you restart the adb server
$ adb kill-server
$ sudo adb start-server
* daemon not running. starting it now *
* daemon started successfully *
$ adb devices
I have a zenithink zt-180 tablet connected to my usb port. I can use adb (from the command line) to get a shell command, reboot the tablet, and stuff like that, though I do have to kill and start the server first on the initial connect.
I can also run ddms and it shows me the device threads and statistics and so forth for the tablet.
However, whenever I try to load the helloAndroid example adb and ddms hang. To recover I have to cntr-C out of them, kill the server and then start the server. I can then do the above stated operations, just not load. In Eclips I get an error saying "failed to install HelloAndroid on device 0123456.... : timeout when i try to debug on the device.
I know the application can run because I loaded it onto a USB stick and installed it on the tablet. It ran fine.
What is it about the load program command that is hanging up adb???
Note: USB debugging is enabled in the device. I make sure that only one DDMS and adb are running. All eclips components and the USB driver were loaded two days ago. The tablet is running android 2.1.1
So I did not really fix this but I did find a work around and it's better then USB cable.
Connect to the tablet via the USB cable and issue the adb command "adb tcpip 5555". This command executed and did not crash my adb server. This is key.
Next use the connect command to connect via tcpip.
adb connect :5555
I had firmware 1030 on the ZT-180. Note: I did not have to install adbwireless and I did not have to root it.
credit to the person who came up with these directions: http://www.slatedroid.com/index.php?topic=4316.0
Thanks to all who tried to help
I have had this same effect from a defective USB cable. adb connected just fine, got the prompt on the phone to trust the computer, the device showed up as online when listing adb devices, but any attempt at install whether from the IDE or from the command line caused adb to just hang. Try a different cable.
Is it possible to write the code/compile Android application on one machine and debug it remotely on the emulator launched on another? I'm sick and tired of the emulator constantly eating half of my laptop's CPU.
I haven't previously tried (or even noticed) the adb connect command that cmb mentioned, but I can confirm that forwarding the TCP ports yourself — such as over SSH — works fine.
The emulator listens on two TCP ports per instance: 5554 for the telnet interface and 5555 for control communication with tools like DDMS. So you could probably get away with only forwarding port 5555 (though I've only tried it so far with both). Each subsequent emulator takes the next available even+odd port number tuple (up to around 5580, I think).
For reference, I did the following steps on my local machine:
ssh -NL 5554:localhost:5554 -L 5555:localhost:5555 myuser#remote-server
killall adb; adb devices
I believe the emulator tries to notify a local adb server at startup; hence the need to restart adb in order for it to probe the local 5554+ ports.
Note that the localhost in the ssh command refers to the local interface of the remote machine.
adb devices showed a new emulator — emulator-5554 — and I could use it as if it were running on my local machine.
I realize this question is really old, but I solved the problem slightly differently, and it took me a while to figure out this trivial solution.
I usually use a Windows7 PC or laptop (depending on where I'm working) as my front-end because I like the GUI, however I prefer to do all of my edit/compile/debug on a headless Ubuntu server because of all the command-line power it provides. My goal is to make each windows system as much of a thin-client as possible without any extra services (such as sshd) or firewall holes.
So here is the senario:
System-A: Windows7 system with android emulator running
System-B: Ubuntu server with SDK installed
The problem as described earlier is that the emulator on System-A binds to localhost, not the external ethernet interface, so adb on the System-B cannot access the emulator on System-A. All you need to do is set up remote port forwarding in PuTTY for your SSH connection to System-B. The trick is to check the "Remote" radio button when you create the two tunnels so that the tunnel direction is reversed (tunneling from the server you are logging into to the client you are logging in from).
Finally, connect with adb to "localhost" on System-B after establishing the SSH connection:
System-B$ adb connect localhost
connected to localhost:5555
System-B$ adb devices
List of devices attached
localhost:5555 device
Now you can download images/debug as normal, and it is a trivial matter to switch to a different Windows system if you want to take your laptop out and get some coffee.
In addition, by also tunneling port 5037 in the same manner you can actually forward your adb server connection so that you can connect a real android device over USB on System-A, and download images to it from System-B. In order for this to work, you need to make sure that the adb server is running on System-A, and not running on System-B before starting your SSH session:
First, start the adb server on System-A (command prompt)
C:\> adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
C:\> adb devices
List of devices attached
3435F6E6035B00EC device
Next, kill the adb server on System-B
System-B$ adb kill-server
Finally, restart your ssh session to System-B and verify
System-B$ adb devices
List of devices attached
3435F6E6035B00EC device
Here is how I solved it on Windows. I pretty much followed Christopher's lead, but I can't edit, so a new answer will have to do.
The problem I had was that ADB as well as the emulator was just listening on 127.0.0.1, not 0.0.0.0, for me. Otherwise I would have used TCPMon. I guess this is either different on Windows, or has changed with the latest versions of the SDK. (You can check with netstat -ban.)
I installed WinSSHD on the machine that runs the emulator. (I believe it should work with freeSSHd as well, but I couldn't get a login working there.)
I opened port 22 (TCP) in the Windows Firewall. (WinSSHD might be able to do that for you.)
I created a virtual account in the WinSSHD GUI.
I created a new PuTTY connection from the development machine to the emulator machine and made sure I could connect.
Then I set up tunnelling in PuTTY: Connection -> SSH -> Tunnels
Source port: 5554
Destination: localhost:5554
Type: Local/Auto
Source port: 5555
Destination: localhost:5555
Type: Local/Auto
(Connect and keep PuTTY open, to maintain the tunnel.)
Now I fired up the emulator on the remote machine and made sure that ADB is not running there.
I restarted ADB on the development machine (adb kill-server, then adb start-server).
adb devices and the remote emulator showed up as emulator-5554 device. I could now deploy and run my app straight from Eclipse/ADT, where the emulator showed up under Virtual Devices as if it was a local emulator.
I found an easy way to do this if your two machines are in the same private network and therefore do not need to use SSH encryption (which is the common case). This may help as an SSH tunnel can be quite long and difficult to install. For example, installing an SSH daemon under Cygwin / Windows for the first time may lead to give up (well, I gave up).
Under Windows, what follows requires having Cygwin installed with the package httptunnel. This must work under Linux / httptunnel as well but I didn't try.
Run the emulator on one of the machines (let's say its host name is HostEmulator)
Start Eclipse on the other machine (let's call it HostEclipse)
Open a Cygwin terminal on each machine, and then,
On HostEmulator, enter the following cygwin commands:
hts -F localhost:5554 10000
hts -F localhost:5555 10001
hts means Http Tunnel Server.
These two commands create two half-bridge that listen to the ports 10001 and 10001 and that redirect the I/O of these ports to the local ports 5554 and 5555, which are the ports used by the emulator (actually, the first lauched emulator - if you are several of them running they will use higher port numbers as seen in other replies of this page).
On HostEclipse, enter these ones:
htc -F 5554 HostEmulator:10000
htc -F 5555 HostEmulator:10001
htc means Http Tunnel Client.
These commands create the missing half-bridges. They listen to the local ports 5554 and 5555 and redirects the I/O of these ports to the half-bridges we have created on HostEmulator just before.
Then, still on HostEclipse, enter these three commands:
adb kill-server
adb start-server
adb devices
This restarts adb as it doesn't detect the remote emulator otherwise. It must be doing some scanning at startup. And then it lists the devices (the available emulators) just for checking.
And there you go.
You can work with your remote emulator as if it was local.
You have to keep the Cygwin terminals open on both machine otherwise you would kill the half bridges you created.
I used the port 10000 and 10001 for the machine/machine exchanges here, but of course you can use other ports as long as they are not already in use.
None of the proposed solutions worked for me.
I've started from Emirikol's solution and refined it, as with the new Android API > 21 the emulator was appearing offline and I had to go to Genymotion settings and leave Android SDK path empty.
And from command line:
netsh interface portproxy add v4tov4 listenport=5555 connectport=5555 connectaddress=<emulatorIP>
netsh interface portproxy add v4tov4 listenport=5554 connectport=5554 connectaddress=<emulatorIP>
source:http://www.sarpex.co.uk/index.php/2016/10/02/connect-genymotion-emulator-remotely/
Disclaimer, I'm the author.
When you run adb, it starts a server copy of itself if one isn't already running.
You can start that copy yourself on the machine with the device and since sdk 4.3 you can give it the -a option to tell that server to listen for remote machines. Do that with the following command which doesn't exit:
adb -a -P 5037 server nodaemon
On the machine you want to use the device from, set ADB_SERVER_SOCKET to tcp:xxxx:5037 in an environment variable (or give the same value to each adb invocation with the -L option), where xxxx is the IP address or hostname of the machine with the devices, and 5037 matches the port you gave the in the command above.
We use this to give access to about 100 emulators spread over 3 machines to a machine running end to end tests in parallel, and to developers wanting to share real devices remotely.
You can forward ports to and from the emulator with adb forward and adb reverse, and they'll appear on the machine with the devices (not the machine you're running 'adb forward' from).
My solution for windows + AndroVM (which requires a host-only adapter) when my ssh service failed to start. so it doesn't require any additional software.
adb connect <Andro VM IP>
adp tcpip 555
On cmd prompt run as admin:
netsh interface portproxy add v4tov4 listenport=5555 listenaddress=<host ip> connectport=5555 connectaddress=<Andro VM IP>
open TCP port 5555 in windows firewall.
Then, from the second PC run:
adb connect <host ip>
This post contains many answers but step by step instructions are missing.
So this answer will explain how to connect 2 computers to run projects of one computer on the emulators of another computer.
Requirements before going further:
Firewall should be off in both the PCs.
Both PCs must be connected in the same network.
Notes:
Computer running Android Studio is mentioned as "PC_AS"
Computer running Emulator is mentioned as "PC_EM"
Step 1:
On the computer running Android Studio, open a terminal window and run following command.
ssh -NL 5554:localhost:5554 -L 5555:localhost:5555 dhaval#192.168.0.104
Above command will forward 5554 and 5555 ports of PC_AS to the same ports on PC_EM. So the emulators running on PC_EM can be detected on the PC_AS.
dhaval#192.168.0.104 is the address of the PC_EM. Format of the address is username#local_ip_address
Once you run above command, the terminal window will not show anything if the command is executed successfully. It will look like nothing is going on but the process is running there.
| 💡 Note: Do not close this terminal until you want to stop remote debugging.
Step 2:
Now open another terminal window on PC_AS and run following commands one by one.
killall adb;adb devices
This command will stop the adb and stop the server.
adb start-server
This command will start the adb server.
adb devices
This command will list down all the connected adb devices.
Once you run above commands, you will see that emulators of PC_EM are now detected in the PC_AS. Now you can run the projects on those emulators and debug remotely.
| 💡 Note: While doing the above process, emulators can show a dialog to trust the incoming request.
Android emulators by default listens on local port 5555, so one way to connect to a remote emulator is by using a port forwarding tool to forward all LAN packets to local 5555 port.
One such excellent tool is Trivial Port Forward
Here is the command:
trivial_portforward.exe 1234 127.0.0.1 5555
Here 1234 is the port number where the development computer will connect. 127.0.0.1 is loopback address and 5555 is the emulator’s port.
For more detailed example, see my blog post.
This is how I made it work from host macOS with emulator to macOS client.
A: One line command
On host of emulator
socat tcp-l:5560 tcp:localhost:5559
On client
adb connect <IP>:5560
B: With a tunnel
on host with Emulator
host$ adb kill-server
host$ adb -a nodaemon server
on client with Android Studio
client$ adb kill-server
client$ ssh -L 5037:localhost:5037 <host-IP>
open second shell on client with Android Studio
client$ adb kill-server # I observe first it kills client adb
client$ adb kill-server # then it kills server adb, do it maybe once more
client$ adb devices # show devices on server now
Now I see host emulator in Android Studio as well
I don't have a second machine with the SDK to hand, but I note that the emulator's listen ports (default 5554, 5555) are listening on 0.0.0.0, i.e. reachable from remote machines, and that adb --help shows a connect <host>:<port> command. I assume that would make it show up in adb devices so adb commands work on it. For Eclipse, try "Run / Run Configurations..." and set the Target to Manual. That gives you a "device chooser" which I'm guessing would include a remote emulator if adb is connected to it. Worth a try.