Durante las pruebas de VTS, se usan comandos de shell para ejecutar una prueba orientada al destino.
binario, para obtener y establecer propiedades, variables de entorno e información del sistema,
e iniciar/detener el framework de Android. Puedes ejecutar el shell del dispositivo VTS
con el comando adb shell
o el controlador de shell de VTS
que se ejecuta en el dispositivo (recomendado).
Cómo usar la shell de ADB
Pruebas que requieren apagar el puerto USB o reiniciar el dispositivo durante
las pruebas deben usar el shell de ADB, ya que el controlador de shell de VTS no está disponible sin un
una conexión USB persistente. Puedes invocar el shell de ADB desde el
AndroidDevice
en la secuencia de comandos de prueba de Python. Ejemplos:
- Obtén un objeto de dispositivo Android:
self.device = self.android_devices[0]
- Emite un solo comando de shell:
result = self.device.adb.shell(‘ls')
Cómo usar el controlador de shell de VTS
El controlador de shell de VTS es un objeto binario que se ejecuta en el dispositivo y
de shell. De forma predeterminada, VTS usa el controlador de shell si este se está ejecutando.
en el dispositivo, ya que este método tiene menos latencia que el uso del comando adb
shell
.
El framework de VTS admite pruebas multidispositivo en las que cada dispositivo Android se representa como un objeto AndroidDevice en el ejecutor básico. De forma predeterminada, VTS El framework envía los objetos binarios del agente de VTS y del controlador de shell de VTS a cada dispositivo Android. y establece conexiones TCP con los agentes de VTS en esos dispositivos.
Para ejecutar un comando de shell, la secuencia de comandos de Python del lado del host hace que una función al objeto ShellMirror dentro del objeto AndroidDevice. The ShellMirror empaqueta los textos de los comandos de shell protobuf mensaje y lo envía (a través del canal TCP) al agente de VTS en la dispositivo. El agente que se ejecuta en el dispositivo reenvía el comando de shell al shell de VTS a través del socket Unix.
Cuando el controlador de shell de VTS recibe un comando shell, lo ejecuta.
mediante nohup en
la carcasa del dispositivo para evitar que se cuelgue. Entonces, los códigos Stdout, stderr y return
Se recuperó de nohup
y se envía de vuelta al agente de VTS. Por último, el agente
responde al host uniendo los resultados del comando en una
protobuf
mensaje.
Ventajas
Entre las ventajas de usar el controlador de shell de VTS en lugar de adb
shell
, se incluyen las siguientes:
- Confiabilidad. El controlador de shell de VTS usa
nohup
para ejecutar comandos en la configuración predeterminada. Como las pruebas de VTS principalmente pruebas de HAL y kernel de nivel inferior,nohup
garantiza que la shell de comandos no se bloquean durante la ejecución. - Rendimiento. Mientras que el comando
adb shell
almacena en caché algunos resultados (como la lista de archivos de un directorio), tiene conexión cuando se realizan tareas como la ejecución de un objeto binario de prueba. Controlador de shell de VTS mantiene una conexión activa durante toda la prueba, de modo que la única sobrecarga sea la USB. la comunicación. En nuestras pruebas, usamos el controlador de shell de VTS para ejecutar un comando con Realizar 100 llamadas a un objeto binario gtest vacío es aproximadamente un 20% más rápido que usaradb shell
; la diferencia real es mayor, ya que el shell del VTS la comunicación tiene registros extensos. - Conservación del estado. El controlador de shell de VTS mantiene una terminal de terminal para cada nombre de terminal (el nombre de terminal predeterminado es predeterminada). Las variables de entorno establecidas en una sesión de terminal disponible solo para comandos posteriores en la misma sesión.
- Extensibles. Comunicaciones de comandos de shell entre VTS el framework y el controlador del dispositivo se unen en protobuf para permitir posibles compresión, remota, encriptación, etc. en el futuro. Otras posibilidades para mejorar el rendimiento, incluido el análisis de resultados del dispositivo Cuando la sobrecarga de comunicación es mayor que el análisis de la cadena de resultados
Desventajas
Entre las desventajas de usar el controlador de shell de VTS en lugar de adb
shell
, se incluyen las siguientes:
- Objetos binarios adicionales. Los archivos del agente de VTS deben enviarse y se limpiaron después de la ejecución de prueba.
- Requiere una conexión activa. Si la conexión TCP entre
el host y el agente se pierden durante la prueba (debido a la desconexión de USB, el cierre de puertos,
falla del dispositivo, etc.), ya sea de forma intencional o no, un comando del shell
no se pueden transmitir al agente de VTS. Incluso con el cambio automático a
adb shell
, el resultado y el estado del comando antes de la desconexión sería desconocido.
Ejemplos
Ejemplos de uso de comandos de shell en una secuencia de comandos de prueba de Python del lado del host de VTS:
- Obtén un objeto de dispositivo Android:
self.device = self.android_devices[0]
- Obtén un objeto de shell para el dispositivo seleccionado:
self.shell = self.device.shell
- Emite un solo comando de shell:
results = self.shell.Execute(‘ls')
- Genera una lista de comandos de shell:
results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
Objeto de resultado del comando
El objeto que se muestra de la ejecución del comando de shell es un diccionario que contiene los
las teclas stdouts
, stderrs
y return_codes
.
Sin importar si el comando shell se proporciona como una sola cadena o una lista
de cadenas de comandos, cada valor del diccionario de resultados es siempre una lista.
Para verificar el código de retorno de una lista de comandos, la secuencia de comandos de prueba debe comprobar los índices. Ejemplo:
asserts.assertFalse(any(results[‘return_codes']), ‘some command failed.')
Como alternativa, la secuencia de comandos puede verificar cada índice de comando de forma individual. Ejemplo:
asserts.assertEqual(results[‘return_codes'][0], 0, ‘first command failed')
asserts.assertEqual(results[‘return_codes'][1], 0, ‘second command failed')