Comandi della shell del dispositivo

Durante i test VTS, i comandi della shell vengono utilizzati per eseguire un binario di test lato destinazione, per ottenere/impostare proprietà, variabili di ambiente e informazioni di sistema e per avviare/arrestare il framework Android. È possibile eseguire i comandi della shell del dispositivo VTS utilizzando il comando adb shell o il driver della shell VTS in esecuzione sul dispositivo (opzione consigliata).

Utilizzo della shell ADB

I test che richiedono l'arresto della porta USB o il riavvio del dispositivo durante il test devono utilizzare la shell ADB poiché il driver della shell VTS non è disponibile senza una connessione USB permanente. Puoi richiamare la shell ADB dall'oggetto AndroidDevice nello script di test Python. Esempi:

  • Ottieni un oggetto dispositivo Android:
    self.device = self.android_devices[0]
    
  • Emettere un singolo comando di shell:
    result = self.device.adb.shell(‘ls')
    

Utilizzando il driver della shell VTS

Il driver della shell VTS è un binario dell'agente che viene eseguito sul dispositivo ed esegue i comandi della shell. Per impostazione predefinita, VTS utilizza il driver della shell se il driver è in esecuzione sul dispositivo perché questo metodo ha una latenza inferiore rispetto all'utilizzo del comando adb shell .

Figura 1. Driver della shell VTS.

Il framework VTS supporta test multi-dispositivo in cui ogni dispositivo Android è rappresentato come un oggetto AndroidDevice in base runner. Per impostazione predefinita, il framework VTS invia i file binari dell'agente VTS e del driver della shell VTS a ciascun dispositivo Android e stabilisce connessioni TCP agli agenti VTS su tali dispositivi.

Per eseguire un comando shell, lo script Python lato host effettua una chiamata di funzione all'oggetto ShellMirror all'interno dell'oggetto AndroidDevice. L'oggetto ShellMirror comprime i testi dei comandi della shell in un messaggio protobuf e lo invia (tramite il canale TCP) all'agente VTS sul dispositivo Android. L'agente in esecuzione sul dispositivo inoltra quindi il comando della shell al driver della shell VTS tramite il socket Unix.

Quando il driver della shell VTS riceve un comando della shell, esegue il comando tramite nohup sulla shell del dispositivo per evitare che si blocchi. Stdout, stderr e il codice di ritorno vengono quindi recuperati da nohup e rispediti all'agente VTS. Infine, l'agente risponde all'host racchiudendo i risultati del comando in un messaggio protobuf .

Vantaggi

I vantaggi dell'utilizzo del driver della shell VTS anziché della adb shell includono:

  • Affidabilità. Il driver della shell VTS utilizza nohup per eseguire i comandi sull'impostazione predefinita. Poiché i test VTS sono per lo più test HAL e kernel di livello inferiore, nohup garantisce che i comandi della shell non si blocchino durante l'esecuzione.
  • Prestazioni . Mentre il comando adb shell memorizza nella cache alcuni risultati (come l'elenco dei file in una directory), ha un sovraccarico di connessione durante l'esecuzione di attività come l'esecuzione di un binario di test. Il driver della shell VTS mantiene una connessione attiva durante il test, quindi l'unico sovraccarico è la comunicazione USB. Nei nostri test, l'utilizzo del driver della shell VTS per eseguire un comando con 100 chiamate a un binario gtest vuoto è circa il 20% più veloce rispetto all'utilizzo di adb shell ; la differenza effettiva è maggiore poiché la comunicazione della shell VTS ha un'ampia registrazione.
  • Mantenimento dello Stato . Il driver della shell VTS mantiene una sessione di terminale per ciascun nome di terminale (il nome di terminale predefinito è predefinito ). Le variabili di ambiente impostate in una sessione del terminale sono disponibili solo per i comandi successivi nella stessa sessione.
  • Allungabile . Le comunicazioni dei comandi della shell tra il framework VTS e il driver del dispositivo sono racchiuse in protobuf per consentire potenziali compressione, remoting, crittografia, ecc. in futuro. Sono disponibili anche altre possibilità per migliorare le prestazioni, inclusa l'analisi dei risultati lato dispositivo quando l'overhead di comunicazione diventa maggiore dell'analisi della stringa dei risultati.

Svantaggi

Gli svantaggi dell'utilizzo del driver della shell VTS anziché della adb shell includono:

  • Binari aggiuntivi . I file dell'agente VTS devono essere inviati al dispositivo e ripuliti dopo l'esecuzione del test.
  • Richiede una connessione attiva . Se la connessione TCP tra host e agent viene interrotta durante il test (a causa di disconnessione USB, arresto della porta, crash del dispositivo, ecc.) intenzionalmente o meno, non è possibile trasmettere un comando shell all'agent VTS. Anche con il passaggio automatico ad adb shell , il risultato e lo stato del comando prima della disconnessione sarebbero sconosciuti.

Esempi

Esempi di utilizzo dei comandi della shell in uno script di test Python lato host VTS:

  • Ottieni un oggetto dispositivo Android:
    self.device = self.android_devices[0]
    
  • Ottieni un oggetto shell per il dispositivo selezionato:
    self.shell = self.device.shell
    
  • Emettere un singolo comando di shell:
    results = self.shell.Execute(‘ls')
    
  • Emettere un elenco di comandi della shell:
    results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
    

Oggetto risultato del comando

L'oggetto restituito dall'esecuzione del comando della shell è un dizionario contenente le chiavi stdouts , stderrs e return_codes . Indipendentemente dal fatto che il comando della shell sia fornito come una singola stringa o un elenco di stringhe di comando, ogni valore del dizionario dei risultati è sempre un elenco.

Per verificare il codice di ritorno di un elenco di comandi, lo script di test deve verificare gli indici. Esempio:

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

In alternativa, lo script può controllare ogni indice di comando individualmente. Esempio:

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