yume-chan
[Feature Request] Support Android 11+ “Wireless debugging” (TLS + pairing code/QR)
Pre-issue checklist
- [x] I've searched the issue list but couldn't find the feature I want
How can Tango be improved?
On Android 11+ (including many TVs/boxes), Wireless debugging is no longer plain ADB over TCP (e.g. port 5555). It requires a pairing step (code or QR) and then runs ADB over a TLS channel.
This project works great when adbd is listening openly on a TCP port (legacy ADB over Wi-Fi), but it fails in standard Wireless debugging mode because the pairing + TLS layer is missing.
We’d like to know whether there is work in progress for Wireless debugging, and if not, whether you’re open to contributions. We can help implement and test on real Android TV / STB devices.
Our usage today (works well)
Runtime: Node.js (embedded in an Android app via a native Node runtime).
Connection: “Direct Sockets”, following the documented contract:
ReadableStream<AdbPacketData> via StructDeserializeStream(AdbPacket)
WritableStream<Consumable<AdbPacketInit>> via AdbPacketSerializeStream + WrapWritableStream
Transport: AdbDaemonTransport.authenticate({ serial, connection, credentialStore })
Auth:
PKCS#8 RSA credential store (persistent host key). We also support a single embedded host key for our fleet to avoid repeated prompts.
Optionally sending the public key first in legacy TCP mode to trigger the approval prompt.
ADB usage:
Subprocess via subprocess.noneProtocol.spawnWaitText([...])
How should the API change?
Proposed direction (API sketch)
New device, e.g. AdbWirelessDevice or AdbDaemonTlsDevice, providing:
pair({ host, pairingPort, code | qr, credentialStoreForTls })
connect({ host, tlsPort, tlsCredentials }) → returns packetized ADB streams over TLS
Optional mDNS discovery (_adb-*_tcp) for convenience (Node/browser), or accept explicit parameters for a first iteration.
A TLS credential store distinct from the ADB RSA host key store.
Keep AdbDaemonTransport as-is; it consumes ADB packet streams regardless of the underlying transport.
(Optional) Other information
Do you already have an internal prototype/branch for Wireless debugging (pairing + TLS) on Android 11+?
Thanks for the excellent packetized ADB stack (StructDeserializeStream / AdbPacketSerializeStream + Consumable streams). We’d be happy to help bring Wireless debugging (Android 11+) support if it isn’t already underway.
CurseGroup Company teams
It requires a pairing step (code or QR) and then runs ADB over a TLS channel.
I know it has a pretty complicated pairing process, and usesTLS with client certificate for connection.
We’d like to know whether there is work in progress for Wireless debugging,
I'm not working on it because I'm using Google ADB to connect to Wireless Debugging devices. We have APIs for pairing and mDNS in Google ADB client module.
and if not, whether you’re open to contributions.
Yes. Any help is welcomed.
A TLS credential store distinct from the ADB RSA host key store.
Doesn't Google ADB use the same key for both traditional authentication and TLS client certificate?
connect({ host, tlsPort, tlsCredentials }) → returns packetized ADB streams over TLS
I did some investigations before, and I found https://github.com/reclaimprotocol/tls might be suitable for a cross-runtime implementation.
But using Node.js built-in tls module should also be fine, since browser's TCP socket support doesn't seem to happen anytime soon, and once we implemented the core logic, swapping the TLS implementation shouldn't be difficult.
Optional mDNS discovery (_adb-*_tcp) for convenience (Node/browser),
I also want that but hasn't found any decent mDNS library on NPM. mDNS shouldn't require periodic scanning but many libraries are doing that.
It uses DNS multicast so also no need to care about browsers.
Keep AdbDaemonTransport as-is;
Its constructor can be used to create an instance from an already authenticated stream pair.
Hi, how is it going?
In next version (v3) I separated the current authentication process from AdbDaemonTransport class (as AdbDaemonAuthenticator, done in #810), so it makes more sense to add another authenticator (for example AdbDaemonWirelessDebuggingAuthenticator) in future.
In #780 I changed the private key format to only contain n and d, but this can be easily reverted, or change to JWK formatted keys to support TLS libraries.