38

I just got my shiny new Wileyfox Swift – and before putting it to use I want to oem unlock and root it (as I usually do with new devices ;) Trouble is, though is enabled on the device, and a corresponding line in /etc/udev/rules.d/51-android.rules exists, the device is not seen by adb devices.

I know there are several answers scattered around this site, but they are either hard to find, just cover a specific device, or don't cover all steps I finally needed. So I take this as a chance for a canonical, device-independent question and give it a detailed answer below:

How can I get my Android device seen and used by adb on Linux?

Izzy
  • 91,166
  • 73
  • 343
  • 943

3 Answers3

50

Enable USB debugging on the device

This is done in Settings › Development. If you don't have that entry in your settings menu, go to Settings › About, scroll to the "Build number", and hammer it like a monkey until your device congratulates you having become a developer. Go back to the main page of the Settings menu, and close to the bottom you should see the "Development" (or "Developers") settings now. Enter it, and enable USB Debugging here.

Identify the device

First we need to know how the device identifies on the USB bus. For that, with the Android device NOT connected, grab a shell and run the command lsusb. Then connect the device and run the command again. Spot the new line. For the Wileyfox Swift this is a "nameless device":

Bus 004 Device 003: ID 2970:2282

Setting up the rules for ADB

We now need the numbers at the end of the above line: 2970:2282. These specify the vendor (2970) and the device itself (2282). Having those details, we need a root shell on our Linux machine to edit (or create, if it doesn't yet exist) the /etc/udev/rules.d/51-android.rules file. In there, add a line for your device. Following example line shows how it looks for the Wileyfox Swift:¹

SUBSYSTEMS=="usb", ATTRS{idVendor}=="2970", ATTRS{idProduct}=="2282", MODE="0666", GROUP="androiddev", SYMLINK+="android%n"

If you have a different device, replace the vendor and product IDs with what you've found above when running lsusb. A short explanation of the line:

  • SUBSYSTEMS=="usb": obviously this rule is for USB only ;)
  • ATTRS{idVendor}=="2970": the vendor ID of the device this rule is for
  • ATTRS{idProduct}=="2282": the device ID
  • MODE="0666": permissions the device node shall get. 0666 is quite lax, giving every user on your system read and write permission – so if you're concerned, you might try replacing that with a 0660 (giving only owner and group read-write, and deny everything to others).
  • GROUP="androiddev": which group the device node should belong to. This should be a group the users intended to work with the device belong to.
  • SYMLINK+="android%n": just to give the node a nice name, so you can find it easier in /dev (in my case, it later showed up there as /dev/android5)

That rule entered in /etc/udev/rules.d/51-android.rules, we must tell udev to make use of it. Safest way (next to a reboot ;) is restarting the udev service. Depending on your Linux distro, this can be done either via sudo service udev restart or sudo /etc/init.d/udev restart.

Done that, leave the root shell. Disconnect and reconnect your Android device, try adb devices again. Most devices showed up now, but not the Wileyfox Swift – which obviously wants some extra cuddles. If you're in that situation, open (or create if it doesn't exist) the file ~/.android/adb_usb.ini and add a single line to it, naming the vendor you've found out with lsusb above; for the Swift that would be 0x2970 (yupp, here you need to prefix it by 0x to point out it's a hexadecimal number). Then restart the ADB server: adb kill-server && adb start-server. Disconnect and reconnect the device again. Now adb devices should see it.

Connecting the device

You might have noticed adb devices told you something like 0123456789ABCDEF unauthorized. That's OK and for your (devices) safety: your computer must be authorized first to be able to access the device. So simply issue adb shell now – which will be quit with an error: device unauthorized. Please check the confirmation dialog on your device. Follow that advice (optionally mark the check-box to permanently authorize your computer), and you're done: Now you can use to access your device.

Updates:

¹ Note that in later Linux versions, syntax for the UDEV rules has slightly changed, as e.g. jcomeau_ictx pointed out in his comment. For the values we found above that would be:

SUBSYSTEM=="usb", ATTR{idVendor}=="2970", ATTR{idProduct}=="2282", MODE="0666", GROUP="plugdev", SYMLINK+="android%n"

Two differences: it's now SUBSYSTEM (no plural), and the group has changed from androiddev to plugdev (the former does not exist on recent systems, the latter does and usually is assigned at least to the first user).

Additionally, you might need to add the vendorID to your ~/.android/adb_usb.ini (one ID per line, in hex notation):

# ANDROID 3RD PARTY USB VENDOR ID LIST
# 1 USB VENDOR ID PER LINE.
0x2970
João Pimentel Ferreira
  • 19
  • 1
  • 11
Izzy
  • 91,166
  • 73
  • 343
  • 943
  • 1
    the format for the udev rule was different on my Jessie system: `jcomeau@aspire:~$ tail -n 1 /etc/udev/rules.d/99-android.rules SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", ATTR{idProduct}=="201d", MODE="0666", GROUP="plugdev", SYMLINK+="android%n" jcomeau@aspire:~$ cat ~/.android/adb_usb.ini

    ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT.

    USE 'android update adb' TO GENERATE.

    1 USB VENDOR ID PER LINE.

    0x0e8d`

    I had to ignore the advice to run android update adb and enter it manually as you stated.

     – jcomeau_ictx May 15 '17 at 02:29
  • @jcomeau_ictx thanks for the feedback! As far as I can see from your comment, it's just using a different user group (plugdev instead of androiddev). Not verified, but I'd say the important part here is that it's a group your user (which you want to use USB with) has as well. – Izzy May 15 '17 at 06:17
  • 2
    also SUBSYSTEM instead of SUBSYSTEMS, ATTR instead of ATTRS, comma after MODE="0666"

    not sure if all those changes were necessary, but that's what worked.

     – jcomeau_ictx May 15 '17 at 07:22
  • Oh – thanks, missed those small ones, @jcomeau_ictx – good point! – Izzy May 15 '17 at 13:21
  • 1
    For Linux Non Savvy folks sudo wget -O /etc/udev/rules.d/51-android.rules from here worked for me for my Xiaomi Mi A1 . Of course it's better to learn but good to be lazy :) – beeshyams Aug 25 '18 at 11:02
  • On some distributions you restart udev with udevadm (see https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot). – Skippy le Grand Gourou Sep 06 '18 at 12:41
  • Unplugging the USB, running lsusb, then replugging in the USB and running lsusb again showed no difference. But maybe that's because I'm using USB C ports? –  Jul 29 '19 at 08:49
  • 1
    Great answer. One thing to add: it is possible for higher-level udev rules which target the same vendor to override / conflict with lower-level rules. So if you have a rule targeting ATTR{idVendor}=="2970" in 51-android.rules and then another rule in 99-bad.rules targeting the same vendor id, the latter may make the former ineffective. Something to look out for. – Andy Sep 17 '19 at 22:01
  • @Andy I didn't dig that deep into udev. And as that's not limited to the Android rules, it might make a question better fitted at Unix & Linux, don't you think? – Izzy Sep 17 '19 at 23:07
  • On Android 11, I see the rules group as plugdev, NOT androiddev, as previously mentioned. Not sure if it's related to Android or Linux Mint – beeshyams May 27 '21 at 08:59
  • 1
    @beeshyams you saw that that is mentioned with the update already? And it's got nothing to do with Android as it's the Linux part. Not even with Android-11, but with the "Linux version" – you see that update was already done in 10/2017 when not even Android-10 was released ;) – Izzy May 28 '21 at 07:32
  • Stackexchange should be like reddit. I wanted to give away 50 points of my credit directly to upvote/award this answer. I lost days with this issue in internet searching and implementing so many voodoos that you see around. +50, why is that not possible? – João Pimentel Ferreira Nov 21 '21 at 12:42
  • Thanks @JoãoPimentelFerreira – glad I was able to help! Unfortunately not even a moderator has influence on the "minimum amount" of bounty credits. And I agree that 100 as a minimum is a bit high, especially if one has not much credits to give. 50 would be a good number. Maybe a corresponding question exists on Meta.SE with a reasoning or even the request to adjust… – Izzy Nov 21 '21 at 14:11
  • @JoãoPimentelFerreira strange, according to this answer, you should be able to put a minimum of 50-rep bounty. I may refund your bounty if you want to try it again. – Andrew T. Nov 21 '21 at 16:57
4

A few comments from a newer Linux distribution. Fedora 29 with a Nexus 5X or the Nokia 7.1 (Android One) phone.

First disconnect the phone, if already connected.

  1. Install android-tools which will supply ADB (sudo dnf install android-tools)
  2. Copy udev rules (sudo cp /usr/share/doc/android-tools/51-android.rules /etc/udev/rules.d)
  3. Reload udev rules (sudo udevadm control --reload-rules)
  4. Restart ADB to be sure (sudo systemctl restart adb)

Now connect the phone and run adb devices from the command line. You will probably see a device listed with "no permissions". This is fine.
IF it is not listed, you will have to add your device to the udev rules file, but for me, the tested devices just worked with the pre-defined rules.

Run adb shell and hopefully you will get a security notification on the phone asking if you want to trust the computer, select yes.
IF instead your computer says "error:insufficient permissions for device", you need to make sure that on the phone you have set your USB port to "Transfer files" mode, and not "Charge this device". On Android 8.1 this is located in settings under "Connected devices" > "USB".

I have noticed that even if you have everything working today, that tomorrow it may suddenly break for no apparent reason. If that happens, first check the USB port setting on the device, which may have changed back to charging mode, and if that fails, revoke USB debugging authorisations on the device (in settings under Developer options), and you should hopefully get the pop-up again when you run adb shell.

With this, I am able to run Android Studio and run on the connected device.

Andrew T.
  • 15,988
  • 10
  • 74
  • 123
Rob
  • 41
  • 2
1

I have played around with USB packet sniffing with Wireshark and had used the modprobe usbmon module. When this module is loaded adb does not work anymore. In this case rmmod usbmonand adb kill-server helps.

k_o_
  • 133
  • 5