[ba6ul]

Refs #28

What

One classification of how adb reaches a device (USB, ip:port, wireless debugging, emulator), used by the daemon and the UI, so Go Wireless and Handoff are offered only for a phone on USB.

Why

isNetwork was "serial contains :". A wireless-debugging serial (adb-<serial>-<suffix>._adb-tls-connect._tcp) and an emulator serial (emulator-5554) have no colon, so both were treated as USB: logged "connected via USB", listed with Go Wireless and Handoff in the UI, and accepted by the daemon. Reproduced against a real emulator before the change: Go Wireless for emulator-5554 was accepted, restarted the emulator's adbd, then tried adb connect to the host's LAN gateway (192.168.1.1:5555) and to 10.0.2.16:5555.

How

• AdbTransport { usb, network, mdns, emulator } in core, with AdbTransport.of(serial). emulator-<digits> is an emulator; adb-<serial>-<suffix>._adb-tls-connect._tcp is mDNS; anything else with a colon is a network address (IPv4, bracketed IPv6); the rest is USB. Lookalikes (emulator-abc, adb-... without the service name, the pairing service) fall to USB rather than guess.
• AdbDevice.transport, canGoWireless (USB only) and hardwareSerial (USB: the serial; mDNS: the embedded part; network and emulator: null, since an emulator's ro.serialno is not its adb serial). isNetwork keeps its meaning for existing callers: an ip:port address.
• Daemon: every device entry in the devices snapshot carries transport (additive; the UI parser ignored unknown keys). Go Wireless and Handoff are refused for anything but USB with a reason (started: false plus a failed status event) before anything is sent to adb. The log says how each device is connected. u (USB-only) is refused for mDNS and emulators over IPC and skipped by the u key; for ip:port it now splits host and port at the last colon, so a bracketed IPv6 address works. The w and h keys pick only USB phones.
• UI: Device.transport is what the daemon reports, with a fallback worked out from the serial for a daemon that sends none (the same rules, tested on the same serials as core). Go Wireless and Handoff show only for USB; the other kinds are labelled (wireless, wireless debugging, emulator).
• Not changed: the reconnector and the stale cached address (Reconnector: backoff, try current gateways, filter non-private gateways #27, Same physical phone gets multiple concurrent scrcpy instances across USB/wireless serials (confirmed, with zombie process accumulation) #4), duplicate listing of one phone (Same physical phone gets multiple concurrent scrcpy instances across USB/wireless serials (confirmed, with zombie process accumulation) #4), the identity fix from UI: no duplicate row for a listed phone, show Try Now results, name the app Voyager #40. hardwareSerial exists for Same physical phone gets multiple concurrent scrcpy instances across USB/wireless serials (confirmed, with zombie process accumulation) #4 but nothing uses it yet.

Verified by

Physical phone (Pixel 10a) and a real emulator, both tested live. All with an isolated daemon config and autoLaunch off.

• Emulator, booted headless from a temporary AVD (Android 35 google_apis_playstore x86_64) on a separate adb server on port 5038, never the owner's server on 5037. The AVD, emulator and server were removed afterwards; nothing else was changed.
  • Serial emulator-5554; ro.kernel.qemu=1; ro.serialno EMULATOR36X4X9X0 (differs from the serial).
  • The branch's daemon reports transport: emulator and logs "connected via emulator". Go Wireless, Handoff and USB-only for it are refused with a reason. The emulator was untouched: same adb transport id before and after, no TCP port opened.
  • Before this change on the same emulator: accepted as USB, adbd restarted, connects to the LAN gateway.
  • Also observed: after adb tcpip and adb connect 127.0.0.1:5555 adb lists the same emulator twice (emulator-5554 and 127.0.0.1:5555, same ro.serialno). That is Same physical phone gets multiple concurrent scrcpy instances across USB/wireless serials (confirmed, with zombie process accumulation) #4, not changed here.
• Physical phone on wireless debugging, read-only (the daemon only lists it and reads its model, as it always did): reports transport: mdns, logs "connected via wireless debugging", Go Wireless and Handoff refused with a reason, phone untouched (same transport id, no TCP port). No tcpip, usb or disconnect was run against it.
• Not tested live: the phone's plain USB serial (the cable was not connected; the form is evidenced by the daemon's own cache written when it was on USB, and ro.serialno equals the serial embedded in the mDNS name), ip:port for this phone (tcpip is off), and how adb answers tcpip / usb: / disconnect on an mDNS transport.
• Tests: core 39 (+12: real serials, lookalikes, hardware serial, device getters); daemon 102 (+5 process-level tests against the fake adb with one device of each kind: transports reported, how each is logged, refusals with nothing sent to adb (tcpipRequests stays 0), a USB phone still accepted, USB-only refused for emulator and mDNS); ui 57 (+25: the fallback on the same serial list as core, JSON with/without/unknown transport, which buttons each row shows). ipc 26. dart analyze and flutter analyze clean.
• With the daemon's gate disabled the refusal test fails; with the UI's gate disabled two widget tests fail.
• CI results are in the checks below.

Risk / follow-ups

• The classification is by serial shape. A future adb naming that matches none of the patterns is treated as USB, which is today's behaviour for unknown shapes.
• The UI keeps a small copy of the rules for the missing-transport case; the two are tied together by the shared serial list, not by code.
• Stale cached address and the changed DHCP address (192.168.1.6 cached, phone now 192.168.1.8) are Reconnector: backoff, try current gateways, filter non-private gateways #27 / Same physical phone gets multiple concurrent scrcpy instances across USB/wireless serials (confirmed, with zombie process accumulation) #4. Not part of this PR.