Une nouvelle connexion d'appareil déclenche une série d'événements asynchrones qui ne sont pas évidents mais qui méritent d'être compris.
Connecté physiquement
Tradefed utilise la bibliothèque ddmlib
(une bibliothèque Java adb
) pour fournir l'interaction de base avec adb
et les appareils. Une partie de cette solution est l' interface IDeviceChangeListener qui permet la réception de nouveaux événements de périphérique, tels que :
-
deviceConnected
: lorsqu'un nouvel appareil est vu paradb
-
deviceDisconnected
: lorsqu'un appareil ne signale plus àadb
-
deviceChanged
: lorsqu'un état majeur de l'appareil se produit (tel qu'un appareil hors ligne ou un appareil en ligne)
Ces événements sont suffisants au niveau adb
pour décider si un appareil est connecté ou non, en ligne ou hors ligne. Mais pour le harnais de test, nous avons besoin d’un état plus fort que cela pour garantir qu’un appareil est vraiment prêt à commencer à exécuter des tests ; il ne devrait pas être affecté par les défauts d’état potentiels pouvant survenir avec un appareil nouvellement connecté.
Voici la séquence des événements dans Tradefed :
- L'appareil est reconnu comme
deviceConnected
et ouvert aux événements réguliers d'adb
Un événement interne Tradefed est créé pour :
- Vérifiez si l'appareil est déjà connu ; Tradefed conserve une référence interne à certains appareils (en particulier celui actuellement alloué et en cours d'exécution des tests) pour éviter que TF en perde la trace de manière aléatoire.
- Vérifiez si l'appareil est
ONLINE
ouOFFLINE
.
Si l'appareil est :
OFFLINE
: l'appareil passera à l'état TradefedCONNECTED_OFFLINE
, ce qui ne permettra pas encore à l'appareil d'exécuter des tests. Si l'appareil est en ligne plus tard, il passera par le cycleONLINE
. Si nous recevons un événementdeviceDisconnect
, l'appareil sera simplement supprimé de la liste.ONLINE
(comme vu par adb) : l'appareil sera mis dans l'étatCONNECTED_ONLINE
et sa disponibilité sera vérifiée pour l'allocation de test :checking_availability
.
Si le contrôle
availability
réussit, l'appareil sera marqué comme disponible pour l'allocation de test ; il pourra exécuter des tests. Dans le cas contraire, l'appareil sera marqué commeunavailable
pour l'attribution et ne pourra recevoir aucun test.
Tous ces états sont reflétés dans la console Tradefed lors de la liste des appareils via : tf> list devices
Il est important de noter que lorsque l'appareil est actuellement alloué à un test, la plupart des événements ci-dessus ne se produiront pas et Tradefed déterminera l'état de l'appareil en interne. Il est donc possible qu'un appareil disparaisse des adb devices
tout en étant toujours répertorié par Tradefed. Cela peut se produire lorsqu'un test consiste à redémarrer l'appareil par exemple.
Appareil virtuel connecté avec adb connect
Lorsqu'un appareil virtuel distant est créé, Tradefed s'y connecte à l'aide de adb connect
. Cela déclenchera généralement l'affichage du périphérique dans adb devices
sous le nom <some ip>:<port number>
et suivra la même séquence que les périphériques physiquement connectés.
Suivi de l'appareil lorsqu'un événement deviceConnected se produit
Lorsque deviceConnected
se produit, ddmlib
crée un nouvel IDevice de référence pour suivre le périphérique nouvellement connecté.
Tradefed utilise cette référence et l'intègre dans sa propre implémentation de l'interface de périphérique ITestDevice pour fournir un service plus avancé. Mais l'IDevice sous-jacent est toujours celui provenant de ddmlib
.
Cela signifie que si un nouvel appareil est connecté, un nouveau ITestDevice est créé et associé à l'IDevice. Lorsque cela se produit lors d’un appel et que ITestDevice est utilisé, l’IDevice sous-jacent est toujours remplacé afin que les tests puissent se poursuivre sur la référence appropriée. Cela se fait de manière transparente chaque fois qu'un périphérique est déconnecté/reconnecté (par exemple, lors d'un redémarrage).