WebUSB in Chromium | Does a package for correct `android-tools` udev rules exist?

Ask Fedora
,
1

I’ve been experiencing an inability to use WebUSB, as Chromium describes.

Via Inform the user that they might need to run the flasher as the superuser to access the device. (#4) · Issues · postmarketOS / webflash · GitLab, I was recently informed that the underlying issue appears to be that android-tools-1:34.0.4-14.fc40.x86_64.rpm doesn’t automatically install a recommended equivalent to, for instance, openSUSE Tumbleweed’s android-tools udev package.

I don’t appear to be the sole person to have experienced this, per:

2

Guide: use adb & fastboot on Fedora for installing custom Android OS - #3 by vgaetera

3 Likes
3

@vgaetera, how weird that it is expected that a user knows this stuff merely to use adb, especially since it breaks WebUSB support, meaning that using the command line is actually easier than what should be the noob-proof version - using the browser!

I would expect that installing android-tools would invoke:

systemctl enable adb &&\
systemctl start adb

Perhaps implementing PolKit like

describes is a feasible solution.

1 Like
4

This is part of the package documentation, and the relevant instruction is on the first line:
Tree - rpms/android-tools - src.fedoraproject.org

The service is automatically triggered by the udev rules when you connect a matching device.
Why do you need to enable the service forcing it to start when no device is connected?

2 Likes
5

@vgaetera,

I’m just trying to get WebUSB to work. What’s the way to do that if not to enable the service?

Expecting a user to happen to read the source code - a file in the package - is unreasonable, and certainly cannot be considered documentation for a user (Are comments considered a form of documentation? - Software Engineering Stack Exchange). Thanks though - I’ll try that if it comes down to it.

1 Like
6

That file is distributed as documentation, not source code:

> rpm --help | grep -e docfiles
  -d, --docfiles                     only include documentation files

> rpm -q -d android-tools 
/usr/share/doc/android-tools/51-android.rules

WebUSB requires the service to run.
The service starts when triggered by the udev rules.
Connecting the USB device triggers the relevant udev rule.

But that does not explain why the service must be explicitly enabled.
Do you want to use WebUSB for devices with arbitrary vendor IDs?

1 Like
7

So the only question is: why ship the udev rules inactive in the docs directory, and not have a separate package android-udev-rules placing it in the active one?

This would then automatically start the adb service and everything should be fine?

Is plugdev still required?

9

@vgaetera, that appeared to be the common consensus for how to provide this functionality in the thread. Have you a preferable method of enabling WebUSB support?

Not to my knowledge - certainly not explicitly - because I’m unfamiliar with what that entails.

10

@vgaetera:

[quote=“{third: "Beedell", first: "Roke"}{.JSON5}, post:23, topic:101410, full:true, username:rokejulianlockhart”]

@boredsquirrel, Google Issue Tracker
[/quote]

11

I’m not sure that elevating privileges is a good idea from a security perspective.
In fact, ADB can run as a normal user without privilege elevation.
Apparently there are built-in udev rules setting up ACLs for USB devices.
To make it run persistently, create a user unit and enable it like this:

mkdir -p ~/.config/systemd/user
sed -e '/^Environment=/d
/^WantedBy=/s/multi-user/graphical-session/' \
/usr/lib/systemd/system/adb.service \
> ~/.config/systemd/user/adb.service
systemctl --user daemon-reload
systemctl --user --now enable adb.service
3 Likes
12

The ADB service can generally run as:

  • root - security risks for the system;
  • normal user - security risks for the user environment and data;
  • dedicated restricted user - best practice for services.

The latter option requires some changes:

sudo rm -f /etc/udev/rules.d/51-android.rules
sudo awk -e '!/^(#|$)/{print $1,$2,"GROUP=\"plugdev\""}' \
/usr/share/doc/android-tools/51-android.rules \
| sudo tee /etc/udev/rules.d/51-android.rules > /dev/null
sudo groupadd -r plugdev
sudo useradd -r -g plugdev -d /var/lib/adb -s $(type -P nologin) adb
sudo chown -R adb:plugdev /var/lib/adb
sudo mkdir -p /etc/systemd/system/adb.service.d
sudo tee /etc/systemd/system/adb.service.d/override.conf << EOF > /dev/null
[Service]
User=adb
Environment=
EOF
sudo systemctl daemon-reload
sudo systemctl --now enable adb.service
3 Likes
13

@vgaetera, that’s very comprehensive. Many thanks. However, before I run that on my machine, might I know where you got that code from? I’m surprised I wasn’t able to locate it if it’s in official documentation. If it’s undocumented, then I’m even more interested in how you ascertained that.

1 Like
14

With years of Linux administration and some RPM packaging experience, this comes naturally, as reading various manuals and studying different RPM spec files can give you an idea of how things work in other projects, so you can utilize those methods for your own need.

3 Likes