Le numéro gravé, et pas l’adresse ADB
Le même téléphone branché en USB puis repris en Wi-Fi faisait deux lignes dans l'inventaire. ADB ne nomme pas un appareil, il nomme une connexion, et seul le poste voit les deux noms à la fois.
L’inventaire du matériel se construit à partir des comptes rendus d’exécution. Un poste joue une préparation, remonte son journal, et les appareils qu’il a touchés rejoignent le parc. Il n’y a pas de seconde remontée dédiée à l’inventaire : deux canaux finiraient par se contredire, et personne ne saurait lequel croire.
Restait à savoir comment nommer un appareil.
Le piège
En USB, ADB désigne un appareil par son numéro de série, celui qui est gravé sur la coque. C’est une identité, elle est stable, c’est exactement ce qu’on veut.
En Wi-Fi ou en Ethernet, il le désigne par 192.168.0.22:5555. Ce n’est plus
une identité mais une adresse, et elle changera au prochain bail DHCP.
Les deux arrivent par le même champ. Un parc alimenté sans faire la différence grossit donc d’appareils qui n’existent pas : le même téléphone préparé lundi en USB et mardi sans fil fait deux lignes, et aucune des deux n’a l’historique complet.
Qui peut trancher
Le service ne peut rien démêler. Il reçoit une chaîne de caractères, et rien dedans ne dit si c’est un numéro ou une adresse. Un numéro de série peut contenir des chiffres et des points, donc une heuristique se tromperait une fois sur mille. Sur un parc de mille appareils, ça fait une ligne fausse.
Le poste, lui, voit les deux noms. Il parle à ADB, il sait par quel transport
il est passé, et il peut interroger l’appareil. Il envoie donc le numéro gravé
dans serial, et le nom du transport à côté quand la connexion passe par le
réseau. Le service ne décide rien, il range ce qu’on lui donne.
La décision vit dans un fichier à part, sans ADB ni quoi que ce soit autour, ce qui permet de l’éprouver sans câble.
Relire le numéro au lancement
Le suivi ADB interroge chaque appareil dès qu’il apparaît pour en obtenir le numéro. Mais cette lecture peut échouer, et elle ne se rejoue qu’à la reconnexion suivante. Un appareil apparu pendant un creux reste donc sans numéro jusqu’à ce qu’on le rebranche.
Le gestionnaire le redemande au lancement, et seulement pour les transports réseau. En USB, le nom que donne ADB est déjà le numéro, il n’y a rien à retrouver. Deux propriétés sont essayées dans l’ordre :
ro.serialno
ro.boot.serialno
La seconde parce que plusieurs constructeurs ne renseignent qu’elle depuis Android 10.
Si la lecture échoue, le lancement part quand même. Le compte rendu arrivera sous l’adresse, ce qui vaut mieux que pas de compte rendu du tout. Une ligne à rapprocher à la main reste une ligne, alors qu’un refus de démarrer efface l’information et la préparation avec.
Deux autres règles de la même famille
Un second envoi met à jour, il ne double pas. L’identifiant d’exécution du poste fait l’unicité, et les compteurs de l’inventaire ne bougent qu’à la création. Le poste peut donc réessayer autant qu’il veut sans rien avoir à compter lui-même.
Un journal en retard ne réécrit pas ce qu’on sait de plus récent. Le modèle, la version d’Android et le dernier résultat ne s’écrivent que depuis la préparation la plus récente. Sans ça, un rattrapage de trois semaines dirait « Android 13 » d’un téléphone passé en 14 entre-temps. Le poste envoie du plus ancien au plus récent, et le service se protège quand même.
Nexmesh