Commandes du shell de l'appareil

Lors des tests VTS, les commandes shell sont utilisées pour exécuter un binaire de test côté cible, pour obtenir/définir des propriétés, des variables d'environnement et des informations système, et pour démarrer/arrêter le framework Android. Vous pouvez exécuter des commandes de shell de périphérique VTS à l'aide de la commande adb shell ou du pilote de shell VTS exécuté sur le périphérique (recommandé).

Utilisation du shell ADB

Les tests qui nécessitent l'arrêt du port USB ou le redémarrage de l'appareil pendant le test doivent utiliser le shell ADB car le pilote du shell VTS n'est pas disponible sans une connexion USB persistante. Vous pouvez appeler le shell ADB à partir de l'objet AndroidDevice dans le script de test Python. Exemples:

  • Obtenez un objet d'appareil Android :
    self.device = self.android_devices[0]
    
  • Exécutez une seule commande shell :
    result = self.device.adb.shell(‘ls')
    

Utilisation du pilote de shell VTS

Le pilote de shell VTS est un binaire d'agent qui s'exécute sur le périphérique et exécute des commandes shell. Par défaut, VTS utilise le pilote shell si le pilote s'exécute sur le périphérique car cette méthode a moins de latence que l'utilisation de la commande adb shell .

Figure 1. Pilote de shell VTS.

Le framework VTS prend en charge les tests multi-appareils où chaque appareil Android est représenté sous la forme d'un objet AndroidDevice dans l'exécuteur de base. Par défaut, la structure VTS envoie les fichiers binaires de l'agent VTS et du pilote de shell VTS à chaque appareil Android et établit des connexions TCP avec les agents VTS sur ces appareils.

Pour exécuter une commande shell, le script Python côté hôte effectue un appel de fonction à l'objet ShellMirror dans l'objet AndroidDevice. L'objet ShellMirror regroupe les textes de la commande shell dans un message protobuf et l'envoie (via le canal TCP) à l'agent VTS sur l'appareil Android. L'agent s'exécutant sur l'appareil transmet ensuite la commande shell au pilote shell VTS via le socket Unix.

Lorsque le pilote de shell VTS reçoit une commande shell, il exécute la commande via nohup sur le shell de l'appareil pour éviter le blocage. Stdout, stderr et le code de retour sont ensuite extraits de nohup et renvoyés à l'agent VTS. Enfin, l'agent répond à l'hôte en enveloppant le(s) résultat(s) de la commande dans un message protobuf .

Avantages

Les avantages de l'utilisation du pilote shell VTS au lieu du adb shell incluent :

  • Fiabilité. Le pilote shell VTS utilise nohup pour exécuter des commandes sur le paramètre par défaut. Comme les tests VTS sont principalement des tests HAL et du noyau de niveau inférieur, nohup garantit que les commandes shell ne se bloquent pas pendant l'exécution.
  • Performances . Alors que la commande adb shell met en cache certains résultats (comme la liste des fichiers dans un répertoire), elle a une surcharge de connexion lors de l'exécution de tâches telles que l'exécution d'un binaire de test. Le pilote de shell VTS maintient une connexion active tout au long du test, de sorte que la seule surcharge est la communication USB. Lors de nos tests, l'utilisation du pilote shell VTS pour exécuter une commande avec 100 appels vers un binaire gtest vide est environ 20 % plus rapide que l'utilisation adb shell ; la différence réelle est plus grande puisque la communication du shell VTS a une journalisation étendue.
  • Maintien de l'État . Le pilote de shell VTS maintient une session de terminal pour chaque nom de terminal (le nom de terminal par défaut est default ). Les variables d'environnement définies dans une session de terminal ne sont disponibles que pour les commandes suivantes dans la même session.
  • Extensible . Les communications de commande Shell entre le framework VTS et le pilote de périphérique sont enveloppées dans protobuf pour permettre la compression potentielle, la communication à distance, le chiffrement, etc. à l'avenir. D'autres possibilités d'amélioration des performances sont également disponibles, notamment l'analyse des résultats côté périphérique lorsque la surcharge de communication devient supérieure à l'analyse des chaînes de résultats.

Désavantages

Les inconvénients de l'utilisation du pilote shell VTS au lieu du adb shell incluent :

  • Fichiers binaires supplémentaires . Les fichiers de l'agent VTS doivent être transmis à l'appareil et nettoyés après l'exécution du test.
  • Nécessite une connexion active . Si la connexion TCP entre l'hôte et l'agent est perdue pendant le test (en raison d'une déconnexion USB, d'un arrêt de port, d'une panne de périphérique, etc.), intentionnellement ou non, une commande shell ne peut pas être transmise à l'agent VTS. Même avec le passage automatique à adb shell , le résultat et l'état de la commande avant la déconnexion seraient inconnus.

Exemples

Exemples d'utilisation de commandes shell dans un script de test Python côté hôte VTS :

  • Obtenez un objet d'appareil Android :
    self.device = self.android_devices[0]
    
  • Obtenir un objet shell pour le périphérique sélectionné :
    self.shell = self.device.shell
    
  • Exécutez une seule commande shell :
    results = self.shell.Execute(‘ls')
    
  • Émettez une liste de commandes shell :
    results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
    

Objet de résultat de commande

L'objet de retour de l'exécution de la commande shell est un dictionnaire contenant les clés stdouts , stderrs et return_codes . Que la commande shell soit fournie sous la forme d'une chaîne unique ou d'une liste de chaînes de commande, chaque valeur du dictionnaire de résultats est toujours une liste.

Pour vérifier le code retour d'une liste de commandes, le script de test doit vérifier les indices. Exemple:

asserts.assertFalse(any(results[‘return_codes']), ‘some command failed.')

Alternativement, le script peut vérifier chaque index de commande individuellement. Exemple:

asserts.assertEqual(results[‘return_codes'][0], 0, ‘first command failed')
asserts.assertEqual(results[‘return_codes'][1], 0, ‘second command failed')