You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Real adb (via the adb server) can enumerate all currently-reachable devices (adb devices, adb devices -l, host:track-devices), and modern Android's wireless debugging advertises itself over mDNS (_adb-tls-connect._tcp). droidsock has no discovery mechanism at all - it only connects to a specific host:port the caller already knows (today, sourced from a static references/devices.json).
Open question
Whether to implement a discovery/enumeration API (mDNS browsing, or some other reachable-device scan), or to continue relying entirely on the caller already knowing the host:port.
Decision: implement, mDNS discovery hand-written on dgram - no dependency
Two mechanisms fall under this issue, handled differently:
Classic fixed-port devices (current use case): a subnet/CIDR sweep of raw TCP connect attempts on a configurable port - trivial, needs nothing beyond Node's built-in net module.
Modern wireless-debugging devices (mDNS-advertised, _adb-tls-connect._tcp / _adb-tls-pairing._tcp from #3): implemented directly on Node's built-in dgram module (raw UDP multicast to 224.0.0.251:5353), not via a dependency. multicast-dns was evaluated and rejected on two independent grounds:
Maintenance:multicast-dns@7.2.5 was last published 2022-05-16. Its own runtime dependencies are equally stale - dns-packet@5.6.1 (2023-08-25) and thunky@1.1.0 (2019-10-14). Taking the dependency means four unmaintained packages, not one.
Scope fit:dns-packet is a full general-purpose DNS message codec (every common RR type) plus responder/announce logic for running your own mDNS service. droidsock only needs a query-only client - build one PTR question for a known service name, parse PTR/SRV/TXT/A answers out of the response (including DNS name-compression-pointer decoding). That's a small, well-specified slice of what the package provides, bounded and comparable in size to protocol work droidsock has already built from spec.
Failing both the maintenance bar and the scope-fit bar rules it out regardless of how well-known it is. The mDNS query/parse logic will be hand-written on top of dgram, consistent with the rest of droidsock's zero-runtime-dependency posture.
Design + implementation deferred until this is picked up in the actual work queue.
Activity
Shinrai commentedon Sep 2, 2026
Decision: implement, mDNS discovery hand-written on
dgram- no dependencyTwo mechanisms fall under this issue, handled differently:
Classic fixed-port devices (current use case): a subnet/CIDR sweep of raw TCP connect attempts on a configurable port - trivial, needs nothing beyond Node's built-in
netmodule.Modern wireless-debugging devices (mDNS-advertised,
_adb-tls-connect._tcp/_adb-tls-pairing._tcpfrom #3): implemented directly on Node's built-indgrammodule (raw UDP multicast to 224.0.0.251:5353), not via a dependency.multicast-dnswas evaluated and rejected on two independent grounds:multicast-dns@7.2.5was last published 2022-05-16. Its own runtime dependencies are equally stale -dns-packet@5.6.1(2023-08-25) andthunky@1.1.0(2019-10-14). Taking the dependency means four unmaintained packages, not one.dns-packetis a full general-purpose DNS message codec (every common RR type) plus responder/announce logic for running your own mDNS service. droidsock only needs a query-only client - build one PTR question for a known service name, parse PTR/SRV/TXT/A answers out of the response (including DNS name-compression-pointer decoding). That's a small, well-specified slice of what the package provides, bounded and comparable in size to protocol work droidsock has already built from spec.Failing both the maintenance bar and the scope-fit bar rules it out regardless of how well-known it is. The mDNS query/parse logic will be hand-written on top of
dgram, consistent with the rest of droidsock's zero-runtime-dependency posture.Design + implementation deferred until this is picked up in the actual work queue.
cldmv-bot commentedon Sep 3, 2026
Closed in v1.2.0 — resolved by #18.