Cette page a été traduite par l'API Cloud Translation.

Commandes shell de l'appareil

Lors des tests VTS, les commandes shell sont utilisées pour exécuter un 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 le shell VTS de l'appareil à l'aide de la commande adb shell ou du pilote shell VTS en cours d'exécution sur l'appareil (recommandé).

Utiliser le shell ADB

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 un une connexion USB persistante. Vous pouvez appeler le shell ADB à partir de 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')
```

Utiliser le pilote shell VTS

Le pilote du shell VTS est un binaire d'agent qui s'exécute sur l'appareil commandes shell. Par défaut, VTS utilise le pilote shell si le pilote est en cours d'exécution sur l'appareil, car cette méthode offre une latence moindre par rapport à 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 Base Runner. Par défaut, VTS le framework transmet les binaires de l'agent VTS et du pilote du 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 crée une fonction à l'objet ShellMirror dans l'objet AndroidDevice. The ShellMirror empaquette les textes de la commande shell dans protobuf et l'envoie (via le canal TCP) à l'agent VTS sur le appareil. L'agent exécuté sur l'appareil transmet ensuite la commande shell au 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 de l'appareil pour éviter tout blocage. Stdout, stderr et le code de retour sont alors récupéré à nohup et renvoyé à 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

L'utilisation du pilote shell VTS au lieu de adb shell présente les avantages suivants:

Fiabilité. Le pilote shell VTS utilise nohup pour exécuter des commandes selon le paramètre par défaut. Comme les tests VTS sont la plupart du temps des tests HAL et du noyau de niveau inférieur, nohup assure le shell. les commandes ne se figent pas lors de l'exécution.
Performances : La commande adb shell met en cache certains résultats (comme lister les fichiers d'un répertoire), elle dispose d'une connexion lors de l'exécution de tâches telles que l'exécution d'un binaire de test. Pilote shell VTS maintient une connexion active tout au long du test, de sorte que la seule surcharge est USB de la communication. Lors de nos tests, utiliser le pilote shell VTS pour exécuter une commande avec 100 appels vers un binaire gtest vide est environ 20 % plus rapide qu'en utilisant adb shell; la différence réelle est plus importante, car le shell VTS comporte des journaux détaillés.
Garder l'état. Le pilote du shell VTS gère un terminal session 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 disponible uniquement pour les commandes suivantes dans la même session.
Extendable : Communications des commandes shell entre VTS le framework et le pilote d'appareil sont encapsulés dans un tampon de protocole pour permettre la compression, la communication à distance, le chiffrement, etc. à l'avenir. D'autres possibilités pour améliorer les performances, y compris l'analyse des résultats côté appareil lorsque la surcharge de la communication devient supérieure à l'analyse de la chaîne de résultats.

Inconvénients

L'utilisation du pilote shell VTS au lieu de adb shell présente les inconvénients suivants:

Binaires supplémentaires. Les fichiers de l'agent VTS doivent être transférés vers et nettoyées après l'exécution du test.
Nécessite une connexion active. Si la connexion TCP entre l'hôte et l'agent sont perdus pendant les tests (déconnexion USB, port plantage de l'appareil, etc.), qu'une commande shell ne peuvent pas être transmises à l'agent VTS. Même avec le passage automatique à adb shell : le résultat et l'état de la commande avant déconnexion serait inconnue.

Exemples

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

Obtenez 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')
```

Émettez la liste des commandes shell:

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

Objet de résultat de la commande

L'objet renvoyé lors de l'exécution d'une commande shell est un dictionnaire contenant 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 renvoyé 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 commandes individuellement. Exemple :

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

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