Diese Seite wurde von der Cloud Translation API übersetzt.

Geräte-Shell-Befehle

Während der VTS-Tests werden Shell-Befehle verwendet, um einen zielseitigen Test auszuführen binär, um Eigenschaften, Umgebungsvariablen und Systeminformationen abzurufen und festzulegen, und das Android-Framework starten/beenden. Sie können die VTS-Geräte-Shell ausführen Befehle mit dem Befehl adb shell oder dem VTS-Shell-Treiber auf dem Gerät ausgeführt wird (empfohlen).

ADB-Shell verwenden

Tests, bei denen währenddessen der USB-Port heruntergefahren oder das Gerät neu gestartet werden muss Für die Tests muss die ADB-Shell verwendet werden, da der VTS-Shell-Treiber ohne eine eine dauerhafte USB-Verbindung. Sie können die ADB-Shell über die AndroidDevice-Objekt im Python-Testskript. Beispiele:

Rufen Sie ein Android-Geräteobjekt ab:
```
self.device = self.android_devices[0]
```
Führen Sie einen einzelnen Shell-Befehl aus:
```
result = self.device.adb.shell(‘ls')
```

VTS-Shell-Treiber verwenden

Der VTS-Shell-Treiber ist eine Agent-Binärdatei, die auf dem Gerät ausgeführt wird. Shell-Befehle verwenden können. Standardmäßig verwendet VTS den Shell-Treiber, wenn der Treiber ausgeführt wird auf dem Gerät gespeichert, da diese Methode eine geringere Latenz hat als der Befehl adb shell.

Abbildung 1: VTS-Shell-Treiber

Das VTS-Framework unterstützt Tests auf mehreren Geräten, bei denen jedes Android-Gerät wird im Basis-Runner als AndroidDevice-Objekt dargestellt. Standardmäßig liefert VTS das Framework überträgt die Binärdateien des VTS-Agents und der VTS-Shell-Treiber auf jedes Android-Gerät. und stellt TCP-Verbindungen zu den VTS-Agents auf diesen Geräten her.

Zum Ausführen eines Shell-Befehls erstellt das Python-Skript auf Hostseite eine Funktion an das ShellMirror-Objekt im AndroidDevice-Objekt. ShellMirror -Objekt packt die Shell-Befehlstexte in ein protobuf und sendet sie über den TCP-Kanal an den VTS-Agent auf dem Android- . Der Agent, der auf dem Gerät ausgeführt wird, leitet dann den Shell-Befehl an die VTS-Shell weiter über den Unix-Socket.

Wenn der VTS-Shell-Treiber einen Shell-Befehl empfängt, wird der folgende Befehl ausgeführt: über nohup auf um zu verhindern, dass das Gerät aufhängt. „stdout“, „stderr“ und „return code“ werden von nohup abgerufen und an den VTS-Agent zurückgesendet. Schließlich hat der Kundenservicemitarbeiter dem Host antwortet, indem sie die Befehlsergebnisse in einen protobuf-Nachricht.

Vorteile

Die Verwendung des VTS-Shell-Treibers anstelle von adb shell bietet unter anderem folgende Vorteile:

Zuverlässigkeit: Der VTS-Shell-Treiber verwendet nohup, um Befehle für die Standardeinstellung auszuführen. Da VTS-Tests hauptsächlich HAL- und Kernel-Tests auf niedrigerer Ebene. nohup stellt die Shell sicher. bleiben Befehle während der Ausführung nicht hängen.
Leistung: Der Befehl adb shell speichert einige Ergebnisse im Cache (z. B. Auflistung von Dateien in einem Verzeichnis), da eine Verbindung besteht. bei der Ausführung von Aufgaben wie dem Ausführen einer Testbinärdatei. VTS-Shell-Treiber hält während des Tests eine aktive Verbindung aufrecht, sodass der einzige Overhead USB-Speicher ist. Kommunikation. In unseren Tests haben wir mit dem VTS-Shell-Treiber einen Befehl mit 100 Aufrufe einer leeren gtest-Binärdatei sind etwa 20 % schneller als bei Verwendung von adb shell; ist der tatsächliche Unterschied größer, da die VTS-Shell -Kommunikation umfasst eine umfangreiche Protokollierung.
Statuskontrolle. Der VTS-Shell-Treiber verwaltet ein Terminal. Sitzung für jeden Terminalnamen (Standard-Terminalname ist default. Umgebungsvariablen, die in einer Terminalsitzung festgelegt werden, sind nur für nachfolgende Befehle in derselben Sitzung verfügbar.
Erweiterbar. Kommunikation mit Shell-Befehlen zwischen VTS Framework und Gerätetreiber sind in protobuf eingebunden, um Komprimierung, Remoting, Verschlüsselung usw. Andere Möglichkeiten für sind ebenfalls verfügbar, darunter das Parsen von Ergebnissen auf Geräteseite. wenn der Kommunikationsaufwand größer wird als das Parsen von Ergebniszeichenfolgen.

Nachteile

Die Verwendung des VTS-Shell-Treibers anstelle von adb shell hat folgende Nachteile:

Zusätzliche Binärprogramme. VTS-Agent-Dateien müssen per Push übertragen werden an und nach der Testausführung bereinigt.
Aktive Verbindung erforderlich. Wenn die TCP-Verbindung zwischen Host und Agent werden während des Tests verloren (aufgrund der Trennung von USB, Herunterfahren des Ports, Geräteabsturz usw.), die absichtlich oder unabsichtlich durch einen Shell-Befehl kann nicht an den VTS-Agent übertragen werden. Auch bei einem automatischen Wechsel zu adb shell, das Ergebnis und der Status des Befehls vor dem Trennen der Verbindung wäre unbekannt.

Beispiele

Beispiele für die Verwendung von Shell-Befehlen in einem Python-Testskript auf Hostseite von VTS:

Rufen Sie ein Android-Geräteobjekt ab:
```
self.device = self.android_devices[0]
```
Rufen Sie ein Shell-Objekt für das ausgewählte Gerät ab:
```
self.shell = self.device.shell
```
Führen Sie einen einzelnen Shell-Befehl aus:
```
results = self.shell.Execute(‘ls')
```

Führen Sie eine Liste mit Shell-Befehlen aus:

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

Befehlsergebnisobjekt

Das von der Shell-Befehlsausführung zurückgegebene Objekt ist ein Wörterbuch, das stdouts, stderrs und return_codes. Unabhängig davon, ob der Shell-Befehl als einzelner String oder als Liste bereitgestellt wird von Befehlsstrings ist jeder Wert des Ergebniswörterbuchs immer eine Liste.

Zum Überprüfen des Rückgabecodes einer Liste von Befehlen muss das Testskript eine Prüfung durchführen. die Indexe. Beispiel:

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

Alternativ kann das Skript jeden Befehlsindex einzeln prüfen. Beispiel:

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

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