Diese Seite wurde von der Cloud Translation API übersetzt.

Geräte-Shell-Befehle

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

ADB-Shell verwenden

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

Android-Geräteobjekt abrufen:
```
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 und Shell-Befehle ausführt. Standardmäßig verwendet VTS den Shell-Treiber, wenn der Treiber auf dem Gerät ausgeführt wird, da diese Methode eine geringere Latenz hat als der Befehl adb shell.

Abbildung 1. VTS-Shell-Treiber.

Das VTS-Framework unterstützt Multi-Device-Tests, bei denen jedes Android-Gerät im Base Runner als AndroidDevice-Objekt dargestellt wird. Standardmäßig sendet das VTS-Framework VTS-Agent- und VTS-Shell-Treiber-Binärdateien an jedes Android-Gerät und stellt TCP-Verbindungen zu den VTS-Agenten auf diesen Geräten her.

Um einen Shell-Befehl auszuführen, ruft das hostseitige Python-Script das ShellMirror-Objekt im AndroidDevice-Objekt auf. Das ShellMirror-Objekt verpackt die Shell-Befehlstexte in eine Protobuf-Nachricht und sendet sie über den TCP-Kanal an den VTS-Agenten auf dem Android-Gerät. Der auf dem Gerät ausgeführte Agent leitet den Shell-Befehl dann über den Unix-Socket an den VTS-Shell-Treiber weiter.

Wenn der VTS-Shell-Treiber einen Shell-Befehl empfängt, führt er ihn über nohup in der Geräte-Shell aus, um ein Aufhängen zu verhindern. Stdout, stderr und der Rückgabecode werden dann aus nohup abgerufen und an den VTS-Agenten zurückgesendet. Schließlich antwortet der Agent dem Host, indem er die Befehlsergebnisse in eine protobuf-Nachricht einbettet.

Vorteile

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

Zuverlässigkeit. Der VTS-Shell-Treiber verwendet nohup, um Befehle mit der Standardeinstellung auszuführen. Da VTS-Tests hauptsächlich HAL- und Kernel-Tests auf niedriger Ebene sind, sorgt nohup dafür, dass Shell-Befehle während der Ausführung nicht hängen.
Leistung Der Befehl adb shell speichert zwar einige Ergebnisse im Cache (z. B. das Auflisten von Dateien in einem Verzeichnis), verursacht aber einen Verbindungsoverhead bei Aufgaben wie der Ausführung eines Test-Binärprogramms. Der VTS-Shell-Treiber hält während des Tests eine aktive Verbindung aufrecht, sodass nur die USB-Kommunikation einen Overhead verursacht. In unseren Tests war die Ausführung eines Befehls mit 100 Aufrufen an eine leere gtest-Binärdatei über den VTS-Shell-Treiber etwa 20 % schneller als mit adb shell. Der tatsächliche Unterschied ist größer, da die VTS-Shell-Kommunikation umfangreiche Protokolle umfasst.
Statusverwaltung: Der VTS-Shell-Treiber führt für jeden Terminalnamen eine Terminalsitzung. Der Standard-Terminalname ist default. Umgebungsvariablen, die in einer Terminalsitzung festgelegt werden, sind nur für nachfolgende Befehle in derselben Sitzung verfügbar.
Erweiterbar Die Shell-Befehlskommunikation zwischen dem VTS-Framework und dem Gerätetreiber wird in Protobuf verpackt, um in Zukunft Komprimierung, Remotezugriff, Verschlüsselung usw. zu ermöglichen. Es gibt auch andere Möglichkeiten, die Leistung zu verbessern, z. B. die geräteseitige Ergebnisanalyse, wenn der Kommunikationsoverhead größer wird als die Ergebnisstring-Analyse.

Nachteile

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

Zusätzliche Binärdateien VTS-Agentdateien müssen auf das Gerät gepusht und nach der Testausführung bereinigt werden.
Erfordert eine aktive Verbindung. Wenn die TCP-Verbindung zwischen Host und Agent während des Tests unterbrochen wird (z. B. durch USB-Trennung, Portabschaltung oder Geräteabsturz), kann ein Shell-Befehl nicht an den VTS-Agenten übertragen werden. Selbst bei automatischer Umstellung auf adb shell sind das Ergebnis und der Status des Befehls vor der Verbindungsunterbrechung unbekannt.

Beispiele

Beispiele für die Verwendung von Shell-Befehlen in einem hostseitigen Python-Testscript für VTS:

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

Liste der Shell-Befehle aufrufen:

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

Befehlsergebnisobjekt

Das Rückgabeobjekt der Shell-Befehlsausführung ist ein Wörterbuch mit den Schlüsseln stdouts, stderrs und return_codes. Unabhängig davon, ob der Shell-Befehl als einzelner String oder als Liste von Befehlsstrings angegeben wird, ist jeder Wert des Ergebniswörterbuchs immer eine Liste.

Um den Rückgabecode einer Liste von Befehlen zu überprüfen, muss das Testscript die Indizes prüfen. Beispiel:

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

Alternativ kann das Script 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')