There are some hints in implementation details of ADB protocol and overview.
As communication starts between ADB server on host (PC) and ADB daemon (
adbd) on device:
Both sides send a CONNECT message when the connection between them is established.
CONNECT message is:
CONNECT(version, maxdata, "system-identity-string")
The system identity string should be
where systemtype is "bootloader", "device", or "host"
The connection state is set when the identity string is parsed.
host are obvious i.e. if the CONNECT message is sent by device or host. We can't see
host state on PC with an Android device on other side because it's set only when it's none of
device or three recovery states (
bootloader part, it seems that ADB can have a "simplified / embedded implementation... for limited environments, like the bootloader":
The bootloader will support two streams. A "bootloader:debug" stream, which may be opened to get debug messages from the bootloader and a "bootloader:control", stream which will support the set of basic bootloader commands.
The BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode.
maintains a list of "connected devices" and assigns a 'state' to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE
considers that a device is ONLINE when it has successfully connected to the adbd program within it. Otherwise, the device is OFFLINE
Other connection states (available to date) include:
Connecting Haven't received a response from the device yet.
Authorizing Authorizing with keys from ADB_VENDOR_KEYS.
Unauthorized ADB_VENDOR_KEYS exhausted, fell back to user prompt.
NoPerm Insufficient permissions to communicate with the device
With the addition of
Previously, devices would transition as follows:
offline -> unauthorized -> offline -> online
offline -> unauthorized (when actually unauthorized)
With this patch:
connecting -> authorizing -> online
connecting -> authorizing -> unauthorized (when actually unauthorized)
It seems that now
device offline state appears only when a wrong
AUTH type is requested or responded by client or server (1).
no permissions or
connecting states are set soon after device is connected.
unauthorized are set when
AUTH message is conveyed between client and server.
unauthorized is set either if host's private key(s) failed or if waiting for on-screen confirmation from user to add new public key.
If none of the above states is detected for any reason, it's returned