Détection d'appareil dans Tradefed

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 par adb
  • 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 :

  1. L'appareil est reconnu comme deviceConnected et ouvert aux événements réguliers d' adb

  2. 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 ou OFFLINE .

  3. Si l'appareil est :

    • OFFLINE : l'appareil passera à l'état Tradefed CONNECTED_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 cycle ONLINE . Si nous recevons un événement deviceDisconnect , l'appareil sera simplement supprimé de la liste.

    • ONLINE (comme vu par adb) : l'appareil sera mis dans l'état CONNECTED_ONLINE et sa disponibilité sera vérifiée pour l'allocation de test : checking_availability .

  4. 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é comme unavailable 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).