Bound the blocking so a peer that vanishes cannot wedge the connection

[3c71]

Problem

None of the blocking in this library can time out, so a peer that goes away without closing the TCP connection — the normal outcome of a Wi-Fi drop, which delivers no FIN — wedges the whole connection permanently, with no way to cancel or recover.

Concretely, on master (and in 3.1.1):

Where	What
AdbConnection ctor	new Socket(host, port) — no connect timeout, no setSoTimeout, no setKeepAlive
connection thread	parks forever in Message.parse() and never reaches its own cleanup
open()	waitForConnection(Long.MAX_VALUE, …) then a bare stream.wait()
getMaxData()	waitForConnection(Long.MAX_VALUE, …) — and it is called on every AdbStream.write()
AdbStream.write()	bare wait() for the OKAY, holding the stream monitor
close()	untimed mConnectionThread.join(), so even disconnect() can hang
PairingConnectionCtx	new Socket(host, port) + readFully() with no read timeout

What makes this unrecoverable rather than merely slow is that the connection thread is the thing that wakes everyone else: when it exits it runs cleanupStreams() + notifyAll(), which wakes open()'s stream.wait(), AdbStream.read()'s mReadQueue.wait() and write()'s wait(). While that thread is stuck in a kernel read no other waiter can ever make progress — and disconnect() cannot break in either, because AbsAdbConnectionManager serialises connect/openStream/disconnect on one lock that the stuck call is holding.

We hit this in an app that keeps a long-lived ADB shell open over wireless ADB. Every Wi-Fi hiccup left the app permanently frozen; the only recovery was a force-stop.

Fix

Six small commits, each independently reviewable:

1. Message.parse() timeout safety — a prerequisite. parse() reads header and payload with partial-read loops, so a SocketTimeoutException raised part-way through would discard consumed bytes and desynchronise the stream. It now only propagates when nothing has been read for the current message; once committed to a message it waits for the rest regardless. Callers can therefore treat it as "nothing arrived yet" and safely retry. No behaviour change without a read timeout set.
2. AdbConnection — explicit bounded connect(), setSoTimeout, setKeepAlive; bounded open(), getMaxData() and close().
3. AdbStream — bounded write(); track whether the OPEN was acknowledged, so open() can tell an acknowledgement from a timeout (Object.wait(long) cannot report which woke it).
4. AbsAdbConnectionManager — setTimeout() now governs the whole set-up path, not only the CNXN handshake.
5. PairingConnectionCtx — bounded pairing connect and reads.
6. waitForConnection() deadline overflow — System.currentTimeMillis() + unit.toMillis(timeout) overflows negative for the Long.MAX_VALUE default, so the wait loop is skipped and connect() reports failure before CNXN completes. Any caller that never calls setTimeout() gets false back from connect() today; the ones that appear to work only do so because they ignore the return value and the following openStream() waits again. Saturating arithmetic, plus the already-clamped getConnectTimeout() instead of the raw mTimeout.

Deliberate non-changes

• A read timeout is not treated as a dead connection. An ADB link is legitimately silent for long stretches — a shell session producing no output — so the connection thread simply resumes waiting. The timeout exists only so the thread returns to the top of its loop periodically, making close() and interrupt() effective.
• AdbStream.read() stays blocking. That is the right semantic for a shell session, and it is already woken by cleanupStreams() when the connection dies.
• sendPacket() is untouched. It writes to the socket while holding mLock, and Java sockets have no send timeout, so a full send window can still stall a writer. Worth knowing about; out of scope here.

Compatibility

Source- and binary-compatible. Timeouts are configurable via new AdbConnection.Builder setters (setConnectTimeout, setSocketTimeout, setResponseTimeout) and default to 30s. The one intentional behaviour change is that the previous defaults were effectively infinite; a caller that never set a timeout now gets a finite one rather than an unbounded wait.

Testing

./gradlew :libadb:assembleRelease passes.

Exercised on a real device over wireless ADB in the app described above, which uses the library two ways at once: a long-lived shell,-n,-T: stream for its background helper, and interactive shell: sessions in a terminal UI. Both behave normally with the timeouts in place — no truncated output on chatty commands, no sessions cut short while idle, pairing unaffected.

To be explicit about what I have not done: I have not yet reproduced the original wedge (Wi-Fi dropped mid-command, no FIN) against this build to time the recovery. The reasoning for that path is from reading the code, not from a measured run, so please weigh commits 2–5 accordingly. Commit 1 and commit 6 are self-contained and verifiable by inspection.