Commandes 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 d'appareil VTS à l'aide de la commande adb shell ou du pilote de shell VTS exécuté sur l'appareil (recommandé).

Utiliser l'interface système ADB

Les tests qui nécessitent d'arrêter le port USB ou de redémarrer 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 :

• Obtenir un objet d'appareil Android:

  self.device = self.android_devices[0]
  

• Exécutez une seule commande shell:

  result = self.device.adb.shell(‘ls')
  

Utiliser le pilote de shell VTS

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

Figure 1. Pilote de shell VTS.

Le framework VTS est compatible avec les tests multi-appareils, où chaque appareil Android est représenté par un objet AndroidDevice dans le runner de base. Par défaut, le framework VTS transfère les binaires de l'agent VTS et du pilote de 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 empaquette 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 transfère ensuite la commande shell au pilote de shell VTS via le socket Unix.

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

Avantages

Voici quelques avantages de l'utilisation du pilote de shell VTS au lieu de adb shell:

• Fiabilité. Le pilote de shell VTS utilise nohup pour exécuter des commandes avec 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 Bien que la commande adb shell mette en cache certains résultats (comme la liste des fichiers dans un répertoire), elle présente des frais généraux 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. Le seul inconvénient est la communication USB. Lors de nos tests, l'utilisation du pilote de shell VTS pour exécuter une commande avec 100 appels à un binaire gtest vide est environ 20 % plus rapide que l'utilisation de adb shell. La différence réelle est plus importante, car la communication du shell VTS génère des journaux étendus.
• Gestion de l'état Le pilote de shell VTS gère 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 ultérieures de la même session.
• Évolutivité Les communications de commande shell entre le framework VTS et le pilote de l'appareil sont encapsulées dans protobuf pour permettre une compression, une télécommande, un chiffrement, etc. potentiels à l'avenir. D'autres possibilités d'amélioration des performances sont également disponibles, y compris l'analyse des résultats côté appareil lorsque les frais généraux de communication deviennent plus importants que l'analyse de la chaîne de résultats.

Inconvénients

Voici quelques inconvénients de l'utilisation du pilote de shell VTS au lieu de adb shell:

• Binaires supplémentaires Les fichiers de l'agent VTS doivent être transférés sur l'appareil et nettoyés après l'exécution des tests.
• Connexion active requise. Si la connexion TCP entre l'hôte et l'agent est perdue pendant les tests (en raison d'une déconnexion USB, d'un arrêt de port, d'un plantage de l'appareil, etc.) intentionnellement ou non, une commande shell ne peut pas être transmise à l'agent VTS. Même avec le basculement automatique vers 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:

• Obtenir un objet d'appareil Android:

  self.device = self.android_devices[0]
  

• Obtenez un objet shell pour l'appareil sélectionné:

  self.shell = self.device.shell
  

• Exécutez une seule commande shell:

  results = self.shell.Execute(‘ls')
  

• Exécutez une liste de commandes shell:

  results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
  

Objet de résultat de commande

L'objet renvoyé par 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 seule chaîne 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 de 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.')

Le script peut également 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')