ADB protocol desync errors during concurrent operations

[nandor23]

Hello,

I'm experiencing ADB protocol-level errors that suggest the TCP stream gets out of sync:

* respones used 2561394801 for our local_id instead of 90260985
* got CLSE in respone instead of OKAY
* got WRTE in respone instead of OKAY

I'm running ADB commands simultaneously on multiple Android emulators, where each ADBTcpDevice instance connects to exactly one emulator. Once these errors occur, retrying commands on the same connection continues to fail with similar protocol mismatches.

Example code:

fn capture_framebuffer(device: &Arc<Mutex<ADBTcpDevice>>) -> ImageBuffer<Rgba<u8>, Vec<u8>> {
    loop {
        match device.lock().unwrap().framebuffer_inner() {
            Ok(framebuffer) => return framebuffer,
            Err(e) => {
                error!("Failed to capture framebuffer: {}. Retrying...", e);
                sleep(Duration::from_millis(500));
            }
        }
    }
}

After the first error, all retries fail with errors mentioned above. Each device has its own Arc<Mutex<ADBTcpDevice>> with only one thread using it, so this isn't a concurrency issue on my end.

Question:

What's the best way to handle this? Should the library recover automatically, or do I need to recreate the device connection when these errors occur? There doesn't seem to be a way to reset the session state on an existing connection.

[nandor23]

Update

Creating a new ADBTcpDevice for each ADB operation works fine and resolves my issue, but it's noticeably slower.

Further investigation

I'm new to Rust and ADB, so I asked Claude Opus 4.5 to help diagnose why reusing connections was failing.

Answer

The problem is likely within the adb_client library itself - specifically how it handles TCP stream state. Looking at the library's internals:

1. Sessions share the underlying TCP connection: When you call shell_command() or framebuffer_inner(), the library:

   • Creates an ADBSession that clones the TcpTransport
   • Both share the same Arc<Mutex> (the TCP socket)
   • On drop, sessions try to drain pending CLSE messages with only a 20ms timeout

2. The framebuffer_inner() is particularly risky: It reads ~2-3MB of framebuffer data. If this read is interrupted, times out, or errors partway through, there's leftover data in the TCP buffer that isn't fully cleared.

3. Under load, timing issues become more frequent: With multiple bots running:

   • More system load → more potential for timeouts
   • More context switching → more partial reads

Why Your Error Occurred

The error got WRTE in response instead of OKAY means:

• The code sent an OPEN command expecting OKAY
• Instead, it read a WRTE (write data) message that was leftover from a previous operation
• The TCP stream position was corrupted from a prior incomplete operation

Why The Fix Works

Creating a new TCP connection for each operation means:

• Each operation starts with a fresh, empty TCP buffer
• No state can carry over from previous failures
  I* f one framebuffer_inner() fails, the next operation uses a completely new socket

Is It an adb_client Bug?

Likely yes - the library doesn't seem to robustly handle:

• Partial reads/writes
• Error recovery that leaves the stream in a clean state
• Proper draining of unexpected messages
• The mutex you had was correct, but it can't fix corrupted internal TCP stream state within the single connection.