Il y a quelques indices dans les détails de la mise en œuvre de la BAD. protocole y vue d'ensemble .
Lorsque la communication commence entre le serveur ADB sur l'hôte (PC) et le démon ADB ( adbd ) sur le dispositif :
Les deux parties envoient un message CONNECT lorsque la connexion entre elles est établie.
Syntaxe de CONNECT Le message est :
CONNECT(version, maxdata, "system-identity-string")
La chaîne d'identité du système doit être "<systemtype>:<serialno>:<banner>" où systemtype est "bootloader", "device", ou "host".
L'état de la connexion est défini lorsque la chaîne d'identité est analysé . device y host sont évidentes, c'est-à-dire si le message CONNECT est envoyé par le périphérique ou l'hôte. Nous ne pouvons pas voir host sur un PC avec un appareil Android de l'autre côté car c'est set seulement quand ce n'est pas bootloader , device ou trois états de récupération ( recovery , sideload y rescue ).
Pour bootloader partie, il semble que l'ADB puisse avoir un "implémentation simplifiée / embarquée... pour des environnements limités, comme le bootloader" :
Le chargeur de démarrage prendra en charge deux flux. Un flux "bootloader:debug", qui peut être ouvert pour obtenir des messages de débogage du bootloader et un flux "bootloader:control", qui supportera l'ensemble des commandes de base du bootloader.
Aussi :
Les états BOOTLOADER et RECOVERY correspondent aux états alternatifs des dispositifs lorsqu'ils sont en mode bootloader ou recovery.
Serveur ADB :
maintient une liste de "dispositifs connectés" et attribue un "état" à chacun d'entre eux : OFFLINE, BOOTLOADER, RECOVERY ou ONLINE
...
considère qu'un périphérique est ONLINE lorsqu'il s'est connecté avec succès au programme adbd qu'il contient. Sinon, le périphérique est OFFLINE
Autre états de connexion (disponibles à ce jour) comprennent :
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
Avec le l'ajout de authorizing y connecting États :
Auparavant, les appareils effectuaient la transition comme suit :
offline -> unauthorized -> offline -> online
offline -> unauthorized (when actually unauthorized)
Avec ce patch :
connecting -> authorizing -> online
connecting -> authorizing -> unauthorized (when actually unauthorized)
Il semble que maintenant device offline n'apparaît que lorsqu'une erreur AUTH est demandé ou répondu par le client ou le serveur ( 1 ) .
no permissions ou connecting Les états sont définis peu après la connexion du dispositif.
authorizing ou unauthorized sont fixés lorsque AUTH le message est transmis entre le client et le serveur.
unauthorized est défini soit si la ou les clés privées de l'hôte ont échoué, soit si l'on attend la confirmation à l'écran de l'utilisateur pour ajouter une nouvelle clé publique.
Si aucun des états ci-dessus n'est détecté pour une raison quelconque, il est retourné unknown .
