Geräte-Shell-Befehle

Während des VTS-Tests werden Shell-Befehle verwendet, um eine zielseitige Testbinärdatei 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 adb shell -Befehl oder dem auf dem Gerät ausgeführten VTS-Shell-Treiber ausführen (empfohlen).

Verwenden Sie die ADB-Shell

Tests, die das Herunterfahren des USB-Anschlusses oder einen Neustart des Geräts während des Tests erfordern, müssen die ADB-Shell verwenden, da der VTS-Shell-Treiber ohne eine dauerhafte USB-Verbindung nicht verfügbar ist. Sie können die ADB-Shell über das AndroidDevice Objekt im Python-Testskript aufrufen. Beispiele:

  • Holen Sie sich ein Android-Geräteobjekt:
    self.device = self.android_devices[0]
    
  • Geben Sie einen einzelnen Shell-Befehl aus:
    result = self.device.adb.shell(‘ls')
    

Verwenden Sie den VTS-Shell-Treiber

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 aufweist als die Verwendung des adb shell Befehls.

Abbildung 1. VTS-Shell-Treiber.

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

Um einen Shell-Befehl auszuführen, führt das hostseitige Python-Skript einen Funktionsaufruf an das ShellMirror-Objekt innerhalb des AndroidDevice-Objekts durch. Das ShellMirror-Objekt packt 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 den Befehl über nohup auf der Geräte-Shell aus, um ein Hängenbleiben zu verhindern. Stdout, stderr und Rückkehrcode werden dann von nohup abgerufen und an den VTS-Agenten zurückgesendet. Schließlich antwortet der Agent dem Host, indem er die Befehlsergebnisse in eine protobuf -Nachricht verpackt.

Vorteile

Zu den Vorteilen der Verwendung des VTS-Shell-Treibers anstelle adb shell gehören:

  • Zuverlässigkeit. Der VTS-Shell-Treiber verwendet nohup , um Befehle in der Standardeinstellung auszuführen. Da es sich bei VTS-Tests meist um HAL- und Kernel-Tests niedrigerer Ebenen handelt, stellt nohup sicher, dass Shell-Befehle während der Ausführung nicht hängen bleiben.
  • Leistung . Während der adb shell -Befehl einige Ergebnisse zwischenspeichert (z. B. das Auflisten von Dateien in einem Verzeichnis), entsteht bei der Ausführung von Aufgaben wie der Ausführung einer Testbinärdatei ein Verbindungsaufwand. Der VTS-Shell-Treiber hält während des gesamten Tests eine aktive Verbindung aufrecht, sodass der einzige Mehraufwand die USB-Kommunikation ist. In unseren Tests ist die Verwendung des VTS-Shell-Treibers zur Ausführung eines Befehls mit 100 Aufrufen einer leeren gtest-Binärdatei etwa 20 Prozent schneller als die Verwendung adb shell . Der tatsächliche Unterschied ist größer, da die VTS-Shell-Kommunikation über eine umfangreiche Protokollierung verfügt.
  • Staatsführung . Der VTS-Shell-Treiber unterhält eine Terminalsitzung für jeden Terminalnamen (der Standard-Terminalname ist default ). In einer Terminalsitzung festgelegte Umgebungsvariablen stehen nur für nachfolgende Befehle in derselben Sitzung zur Verfügung.
  • Erweiterbar . Die Shell-Befehlskommunikation zwischen dem VTS-Framework und dem Gerätetreiber ist in Protobuf verpackt, um zukünftige Komprimierung, Remoting, Verschlüsselung usw. zu ermöglichen. Es stehen auch andere Möglichkeiten zur Leistungsverbesserung zur Verfügung, einschließlich der geräteseitigen Ergebnisanalyse, wenn der Kommunikationsaufwand größer wird als die Ergebniszeichenfolgenanalyse.

Nachteile

Zu den Nachteilen der Verwendung des VTS-Shell-Treibers anstelle adb shell gehören:

  • Zusätzliche Binärdateien . VTS-Agentendateien müssen nach der Testausführung auf das Gerät übertragen und bereinigt werden.
  • Erfordert eine aktive Verbindung . Wenn die TCP-Verbindung zwischen Host und Agent während des Tests absichtlich oder unabsichtlich verloren geht (aufgrund von USB-Verbindung, Port-Abschaltung, Geräteabsturz usw.), kann kein Shell-Befehl an den VTS-Agenten übermittelt werden. Selbst beim automatischen Wechsel zur adb shell wären das Ergebnis und der Status des Befehls vor dem Trennen der Verbindung unbekannt.

Beispiele

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

  • Holen Sie sich ein Android-Geräteobjekt:
    self.device = self.android_devices[0]
    
  • Holen Sie sich ein Shell-Objekt für das ausgewählte Gerät:
    self.shell = self.device.shell
    
  • Geben Sie einen einzelnen Shell-Befehl aus:
    results = self.shell.Execute(‘ls')
    
  • Geben Sie eine Liste von Shell-Befehlen aus:
    results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
    

Befehlsergebnisobjekt

Das Rückgabeobjekt der Shell-Befehlsausführung ist ein Wörterbuch, das die Schlüssel stdouts , stderrs und return_codes enthält. Unabhängig davon, ob der Shell-Befehl als einzelne Zeichenfolge oder als Liste von Befehlszeichenfolgen bereitgestellt wird, ist jeder Wert des Ergebniswörterbuchs immer eine Liste.

Um den Rückkehrcode einer Befehlsliste zu überprüfen, muss das Testskript die Indizes überprüfen. Beispiel:

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

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

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