On Windows, a missing driver shows up as a yellow triangle in Device Manager. On Linux there's no driver to install in the traditional sense — the kernel already talks to the phone over USB. What's usually missing is permission. Without a udev rule granting your user account access to the device node, adb devices either shows nothing or lists the phone with an empty serial number and no permissions next to it.
By default, USB device nodes under /dev/bus/usb/ are owned by root with restrictive group permissions. adb and fastboot run as your regular user, so they can enumerate the device but can't open it for read/write. The fix is a udev rule that matches your phone's vendor ID and reassigns the device node to a group your user belongs to, typically plugdev.
This is a one-time setup per machine. Once the rule is in place, it applies to every Android device you plug in, not just one phone.
Plug the phone in, then run:
lsusbLook for a line matching your phone's brand. It will look something like Bus 001 Device 004: ID 18d1:4ee7 Google Inc.. The four hex digits before the colon — 18d1 in this example — are the vendor ID. Google's vendor ID is 18d1; Samsung is 04e8; Xiaomi is 2717; OnePlus/OPPO devices commonly show 2b4c or 22d9 depending on the model. If lsusb doesn't list the phone at all, try a different cable or port before assuming a software problem — charge-only cables that lack data lines are a common cause of a phone not appearing here.
Create a new rules file (the filename just needs to sort before other rules and end in .rules; 51-android.rules is the conventional name):
sudo nano /etc/udev/rules.d/51-android.rulesAdd one line per vendor ID you need. A generic Google/AOSP entry plus a couple of common brands looks like this:
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"
SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", MODE="0666", GROUP="plugdev"
SUBSYSTEM=="usb", ATTR{idVendor}=="2717", MODE="0666", GROUP="plugdev"Google publishes a longer reference list of vendor IDs for most Android OEMs in the Android Studio documentation, which is worth keeping bookmarked if you work with more than one or two brands.
The rules file itself needs to be readable by udev:
sudo chmod a+r /etc/udev/rules.d/51-android.rulesThen add your user to the plugdev group so the GROUP="plugdev" clause actually grants you access:
sudo usermod -aG plugdev $USEROn distributions that don't ship a plugdev group (some minimal Fedora or Arch installs), either create it with sudo groupadd plugdev before running the command above, or swap GROUP="plugdev" for a group that already exists on your system, such as your own primary user group.
sudo udevadm control --reload-rules
sudo udevadm triggerGroup membership changes don't take effect in an already-open session, so log out and back in (or reboot) before testing. Then unplug and replug the USB cable, enable USB debugging on the phone if you haven't already, and check:
adb kill-server
adb devicesYou should see the device listed with its serial number and status device, along with an authorization prompt on the phone the first time it connects to a new host.
The same udev rule generally covers both ADB and fastboot mode for a given phone, since both use the same USB vendor ID even though the device presents a different interface in each mode. If adb devices works but fastboot devices shows nothing once the phone reboots into the bootloader, double check with lsusb while the phone sits in fastboot mode — a small number of devices report a different product ID (not vendor ID) in that state, though the vendor ID rule above should still match.
Device still shows "no permissions": Confirm the vendor ID you used matches exactly what lsusb reports for this specific phone — some sub-brands ship under an unexpected vendor ID rather than the parent company's usual one. Also confirm the group you specified in the rule actually contains your user: groups $USER should list it.
Rule loads but device still not listed: Some environments run adb as a system service under a different user or in a container, which won't see your group membership. Kill any system-level adb server with sudo pkill -f adb and restart your user-level one.
Works over USB but you'd rather skip cables entirely: once the wired connection is confirmed working at least once, you can switch to ADB over Wi-Fi using adb tcpip 5555 for day-to-day use, which sidesteps udev entirely after the initial pairing.
Need to script this across many machines: the same 51-android.rules file can be copied verbatim to any Linux box; there's nothing machine-specific in it beyond the vendor IDs you choose to include.