Commandes du shell de périphérique

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 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 du périphérique 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')
    

Utilisation du pilote shell VTS

Le pilote 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 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 runner de base. Par défaut, le framework VTS pousse les binaires de l'agent VTS et du pilote du shell VTS vers chaque périphérique Android et établit des connexions TCP avec les agents VTS sur ces périphériques.

Pour exécuter une commande shell, le script Python côté hôte effectue un appel de fonction à l'objet ShellMirror à l'intérieur de l'objet AndroidDevice. L'objet ShellMirror rassemble 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 le périphérique transmet ensuite la commande shell au pilote shell VTS via le socket Unix.

Lorsque le pilote du 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 code de 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 du shell VTS au lieu du adb shell incluent:

  • Fiabilité. Le pilote du shell VTS utilise nohup pour exécuter des commandes sur 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 . 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 test binaire. Le pilote du shell VTS maintient une connexion active tout au long du test, de sorte que la seule surcharge est la communication USB. Dans 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 du shell VTS maintient une session de terminal pour chaque nom de terminal (le nom de terminal par défaut est la valeur par défaut ). 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 la compression potentielle, la communication à distance, le cryptage, etc. à l'avenir. D'autres possibilités pour améliorer les performances sont également disponibles, notamment l'analyse des résultats côté périphérique lorsque la surcharge de communication devient plus importante que l'analyse de la chaîne de résultats.

Désavantages

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

  • Binaires supplémentaires . Les fichiers de l'agent VTS doivent être poussés vers le périphérique 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 au 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 la 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.')

Sinon, 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')