The rules file: /usr/lib/udev/rules.d/51-android.rules contains matches like: SUBSYSTEM=="usb", ATTR{idVendor}=="8087", which are "Intel" and match on USB "Root Hubs" which are found on, I guess, 80% of all machines out there. This makes no sense, really. Also, udev cannot be used to start services, udev will track all processes and kill them after 30 seconds of udev idle time. Services need to be started by systemd. Udev only supports executing very short running processes, never services. The server should likely be converted to a systemd service, which is manually enabled on systems that want to start it. Starting it on-demand based on USB ids is almost impossible, unless you want to maintain a list of product too, the vendor alone surely makes no sense, because almost every box contains an Intel, or any of the other vendors, USB device. As an alternative, the server could be patched to support socket activation, inetd-style or systemd style, and when the clients tries to connect, the system will start it on-demand. Currently, the server is started on every box, I've check, where the android-tools are installed. Thanks!
Due to security issues(879585,894745) we need to run service as unprivileged user so we need something like: SUBSYSTEM=="usb", ATTR{idVendor}=="8087", MODE="0664", GROUP="usb_rw", TAG+="systemd", ENV{SYSTEMD_WANTS}="adb.service" Or if we chouse not to start service on plugging: SUBSYSTEM=="usb", ATTR{idVendor}=="8087", MODE="0664", GROUP="usb_rw" ( service is configured to start as User=adb Group=usb_rw ) I'am also researching some workarounds with running service as root(it seems not so good idea to set group for all Intel usb devices). I'll try "PrivateTmp=true" systemd parameter.
As mentioned, on-demand activation based on "IS there an Intel USB device" makes no sense really. You are better off turning that thing into a normal service which users can enable, or which even gets unconditionally enabled at package install time. On-demand activation is pointless if it happens at ~80% of all machines, we should not do such stuff, it's the wrong model. The only sensible on-demand activation is based on strict product, not vendor-only matches, or based on starting the client tool, which triggers starting the server (socket activation). Please turn that thing into a simple service to enable/disable, or make it socket activated, but leave the udev matching alone, it's really pointless to match on a long list of huge computer vendors to start a very specialized service. That's really not what udev is for, and not how things should work.
+1 for converting this into a service or at least marking 51-android.rules as config in rpm. Remove it would be ok for me, but I don't want to break the package.
android-tools-20130123git98d0789-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc16
android-tools-20130123git98d0789-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc17
android-tools-20130123git98d0789-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc18
Package android-tools-20130123git98d0789-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing android-tools-20130123git98d0789-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1666/android-tools-20130123git98d0789-1.fc16 then log in and leave karma (feedback).
android-tools-20130123git98d0789-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
android-tools-20130123git98d0789-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
android-tools-20130123git98d0789-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.