What represents 'bootloader' in the possible outputs of `adb get-state`? 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.
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 "&lt;systemtype&gt;:&lt;serialno&gt;:&lt;banner&gt;"
  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 -&gt; unauthorized -&gt; offline -&gt; online
  offline -&gt; unauthorized (when actually unauthorized)

  
  With this patch:

  connecting -&gt; authorizing -&gt; online
  connecting -&gt; authorizing -&gt; 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.