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
{{ message }}
This repository was archived by the owner on Jan 10, 2023. It is now read-only.
More robust handling of duplicate CLOSE commands from device.
For some reason some devices will send a CLSE command multiple times
for the sme connection. It's not clear whether this is a bug in the
device or some poorly-documented "feature" of the adb protocol, or
a bug elsewhere in python-adb (possible, but I can't find it if so).
Nevertheless, the [protocol specs](https://android.googlesource.com/platform/system/core/+/master/adb/protocol.txt) state:
> A CLOSE message containing a remote-id which does not map to an
> open stream on the recipient's side is ignored. The stream may have
> already been closed by the recipient while this message was
> in-flight.
Thus, when opening a new connection, we should ignore any CLSE commands
that may still be on the wire for some reason. The current architecture
does not support multiple interleaved connections, and thus does not
keep track of the remote-ids of previous connections. We could do that,
but another approach is to send a monotonically increasing value for the
local-id of each connection, rather than repeatedly reusing 1. This
allows us to distinguish stray CLSE messages for a previous connection
from CLSE or OKAY messages in response to the current connection by
checking the remote-id (our local-id) of the command from the device.
I observed that an emulated device running Android 8.1 sometimes sent
multiple (2 or even 3) duplicate CLSE commands. Hence the while loop
until we get a command intended for the correct recipient.
0 commit comments