3

I recently employed the use of adb get-state and decided to know further about it. Running adb inter alia shows:

adb get-state                - prints: offline | bootloader | device

I intend to know under what circumstance(s) would that command return bootloader.

As of now I'm aware of these outputs:

  • device: booted into Android OS, debugging enabled and authorized
  • recovery: booted into recovery environment
  • sideload: during side-loading
  • unauthorized: booted into Android OS, debugging enabled but not authorized yet
  • offline: wireless device not in reach. (There may be other reasons.)
  • unknown: When adbd not detected at other side. At least that's what I understand of it. Occurs in case of debugging being disabled or device not plugged in.

I'm yet to know about the following two outputs:

  • host
  • bootloader

I found all those outputs here with no added explanation.

Before you ask,

  • yes, I've already ran that command when my Nexus 6 was booted into bootloader mode and I received unknown as output;
  • it is mere curiosity with nothing that it would solve in particular as of now.
  • If I may dare a guess, I'll say that the bootloader string can be outputted only if you find a way to start adbd after booting into the bootloader. This guess is based on the fact that, by issuing adb get-state from a Windows machine to a device booted into Android, I got unknown. Only by manually launching adbd on the Android with start adbd, was I able to have my Windows machine's adb outputting device. – Grimoire May 13 '16 at 8:15
  • @DeathMaskSalesman I don't think I'm following you. Consider addressing these points: 1) Did you verify on the device's screen that the device was indeed in bootloader mode? Which device did you use? 2) How were you able to start adbd at all? If you are talking about adb shell start adbd then it is technically impossible thing. – Firelord May 13 '16 at 9:14
  • The device output was obtained with the Android device booted into... Android. The main OS. Now, let's come to the two points: 1) Samsung devices' bootloader mode is the famed Odin mode, obtained by issuing adb reboot bootloader. My device is a Samsung Galaxy S4 Mini (GT-I9195, or serranoltexx); 2) As said in the prologue, starting adbd seems to be possible only from recovery or the OS itself. Launching it from the bootloader is one of my many crazy theories, but adb does not recognize a phone if in bootloader mode. – Grimoire May 13 '16 at 9:21
1

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.

Syntax of CONNECT message is:

CONNECT(version, maxdata, "system-identity-string")

The system identity string should be "<systemtype>:<serialno>:<banner>" where systemtype is "bootloader", "device", or "host"

The connection state is set when the identity string is parsed. device and 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 bootloader, device or three recovery states (recovery, sideload and rescue).

For 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.

Also:

The BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode.

ADB server:

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 authorizing and connecting states:

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.
authorizing or 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 unknown.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.