Commandes du shell de l'appareil

Pendant les 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 shell de périphérique VTS à l'aide de la commande adb shell ou du pilote shell VTS exécuté sur le périphérique (recommandé).

Utiliser le shell ADB

Les tests qui nécessitent l'arrêt du port USB ou le redémarrage de l'appareil pendant les tests 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 appareil Android :
    self.device = self.android_devices[0]
    
  • Émettez une seule commande shell :
    result = self.device.adb.shell(‘ls')
    

Utiliser le pilote shell VTS

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

Figure 1. Pilote shell VTS.

Le framework VTS prend en charge les tests multi-appareils où chaque appareil Android est représenté comme un objet AndroidDevice dans le base runner. Par défaut, le framework VTS envoie les binaires de l'agent VTS et du pilote shell VTS vers 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 commande shell dans un message protobuf et l'envoie (via le canal TCP) à l'agent VTS sur l'appareil Android. L'agent exécuté sur l'appareil transmet ensuite la commande shell au pilote shell VTS via le socket Unix.

Lorsque le pilote shell VTS reçoit une commande shell, il exécute la commande via nohup sur le shell du périphérique pour éviter le blocage. Stdout, stderr et le code retour sont ensuite récupérés de nohup et renvoyés à l'agent VTS. Enfin, l'agent répond à l'hôte en encapsulant 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 avec les paramètres par défaut. Comme les tests VTS sont pour la plupart des tests HAL et noyau de niveau inférieur, nohup garantit que les commandes shell ne se bloquent pas pendant l'exécution.
  • Performance . Bien que la commande adb shell mette en cache certains résultats (tels que la liste des fichiers dans un répertoire), elle entraîne une surcharge de connexion lors de l'exécution de tâches telles que l'exécution d'un binaire de test. Le pilote 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 à 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 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 de 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 une compression, un accès à distance, un cryptage, etc. potentiels à 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 :

  • Binaires supplémentaires . Les fichiers de l'agent VTS doivent être poussés vers 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 du 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 appareil Android :
    self.device = self.android_devices[0]
    
  • Obtenez un objet shell pour le périphérique sélectionné :
    self.shell = self.device.shell
    
  • Émettez 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 forme de chaîne unique ou de 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 index. 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')