rule to enable use of android's adb

[Joel Stanley]

Binary package hint: udev

The Android developer kit has software that talks to a device over usb. It requires a udev rule to set the correct permissions, as described at:

http://code.google.com/android/intro/develop-and-debug.html#developingondevicehardware

The rule is:

SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"

[Scott James Remnant (Canonical) (canonical-scott)]

Would this not give all system users the ability to brick your phone?

[Joel Stanley (shenki)]

Generally speaking, adb doesn't allow you to brick your phone. It can give you a non-root shell (root on a dev phone, but if you have a dev phone there's plenty of ways to brick), install and remove applications, pull and push files from/to the device.

I saw your new udev-extras package. Not much documentation there but would this rule fit there?

Or am I missing something entirely?

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-01-15 at 22:18 +0000, Joel Stanley wrote:

> Generally speaking, adb doesn't allow you to brick your phone. It can
> give you a non-root shell (root on a dev phone, but if you have a dev
> phone there's plenty of ways to brick), install and remove applications,
> pull and push files from/to the device.
>
Right,

So this sounds like the kind of device access you would only want to
give to the user at the same physical console as the device.

In other words, access control by ACL (as we do for media players,
phones, scanners, etc. already)

> I saw your new udev-extras package. Not much documentation there but
> would this rule fit there?
>
> Or am I missing something entirely?
>
udev-extras does contain an early version of code that will set ACLs for
devices, but it is not suitable for use right now. It's intended to
replace code that already exists in HAL as we migrate away from HAL to
DeviceKit over the coming years.

Right now, the correct place to set your device ACL is through HAL.

Scott
--
Scott James Remnant
<email address hidden>

[Joel Stanley (shenki)]

Attached is an attempt at a hal fdi for the G1/Android Dev Phone 1.

Also attached is the output of hald --verbose=yes when plugging in the device. I attach the log as the device is not getting sufficient permissions from hal/policykit with access_control.type set to pda.

[Daniel Sargeant (dsargeant)]

Could this have something to do with it?: https://lists.ubuntu.com/archives/jaunty-changes/2009-January/002637.html
It seems SYSFS is now called ATTRS.

[Daniel Sargeant (dsargeant)]

Nevermind, changing SYSFS to ATTRS in the rule fix the problem for me.

[Daniel Sargeant (dsargeant)]

*didn't fix the rule for me. I wish there was a way to edit comments.

[Cyril Jaquier (cyril-jaquier)]

Changing SYSFS to ATTRS did not fix the issue for me too. However, if I start the ADB server as root, it works. So it seems to be a permission issue.

I attach the output of "udevadm info" for the device. Maybe someone with a better understanding of the udev rules could propose a fix.

[Cyril Jaquier (cyril-jaquier)]

Ok. I just fixed the issue. 50-udev-default.rules was overwriting my rule stored in 50-android.rules.

[8728] udev_rules_apply_to_event: MODE 0666 /etc/udev/rules.d/50-android.rules:1
[8728] udev_rules_apply_to_event: LINK 'char/189:132' /lib/udev/rules.d/50-udev-default.rules:4
[8728] udev_rules_apply_to_event: MODE 0664 /lib/udev/rules.d/50-udev-default.rules:52
[8728] udev_rules_apply_to_event: NAME 'bus/usb/002/005' /lib/udev/rules.d/50-udev-default.rules:52
[8728] udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /lib/udev/rules.d/90-hal.rules:2
[8728] udev_rules_apply_to_event: RUN 'socket:@/org/kernel/udev/monitor' /lib/udev/rules.d/95-udev-late.rules:7
[8728] udev_device_new_from_syspath: device 0x7fb6f92d0330 has devpath '/devices/pci0000:00/0000:00:1a.7/usb2/2-3'

So I renamed it to 90-android.rules so that it gets exectued after 50-udev-default.rules.

[8887] udev_rules_apply_to_event: LINK 'char/189:133' /lib/udev/rules.d/50-udev-default.rules:4
[8887] udev_rules_apply_to_event: MODE 0664 /lib/udev/rules.d/50-udev-default.rules:52
[8887] udev_rules_apply_to_event: NAME 'bus/usb/002/006' /lib/udev/rules.d/50-udev-default.rules:52
[8887] udev_rules_apply_to_event: MODE 0666 /etc/udev/rules.d/90-android.rules:1
[8887] udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /lib/udev/rules.d/90-hal.rules:2
[8887] udev_rules_apply_to_event: RUN 'socket:@/org/kernel/udev/monitor' /lib/udev/rules.d/95-udev-late.rules:7
[8887] udev_device_new_from_syspath: device 0x7f9c115607e0 has devpath '/devices/pci0000:00/0000:00:1a.7/usb2/2-3'

My 90-android.rules:

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666"

[Joel Stanley (shenki)]

Per Scott's recommendation, this is a HAL rule we need, not udev.

[Matt Zimmerman (mdz)]

In order to work, adb requires access to /dev/bus/usb/NNNN/MMMM for the device. Mine (T-Mobile G1) is:

Bus 001 Device 013: ID 0bb4:0c02 High Tech Computer Corp.

A quick Google search indicates that 0bb4:0c01 is used for some other G1 phones. I don't know the difference between the two.

Please note that HTC makes many other USB devices as well, so the rules which apply a permission change based only on idVendor are not a general solution.

[Matt Zimmerman (mdz)]

udi = '/org/freedesktop/Hal/devices/usb_device_bb4_c02_HT839GZ23983'
  info.linux.driver = 'usb' (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_1d6b_2_0000_00_1a_7' (string)
  info.product = 'Android Phone' (string)
  info.subsystem = 'usb_device' (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_bb4_c02_HT839GZ23983' (string)
  info.vendor = 'High Tech Computer Corp.' (string)
  linux.device_file = '/dev/bus/usb/001/013' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'usb' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3' (string)
  usb_device.bus_number = 1 (0x1) (int)
  usb_device.can_wake_up = false (bool)
  usb_device.device_class = 0 (0x0) (int)
  usb_device.device_protocol = 0 (0x0) (int)
  usb_device.device_revision_bcd = 256 (0x100) (int)
  usb_device.device_subclass = 0 (0x0) (int)
  usb_device.is_self_powered = false (bool)
  usb_device.linux.device_number = 13 (0xd) (int)
  usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3' (string)
  usb_device.max_power = 256 (0x100) (int)
  usb_device.num_configurations = 1 (0x1) (int)
  usb_device.num_ports = 0 (0x0) (int)
  usb_device.product = 'Android Phone' (string)
  usb_device.product_id = 3074 (0xc02) (int)
  usb_device.serial = 'HT839GZ23983' (string)
  usb_device.speed = 480.0 (480) (double)
  usb_device.vendor = 'High Tech Computer Corp.' (string)
  usb_device.vendor_id = 2996 (0xbb4) (int)
  usb_device.version = 1.0 (1.02) (double)

[Joel Stanley (shenki)]

I see the same product id and lshal output for my ADP1.

The 0bb4:0c01 is the id you will see when booting a Dream into HBOOT, the bootloader. Stock G1s won't be able to do this.

Apparently it's also the id for phones that have adb disabled, and/or an older version of the firmware, but I can't confirm either of these.

Is it possible to match on something like usb_device.product = 'Android Phone'? This may make the rule forwards-compatable with newer devices?

[Matt Zimmerman (mdz)]

Based on my (new and very basic) understanding of access control in HAL, the two patches above should cause the active session to have access to the device node for a connected G1 phone.

It didn't work when I tested it, though. access_control.file was set to the correct device node path, but its permissions remained root/root.

[Matt Zimmerman (mdz)]

Jason D. Clinton said he got this working, in http://jasondclinton.livejournal.com/73152.html

I haven't looked to see if his configuration was substantially different from the one I experimented with yet.

[Endolith (endolith)]

Jason's livejournal post says not to do it that way

Update 2009-07-06: All of this is broken on the latest versions of various parts as hal is in the process of being aggressively purged from the newest distros. The new, officially blessed method is to use udev-acl support which grants access to anyone who is in the ConsoleKit database at the time that the phone is attached to the computer.

[chrisdew (cmsdew)]

Matt Zimmerman's post #12 made me think that I may have been sold an HTC Hero with adb disabled.

Luckily that it not the case - http://www.finalcog.com/htc-hero-android-adb-0bb4-0c01-ubuntu-jaunty-0bb4-0c02-problem

[Mats Bengtsson (matsbengtsson)]

#17
First time I attach the ADP1 the ACL is set. But the next time I attach the ACL is never set and I have to run adb as super-user to get in contact with the ADP1.

I read the first couple of chapters of the HAL description and it struck me that the other PDA's (like Palm, PocketPC) are defined in the "/usr/share/hal/fdi/information" directory while the "android.fdi" file lives in the "policy" directory. I tried sticking the "android.fdi" file in the "/etc/hal/fdi/information" directory instead and suddenly I got an ACL set every time I attached the ADP1.

[Matt Zimmerman (mdz)]

An android-developers thread at http://groups.google.com/group/android-developers/browse_thread/thread/af53210a9c41ec37/a0abc58971a44ac0?pli=1 suggests:

SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"

which is the same as the one in comment #10 but seems too broad, both in the devices matched and in the permissions granted.

Based on the examples I see in the default rules, I think what is probably needed is:

1. A set of rules which match the appropriate USB devices and identify them as Android devices, e.g.:

ATTRS{idVendor}=="0bb4" , ATTRS{idProduct}=="0c02" , ENV{ID_...}="..."

2. A rule which then sets permissions based on the ID_... value, perhaps in 70-acl.rules, e.g.:

ENV{ID_...}=="...", ENV{ACL_MANAGE}="1"

I'm not intimately familiar with this, though, and would appreciate guidance on whether this is the Right Way to Do It now.

[Scott James Remnant (Canonical) (canonical-scott)]

I think it's just a matter of adding this directly to 70-acl.rules, there's unlikely to be many devices in this case, so we can just put them in like we do for fingerprint readhers, etc. already.

Maybe something like

# smart phones
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0c02", ENV{ACL_MANAGE}="1"

If that works, then I'll submit a patch upstream

[Matt Zimmerman (mdz)]

On Sat, Nov 14, 2009 at 05:29:17PM -0000, Scott James Remnant wrote:
> I think it's just a matter of adding this directly to 70-acl.rules,
> there's unlikely to be many devices in this case, so we can just put
> them in like we do for fingerprint readhers, etc. already.
>
> Maybe something like
>
> # smart phones
> SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0c02", ENV{ACL_MANAGE}="1"
>
> If that works, then I'll submit a patch upstream

Confirmed, that works fine with my G1.

I thought we might want some indirection there because there is more than
one device and the list will grow, but if you think it's OK to put it
directly into 70-acl.rules, then great.

--
 - mdz

[eagano (developer1)]

I have been working on getting the Android Debug Bridge (adb, the Android tool referenced in the original bug report) working with the Motorola Droid on Ubuntu 9.10. The hardware vendor id is different - this is a Motorola handset. If this is going to be addressed, should all the major Android handsets be added? From the Android developer site (http://code.google.com/android/intro/develop-and-debug.html#developingondevicehardware) the vendors possible vendors include:

Acer -- 0502
HTC -- 0bb4
Huawei -- 12d1
LG -- 1004
Motorola -- 22b8
Samsung -- 04e8
Sony Ericsson -- 0fce

Also, I added a group to prevent the Android tools from having to be run as root and although I am new at this level of config it seems reasonable to me to prevent root:
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", MODE="0666", GROUP="plugdev"

[Matt Zimmerman (mdz)]

Assigned to Scott per comment #24

[Scott James Remnant (Canonical) (canonical-scott)]

Pushed as git 4fe41ac

[eno (ubuntu-bitblit)]

When was this fixed? I ask because Im still seeing this problem in 9.10. Moreover, if the fix is only for the vendors above then I predict there will be a lot of updates to the vendor IDs since there are going to be a LOT of new Android devices (not just phones but also media players, tablets, netbooks, etc) being released in 2010.

[Matt Zimmerman (mdz)]

9.10 was released in October, while the fix for this bug was committed in December. It's not available in Ubuntu yet; the bug will be marked Fix Released when it's available it Lucid (10.04).

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 151-1

---------------
udev (151-1) lucid; urgency=low

  * New upstream release:
    - Support for systems with SYSFS_DEPRECATED=y officially dropped.
    - Bug fixes.
    - Rules updates. LP: #492657, #316215, #259244, #250732.

  * Merge additional fixes from GIT master:
    - Rules updates. LP: #581496, #415023.
    - Fix firmware error reporting.
 -- Scott James Remnant <email address hidden> Wed, 10 Feb 2010 11:50:56 +0000

[Sbubba (sbubba)]

Hello
I've Ubuntu 10.04 and I try to connect my HTC diamond by USB with the original cable.
I've tried to add rule (SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666" and also SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666") and restart udev, but nothing.

the output of my lsusb:
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

none usb.

the output of ./adb usb:
error: device not found

outpu of ./adb devices:
List of devices attached

(empy list)

I've tried to connect also a nokia 6610 and it worked.
With windows mobile on HTC, usb connection is perfect.

What's wrong?

[Tero Karvinen (karvinen+launchpad)]

Perla, the problem is probably not in your udev rule. The device should show in 'lsusb' listing before you create the rule.

I use 'lsusb' to check for vendor ID before creating the rule.

Check that you have set HOME: MENU: Settings: Applications: Development: USB debugging: On.

[Sbubba (sbubba)]

@Tero Karvinen: first of all, thank you so much for your answer.

-with wm:
I can see the device with lsusb ONLY with windows mobile:
"Bus 002 Device 002: ID 0bb4:0c13 High Tech Computer Corp. "
so I known the vendor ID and add it in udev rule.
Additionally, I can see HTC in "computer" as "HTC Storage: File system da 4,0 GB", so I can use it to transfer files (none usb connection with android)

-with android:
The same lsusb does NOT show the device with android:
"Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 15ca:00c3 Textech International Ltd. Mini Optical Mouse
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub"
there is only the usb mouse.
I've activated the USB debugging mode under android, but the pc seems to not recognize android.
The adb output are the same of the previous post.

I still don't understand where is the problem.
Thanks.

[Juanje Ojeda (juanje)]

Actually the bug has been fixed just for the smartphone G1, but not for the rest. There are a lot of new smartphones that are affected by this issue.
Following the upstream rules about to use ACL instead of give permissions to everyone I've created a patch for upstream and I've sent to the maillist:
http://www.spinics.net/lists/hotplug/msg03943.html

The code on the Ubuntu's package is not fully compatible with the last upstream's code and this patch so I've made also a patch for the Ubuntu's package's code at the branch: lp:~juanje/udev/udev-acls-android (revision 173)

The patch add all the Android smartpnohes' vendors that are listed on the Android Development website, plus the Nexus One, which wasn't on that list.
http://developer.android.com/guide/developing/device.html#VendorIds

Cheers

[Scott James Remnant (Canonical) (canonical-scott)]

Please don't patch the Ubuntu udev package, instead submit the patch to udev upstream and it will be included when we update

[Scott James Remnant (Canonical) (canonical-scott)]

Marking back as Fix Released since the original rule is present - once you've got the new rules in the udev package upstream and there's been a release, feel free to open a new tracking bug requesting the update (in case of required freeze exceptions, etc.)

[Juanje Ojeda (juanje)]

Well, as I told you above, I sent the patch to upstream but they haven't pay much attention to it...[1]

Anyway I marked back to Confirmed before because the package released din't fix this bug. At least not the one is described at the Description. It was fixed just for a single phone's model and the Description asking about a more generic solution.

I understand it won't worth to change it on the current stable version of Ubuntu. Sorry for the inconveniences.

[1] http://www.spinics.net/lists/hotplug/msg03943.html

[tak (tak)]

I've been trying to manually configure udev for a while now to be compatible with adb, I've had to buy a suite of applications for my phone as an alternative due to the fact it just isn't working. this would be an awesome feature for android developers on ubuntu.

[Guilherme Salgado (salgado)]

http://bazaar.launchpad.net/~vcs-imports/udev/trunk/revision/3353 seems to be the revision that made it possible to use adb with G1 phones, but the rule added there is no longer present in Maverick's udev or udev trunk. There's also the fact that this bug is not about making it possible to use adb with G1 phones but rather make it possible to use adb with any android phone.

I understand that the more reasonable solution requires each of the phones to be listed explicitly but in that it'd be better to change this bug's title and instruct people to file separate bugs with the details about their phones. Is that OK?

I'm reopening this bug as the change that "fixed" it doesn't seem to be in udev anymore, and once it's acknowledged that we need separate bugs for other phones I'll change the title/description to clearly say so.

[Guilherme Salgado (salgado)]

Except that I don't seem to have the rights to reopen the bug, so I'll have to chase someone who does.

BTW, I've tried using adb with a G1 on a fresh Maverick install and I got the no permissions error. I got that even after adding a rule [1] identical to the one in http://bazaar.launchpad.net/~vcs-imports/udev/trunk/revision/3353 plus restarting the adb server and reconnecting the phone. It was only after I added [2] that it did work.

[1] SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0c02", ENV{ACL_MANAGE}="1"
[2] SUBSYSTEM=="usb",ATTRS{idVendor}=="0bb4",MODE="0666"

[Matt Zimmerman (mdz)]

Confirmed, this isn't working for me either in 10.10:

perseus:[~/src/android/tools] lsusb |grep G1
Bus 001 Device 043: ID 0bb4:0c02 High Tech Computer Corp. Dream / ADP1 / G1 Phone (Debug)
perseus:[~/src/android/tools] sudo getfacl /dev/bus/usb/001/043
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/043
# owner: root
# group: root
user::rw-
group::rw-
other::r--

[Juanje Ojeda (juanje)]

That's because upstream decide to remove that:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=232f180

I was trying to add suport for more Android devices but they said there was no good way to manage all the new devices and they were going to remove the support for specific devices.
I was thinking about to create a patch for Ubuntu or (maybe better) a seperate package with the android udev rules, so those rules don't mess with people who don't have Android devices or simply they don't want it.

I've already post a branch with the patch here, in my mail to upstream:
http://www.spinics.net/lists/hotplug/msg03943.html

[Martin Pitt (pitti)]

For the same reason that it was removed upstream it would also be quite a nuisance to maintain this list in the Ubuntu package, but I'm not opposed to doing that as long as it's precise vendor/product lists. Juanje's approach of allowing access to all devices from a large set of vendors would also allow users raw access to e. g. Samsung USB hard disks. Also, I doubt that raw device access is of much use on phones which do not have the ADB equivalent. So for now I'll just put back the G1 rule.

[Martin Pitt (pitti)]

Actually, I think we can do better. Incidentally, the G1 (and other phones) are already marked as music players, and I see little reason to not give users raw access to this class of devices. This requires us to reshuffle the media-player-info rules a bit, but this should be feasible.

[Juanje Ojeda (juanje)]

Martin, I agree with you about not to do it by vendors, but It'd be nice if (as long the bug is for android phones, not just for the N1) we put the rule also for more phones. At least for the Google's ones, like the Nexus One (which is pretty extended I think):

# Nexus One
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e11|4e12", TAG+="udev-acl"

I'm guess the media-player-info could be the easier place to manage all these devices. As you said, most of then are already there as music players...

[Guilherme Salgado (salgado)]

Martin, while you're at it, can you add the HTC Desire (idVendor 0x0bb4
and idProduct 0x0c87) as well? It's not present on natty's
media-player-info.

Thanks!

[Martin Pitt (pitti)]

Guilherme Salgado [2010-11-04 14:08 -0000]:
> Martin, while you're at it, can you add the HTC Desire (idVendor 0x0bb4
> and idProduct 0x0c87) as well?

It's already present in upstream trunk, I'll do a release and upload soon.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Martin Pitt (pitti)]

Incidentally the current m-p-i rules already also tag the raw USB device, for UMS devices.

[Martin Pitt (pitti)]

I fixed that in upstream git: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=0e6546c11

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 165-0ubuntu1

---------------
udev (165-0ubuntu1) natty; urgency=low

  * New upstream release. Switch to Ubuntu-ish version number to avoid
    confusing them with Debian's.
    - Allow local users ACL access to raw USB devices of mobile phones.
      (LP: #316215)
    - Allow local users ACL access to raw FFADO devices. (LP: #681755)
    - Keymap fixes. (LP: #625770, #627890, #686662)
  * debian/control, debian/gir1.2-gudev-1.0.install: Rename GIR package to
    gir1.2-* to match the repository version and the recent transition.
    Add conflicts/replaces to old gir1.0-gudev-1.0.
  * debian/udev.postinst: Call udevadm --convert-db when upgrading from a
    version earlier than 165, to update the running database.
 -- Martin Pitt <email address hidden> Sun, 19 Dec 2010 00:15:00 +0100