Geräte-Shell-Befehle

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

Verwenden der ADB-Shell

Tests, die das Herunterfahren des USB-Ports oder das Neustarten 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:

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

Verwenden des VTS-Shell-Treibers

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 Multi-Device-Tests, bei denen jedes Android-Gerät als AndroidDevice-Objekt im Basis-Runner dargestellt wird. Standardmäßig überträgt das VTS-Framework VTS-Agent- und VTS-Shell-Treiber-Binärdateien auf 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 laufende Agent leitet dann den Shell-Befehl ü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 Aufhängen zu verhindern. Stdout, stderr und der Rückgabecode werden dann von nohup abgerufen und an den VTS-Agenten zurückgesendet. Schließlich antwortet der Agent dem Host, indem er das/die Befehlsergebnis(se) in eine protobuf Nachricht verpackt.

Vorteile

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

  • Verlässlichkeit. Der VTS-Shell-Treiber verwendet nohup , um Befehle in der Standardeinstellung auszuführen. Da VTS-Tests hauptsächlich HAL- und Kernel-Tests auf niedrigerer Ebene sind, 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), hat er einen Verbindungsaufwand, wenn er Aufgaben wie das Ausführen einer Testbinärdatei ausführt. Der VTS-Shell-Treiber behält während des gesamten Tests eine aktive Verbindung bei, sodass der einzige Overhead die USB-Kommunikation ist. In unseren Tests ist die Verwendung des VTS-Shell-Treibers zum Ausführen eines Befehls mit 100 Aufrufen einer leeren gtest-Binärdatei etwa 20 Prozent schneller als die Verwendung von adb shell ; Der tatsächliche Unterschied ist größer, da die VTS-Shell-Kommunikation eine umfangreiche Protokollierung aufweist.
  • Staatshaltung . Der VTS-Shell-Treiber verwaltet eine Terminalsitzung für jeden Terminalnamen (der Standard-Terminalname ist default ). In einer Terminalsitzung festgelegte Umgebungsvariablen sind nur für nachfolgende Befehle in derselben Sitzung verfügbar.
  • Erweiterbar . Die Shell-Befehlskommunikation zwischen dem VTS-Framework und dem Gerätetreiber ist in Protobuf verpackt, um in Zukunft potenzielle Komprimierung, Remoting, Verschlüsselung usw. zu ermöglichen. Andere Möglichkeiten zur Verbesserung der Leistung sind ebenfalls verfügbar, einschließlich der geräteseitigen Ergebnisanalyse, wenn der Kommunikationsaufwand größer wird als die Analyse der Ergebniszeichenfolge.

Nachteile

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

  • Zusätzliche Binärdateien . VTS-Agentendateien müssen nach der Testausführung auf das Gerät übertragen und bereinigt werden.
  • Aktive Verbindung erforderlich . Wenn die TCP-Verbindung zwischen Host und Agent während des Tests unterbrochen wird (aufgrund von USB-Trennung, Portabschaltung, Geräteabsturz usw.), entweder absichtlich oder unabsichtlich, kann ein Shell-Befehl nicht an den VTS-Agenten übertragen werden. Auch bei automatischer Umschaltung auf adb shell wären das Ergebnis und der Zustand des Befehls vor der Verbindungstrennung unbekannt.

Beispiele

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

  • Rufen Sie ein Android-Geräteobjekt ab:
    self.device = self.android_devices[0]
    
  • Holen Sie sich ein Shell-Objekt für das ausgewählte Gerät:
    self.shell = self.device.shell
    
  • Setzen Sie einen einzelnen Shell-Befehl ab:
    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 von der Shell-Befehlsausführung ist ein Wörterbuch, das die Schlüssel stdouts , stderrs und return_codes . Unabhängig davon, ob der Shell-Befehl als einzelne Zeichenfolge oder als Liste von Befehlszeichenfolgen bereitgestellt wird, ist jeder Wert des Ergebnisverzeichnisses immer eine Liste.

Um den Rückkehrcode einer Liste von Befehlen 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 prüfen. Beispiel:

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