1) plug your phone into the usb bus on your system. does not need to be in application debug mode yet... 2) verify that you can see the phone by using 'lsusb', e.g.: $ lsusb Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 044: ID 22b8:2d66 Motorola PCS Bus 002 Device 004: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub Bus 002 Device 003: ID 10d5:0001 Uni Class Technology Co., Ltd ... the line "ID 22b8:2d66 Motorola PCS" is my phone. the rest is other stuff on the usb busses. ignore it. 3) the 4 digit value 22b8 is the Vendor ID of my phone. yours may be different. whatever it is, this is the value you need to use in your udev rule. 4) the Bus number and Device number are useful. you can see what permissions your device is getting at any time by doing $ ls -l /dev/bus/usb/ where is the Bus number above (002 in this case). the permissions of the device will be the permissions of the file numbered with the Device number above. in my case it was device 044, so the full file path is /dev/bus/usb/002/044 ! note - this device number will change when you plug/unplug or enable/disable debug on your device. 5) you can now get *alot* of info on this device now by using 'udevadm info', but you need to use the bus and device info above (remember yours may be different and change). you can use either udev info command --query=all or --attribute-walk, e.g.: $ udevadm info --query=all --name=/dev/bus/usb/002/044 or $ udevadm info --attribute-walk --name=/dev/bus/usb/002/044 note that the attribute-walk walks up the bus. the first entry printed should be the lowest device on the chain, which is your phone. in my case some of the lines looked like: looking at device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.4': KERNEL=="2-2.4" SUBSYSTEM=="usb" DRIVER=="usb" ATTR{configuration}=="Motorola Config 42" ... ATTR{idVendor}=="22b8" ... ATTR{busnum}=="2" ATTR{devnum}=="44" ATTR{version}==" 2.00" ATTR{maxchild}=="0" ATTR{quirks}=="0x0" ATTR{authorized}=="1" ATTR{manufacturer}=="Motorola " ATTR{product}=="MB200" ATTR{serial}=="" ... where the is the serial number of my phone, which will show up in the adb devices list when this all works. recognize the items that you will need for the .rules file are there. 6) now, lets write the .rules file. you have two choices. either get the permissions of the phone as it shows up changed to 0666 (rw for all users, including the world) or change the ownership to be your user. i prefer the latter. seems cleaner to me, so i will use this approach for the rest of the info. 7) find out who you are. use the id command, e.g.: $ id uid=1000() gid=1000() groups=... where the uid and gid for you are indicated. for now lets use both as 'juser' for the example. 8) now lets create the .rules file. the number at the beginning of the file name is the order that it will be loaded by the udev infrastructure. it may be important. all the examples showed a number of 50, but there are a bunch of things being loaded in /lib/udev/rules.d/ as well. i prefer to make my file name 99-android.rules to force it to load very late in the process. this keeps other later things from clobbering my permissions as they load. for example, if you use the ATTR{idVendor} attribute in .rules as oppose to SYSFS{idVendor}, then when other later rules load they could over write the permissions you set in your .rules file. 9) you have to use root or sudo to create the file in /etc/udev/rules.d. create /etc/udev/rules.d/99-android.rules and put in a line like: SUBSYSTEM=="usb", SYSFS{idVendor}=="", OWNER="" GROUP="" and save it. the SYSFS{idVendor} value needs to match your device id, and the OWNER and GROUP are from step 7 above. for this example lets use SUBSYSTEM=="usb", SYSFS{idVendor}=="22b8", OWNER="juser" GROUP="juser" if you just want to set the permissions use: SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", MODE="0666" 10) now, when you connect the device (try the application debug mode) you should be able to see that the device appears with the correct user permissions. e.g.(using this example's bus, device, and uid/gid values): $ ls -l /dev/bus/usb/002 crw-rw-r-- 1 root root 189, 128 2010-10-09 20:02 001 ... crw-rw-r-- 1 root root 189, 131 2010-10-09 20:02 004 crw-rw-r-- 1 juser juser 189, 173 2010-10-10 11:29 044 this is very good, 'cause now adb running as you will be able to read and write the device. 11) if you did not get here, then you have udev issues. dont bother beating on adb, the problem is in udev. your best bet is to go into /etc/udev and edit udev.conf, to change the line udev_log="err" to udev_log="debug" to see what is going on. then you can follow what udev is doing by opening a terminal window and following /var/log/syslog with: # tail -f /var/log/syslog you may need to restart udev, which you can do by doing: $ sudo /etc/init.d/udev restart from another terminal window. this output is very verbose, but you should look to see that your .rules file is being loaded. if not, then that is the issue to fix. 12) if all is ok, and the device has the right permissions, when you put it into application debug mode you should be able to simply start the adb server with: $ adb devices and see your device by serial number List of devices attached device 13) if you have problems with adb, here are a few things to check. a) make sure you see that adb is running, and owned by you by looking for it with ps, e.g.: $ ps aux |grep adb you should see a line like: juser 0.0 0.1 28160 728 pts/4 Sl 10:18 0:01 adb fork-server server where juser should be your user id, and is the process ID. b) if adb is running as root, you may need to use 'sudo killall adb' to kill it off and then as your user run 'adb devices', which should start the server as you. c) if you still have problems you can run strace on the server and it's child processes with: $ strace -f ./tools/adb server note that the output is very verbose, but look thru there for some kind of permissions problem. lots of 'file not founds' are ok, but as the daemon starts and tries to bind to the device, you may find a permission problem.