Wireless adb doesn't follow you into the bootloader

I spent an evening setting up an Android phone as a portable pentest lab — entirely over Wi-Fi. Paired with adb pair, connected with adb connect, debloated 41 packages, pushed scripts, installed Magisk, pulled a patched boot.img back. The cable stayed in the drawer. It felt clean.

Then I ran the flash step:

adb -s 192.168.1.189:42311 reboot bootloader
fastboot wait-for-device
fastboot flash boot ./patched.img

And fastboot wait-for-device just sat there. Forever.

[*] Rebooting to bootloader...
[*] Waiting for fastboot...
< waiting for any device >

The phone was in fastboot mode — I could see it on the screen. The Mac was on the same Wi-Fi as before. But the connection was gone.

The reason is obvious once you say it out loud: fastboot is a USB-only protocol. adb has a TCP transport (that’s what wireless debugging is). fastboot doesn’t. When the bootloader takes over, the Android userspace that was hosting the adb daemon is gone, and with it the network stack. There’s nothing on the other end of the socket to talk to. The device is sitting two meters away from me speaking only over a cable that isn’t plugged in.

I knew this. I’ve known this for years. I still walked right into it because the entire session up to that point had been wireless and I’d built a small, smug mental model where “the phone is just a network endpoint.”

The mental model was wrong in a specific way worth naming: adb-over-Wi-Fi is a userspace service, not a property of the device. It exists because Android boots up and runs adbd listening on a TCP port. Anything that happens before userspace — bootloader, recovery in some configurations, fastbootd — has no such daemon and no such port. The transport vanishes the moment the OS does.

There’s a second-order lesson in the script I’d written. My pull-and-flash.sh chained adb reboot bootloader directly into fastboot flash with no checkpoint, no “is the cable in?” prompt, no fallback. The wireless-only flow had been so frictionless that I didn’t think to add one. The script encoded my bad assumption.

A better version would refuse to run unless fastboot devices already shows the phone over USB before the reboot — fail fast, before stranding the device in the bootloader. I’ll add that.

The fix in the moment was just: get up, find the cable, plug it in. The fix in the repo is to stop pretending the network is a substitute for a wire when the wire is the only protocol the bootloader speaks.

Cables are a transport, not a UX failure.