Hay algunas pistas en los detalles de la aplicación del ADB protocolo y resumen .
Al iniciarse la comunicación entre el servidor ADB en el host (PC) y el daemon ADB ( adbd ) en el dispositivo:
Ambos lados envían un mensaje CONNECT cuando se establece la conexión entre ellos.
Sintaxis de CONNECT mensaje es:
CONNECT(version, maxdata, "system-identity-string")
La cadena de identidad del sistema debe ser "<systemtype>:<serialno>:<banner>" donde systemtype es "bootloader", "device" o "host"
El estado de la conexión se establece cuando la cadena de identidad es analizado . device y host son evidentes, es decir, si el mensaje CONNECT es enviado por el dispositivo o por el host. No podemos ver host estado en el PC con un dispositivo Android en el otro lado porque es set sólo cuando no es ninguno de bootloader , device o tres estados de recuperación ( recovery , sideload y rescue ).
Para bootloader parte, parece que el BAD puede tener un "Implementación simplificada/incorporada... para entornos limitados, como el gestor de arranque" :
El cargador de arranque soportará dos flujos. Un flujo "bootloader:debug", que puede abrirse para obtener mensajes de depuración del gestor de arranque y un flujo "bootloader:control", que soportará el conjunto de comandos básicos del gestor de arranque.
También:
Los estados BOOTLOADER y RECOVERY corresponden a estados alternativos de los dispositivos cuando están en el modo bootloader o recovery.
Servidor ADB:
mantiene una lista de "dispositivos conectados" y asigna un "estado" a cada uno de ellos: OFFLINE, BOOTLOAD, RECOVERY u ONLINE
...
considera que un dispositivo está ONLINE cuando se ha conectado con éxito al programa adbd dentro de él. En caso contrario, el dispositivo está OFFLINE
Otros estados de conexión (disponibles hasta la fecha) incluyen:
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
Con la adición de authorizing y connecting afirma :
Anteriormente, los dispositivos hacían la transición de la siguiente manera:
offline -> unauthorized -> offline -> online
offline -> unauthorized (when actually unauthorized)
Con este parche:
connecting -> authorizing -> online
connecting -> authorizing -> unauthorized (when actually unauthorized)
Parece que ahora device offline sólo aparece cuando se produce un error AUTH tipo es solicitado o respondido por el cliente o el servidor ( 1 ) .
no permissions o connecting Los estados se establecen poco después de la conexión del dispositivo.
authorizing o unauthorized se fijan cuando AUTH El mensaje se transmite entre el cliente y el servidor.
unauthorized se establece si la(s) clave(s) privada(s) del host ha(n) fallado o si se espera la confirmación en pantalla del usuario para añadir una nueva clave pública.
Si no se detecta ninguno de los estados anteriores por cualquier motivo, se devuelve unknown .
