File Bridge 1.15.0 — a second wired path, when the phone will not give you adb

A second wired path, because the first one did not survive contact with the phone.

The problem

adb reverse is the better cable transport — loopback cannot be routed, so no
VPN can touch it. But the Honor this was built against never publishes an adb
interface. With USB debugging on, "Transfer files" selected and the cable
replugged, ioreg shows only:

MTP@0           255/255/0   vendor MTP
Mass Storage@1  8/6/80      "Linux File-CD Gadget" — HiSuite's autorun disc

adb's interface is class 255 / subclass 66 / protocol 1. It is not there, and
idProduct was identical before and after the replug, so the USB function set
was never rebuilt. adb devices stayed empty across a twelve-minute poll;
adb kill-server, adb usb and adb reconnect change nothing, because there
is no interface for them to talk to.

Read the descriptors before debugging the host. An absent interface and a
refused authorisation both look like "no devices" from adb devices and have
nothing in common — unauthorized means the interface is there and only the
Allow tap is missing.

USB tethering

Needs nothing from Developer options. Turn it on, and the panel spots the
192.168.42.x link by itself and offers a QR for it.

tether_ip() matches that fixed subnet — the one Android's USB tethering always
builds, phone at .129 — rather than guessing from interface names, which
differ per Mac. No second listener is needed: it is a real address on a real
interface, so the existing socket already answers there and correctly treats the
caller as a phone. Only the advertised address had to change, since lan_ip()
asks the routing table for one address and would keep printing the wifi one.

/qr.png?tether=1 encodes the tethered link. Needed because the adb path pairs
by firing a deep link at the phone, and with no adb there is nothing to fire
it with — so tethered pairing is a scan again. With no tether up, ?tether=1
falls back to the wifi address rather than emitting a broken link.

It is the weaker of the two, and the panel says so

Tethering is plain IP, so a full-tunnel VPN on the phone can swallow it exactly
as it swallows wifi. adb reverse cannot be routed at all. Prefer adb whenever
the phone will allow it.

	Wifi	Cable, via adb	Cable, via tethering
Needs	same wifi	USB debugging + one Allow tap	nothing in Developer options
Pairs by	QR	deep link fired over adb	QR (?tether=1)
A VPN can break it	yes	no	yes
Radio can sleep	yes	no	no

Also

• Android's isCable() counts a tethered address. It matched only loopback,
  so a 192.168.42.x link would have been filed in the wifi slot and
  overwritten the real one — the exact bug the two saved slots exist to prevent.

Still not faster

One hard number, from this release's own delivery: the phone pulled the 6.3 MB
APK over wifi at 17.34 MB/s. The cable negotiates USB 2.0 High Speed with
adb port-forwarding overhead on top. Wired is for not depending on the network.

Not verified

Tethering on real hardware. Detection, the tether status block, the tethered
QR and its decode were all exercised — but by pointing TETHER_NET at a subnet
the Mac was already on. Whether macOS brings up an interface for this phone at
all is unknown: it has no native RNDIS, though CDC-NCM it does support. The two
adb calls have never run against hardware either, for the reason above.
HANDOFF.md keeps both as the top open item.

Versions

Piece	Version
Server	1.14.0
Mac app	1.14.0
Android app	1.13.0 (versionCode 16)

Debug-signed. Installs and upgrades in place, not Play Store distributable.