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 / zu stoppen. Sie können VTS-Geräte-Shell-Befehle mit dem Befehl adb shell oder dem auf dem Gerät ausgeführten VTS-Shell-Treiber ausführen (empfohlen).

Verwenden der ADB-Shell

Tests, bei denen der USB-Anschluss heruntergefahren oder das Gerät während des Tests neu gestartet werden muss, müssen die ADB-Shell verwenden, 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- AndroidDevice 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 des VTS-Shell-Treibers

Der VTS-Shell-Treiber ist eine Agenten-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 der Befehl adb shell .

Abbildung 1. VTS-Shell-Treiber.

Das VTS-Framework unterstützt Tests mit mehreren Geräten, bei denen jedes Android-Gerät im Base Runner als AndroidDevice-Objekt dargestellt wird. Standardmäßig überträgt das VTS-Framework die Binärdateien für VTS-Agenten und VTS-Shell-Treiber auf 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 host-seitige Python-Skript das ShellMirror-Objekt im AndroidDevice-Objekt auf. 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 Aufhängen 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 protobuf .

Vorteile

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

  • Verlässlichkeit. Der VTS-Shell-Treiber verwendet nohup , um Befehle in der Standardeinstellung auszuführen. Da es sich bei VTS-Tests hauptsächlich um HAL- und nohup niedrigerer Ebene handelt, stellt nohup sicher, dass Shell-Befehle während der Ausführung nicht hängen bleiben.
  • Leistung . Während der Befehl adb shell einige Ergebnisse zwischenspeichert (z. B. das Auflisten von Dateien in einem Verzeichnis), entsteht ein Verbindungsaufwand, wenn Aufgaben wie das Ausführen einer Testbinärdatei ausgeführt werden. Der VTS-Shell-Treiber unterhält während des gesamten Tests eine aktive Verbindung, 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 der 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 verwaltet eine Terminalsitzung für jeden Terminalnamen (Standardterminalname ist Standard ). Umgebungsvariablen, die in einer Terminalsitzung festgelegt wurden, 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 eingebunden, um in Zukunft eine mögliche Komprimierung, Remoting, Verschlüsselung usw. zu ermöglichen. Es gibt auch andere Möglichkeiten zur Verbesserung der Leistung, einschließlich der geräteseitigen Ergebnisanalyse, wenn der Kommunikationsaufwand größer wird als die Ergebniszeichenfolgenanalyse.

Nachteile

Die Verwendung des VTS-Shell-Treibers anstelle der adb shell Nachteile:

  • Zusätzliche Binärdateien . VTS-Agentendateien müssen auf das Gerät übertragen und nach der Testausführung bereinigt werden.
  • Erfordert eine aktive Verbindung . Wenn die TCP-Verbindung zwischen Host und Agent während des Tests (aufgrund von USB-Trennung, Herunterfahren des Ports, Geräteabsturz usw.) absichtlich oder unbeabsichtigt unterbrochen wird, kann kein Shell-Befehl an den VTS-Agenten übertragen werden. Selbst bei der automatischen Umschaltung auf die adb shell sind das Ergebnis und der Status des Befehls vor dem Trennen unbekannt.

Beispiele

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

  • Holen Sie sich ein Android-Geräteobjekt:
    self.device = self.android_devices[0]
    
  • Rufen Sie ein Shell-Objekt für das ausgewählte Gerät ab:
    self.shell = self.device.shell
    
  • Geben Sie einen einzelnen Shell-Befehl aus:
    results = self.shell.Execute(‘ls')
    
  • Geben Sie eine Liste der Shell-Befehle 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 . 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')