Android development on Linux - How to have ADB recognize your device


While developing in Android, I've found that sometimes ADB doesn't recognize your device (specially if it's a chinese phone/tablet). In some cases this is plain frustrating. I will try to make a comprehensive list of all possible situations I've found where ADB doesn't recognize your device, and hopefully show you how to trace the problem, why it happens and how to solve it. Note that after each of the following points I suggest you unplug and plug the USB cable and try adb devices command to see if the step solved the problem.

  1. USB port and cable: use another USB device and cable to plug for example a pendrive, to make sure the device is recognized. If not, then it's a hardware problem (either the port is broken or the cable is).

  2. USB debugging is ON: check your Android device settings and make sure USB debugging is ON. This might sound stupid, but a lot of times it's just this simple. In old Android versions there's directly an entry for this in the Settings menu, but in newer versions it is hidden. Following instructions are for Android 4.4.4, but should be very similar for any other Android version. You have to go to About phone and click several times on the Build number. After some clicks you will see an on-screen text (a toast in Android parlance) that informs you that you enabled this option. Now go back to Settings, there should be a new menu entry named Developer options. Enter this setting and scroll until you see an Android debugging option. Activate it (check this link for a more detailed description).

  3. Restart adb server: try restarting adb server with adb kill-server; adb start-server and check again.

  4. Reboot device: sometimes the adb daemon on the device crashes or freezes. Since if this happens we cannot access it, a reboot will solve this problem.

  5. List USB devices: see if the devices shows as attached in USB using lsusb. They usually show like this

    Bus 001 Device 004: ID 18d1:dddd Google Inc.

    If it doesn't show, then it's likely that the USB port and/or cable are not working properly, or, as I found once, you have MTP selected in the USB connection settings of the phone/tablets. Some strange tablets I worked with had this strange problem. Switching to Mass Storage solved this problem.

  6. udev: add your vendor ID to /etc/udev/rules.d/51-android.rules (you need root permissions for this). You can see the vendor ID on the lsusb command result. For example, if lsusb shows Bus 001 Device 004: ID 18d1:dddd Google Inc., the vendor ID is 18d1. In this case you need to add this line to the file

    SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", MODE="0666"


    (of course substitute 18d1 with your actual vendor ID). I suggest you first make sure this doesn't already exist. After modifying the file (remember you need root permissions to do so), you need to restart the udev service with sudo service udev restart.

  7. ADB TCP: check if ADB TCP works. Download the Wifi ADB app that allows you to set adbd on TCP mode (note that if TCP and USB modes are mutually exclusive). Now check you device IP address on the device Wifi settings and connect to it from the PC with adb tcpip . For example, if the IP address is 192.168.1.10, then you should run adb tcpip 192.168.1.10. If it connects, then the adbd on the device is working properly. If not, there's likely a problem with ADB on the device side.

  8. ndiswrapper: I only had this problem once, but it was a pain to figure it out. Ubuntu decided by itself that the Android tablet on debug mode needed a Windows driver, and it ran it through ndiswrapper. Of course this didn't work. To check if this is your problem, unnplug the USB cable and plug it again, then run dmesg | grep -i ndiswrapper, it should show something like

    [277701.952803] ndiswrapper (load_wrap_driver:103): couldn't load driver android_winusb; check system log for messages from 'loadndisdriver'

    If so, uninstalling ndiswrapper solved the problem for me. Removing the kernel module should also solve the problem.

  9. Kernel log: if everything above fails to solve the problem, you can check dmesg logs and figure out what's happening. You can post your problem on the comments here and maybe we can solve it with everyone's help!

Comments

Popular Posts