Durante las pruebas de VTS, se usan comandos de shell para ejecutar un objeto binario de prueba del destino, obtener o establecer propiedades, variables de entorno y la información del sistema, y para iniciar o detener el framework de Android. Puedes ejecutar comandos de shell del dispositivo de VTS con el comando adb shell
o el controlador de shell de VTS que se ejecuta en el dispositivo (recomendado).
Usa el shell de ADB
Las pruebas que requieren que se cierre el puerto USB o se reinicie el dispositivo durante la prueba deben usar la shell de ADB, ya que el controlador de shell de VTS no está disponible sin una conexión USB persistente. Puedes invocar la shell de ADB desde el objeto 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')
Usa el controlador de shell de VTS
El controlador de shell de VTS es un agente binario que se ejecuta en el dispositivo y ejecuta comandos de shell. De forma predeterminada, VTS usa el controlador de shell si se ejecuta en el dispositivo, ya que este método tiene menos latencia que usar el 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 base. De forma predeterminada, el framework de VTS envía objetos binarios del agente 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 host realiza una llamada de función al objeto ShellMirror dentro del objeto AndroidDevice. El objeto ShellMirror empaqueta los textos de los comandos de shell en un mensaje protobuf y lo envía (a través del canal TCP) al agente de VTS en el dispositivo Android. Luego, el agente que se ejecuta en el dispositivo reenvía el comando de shell al controlador de shell de VTS a través del socket de Unix.
Cuando el controlador de shell de VTS recibe un comando de shell, lo ejecuta a través de nohup en la shell del dispositivo para evitar que se cuelgue. Luego, se recuperan stdout, stderr y el código devuelto de nohup
y se envían al agente de VTS. Por último, el agente responde al host uniendo los resultados del comando en un mensaje protobuf
.
Ventajas
Estas son algunas de las ventajas de usar el controlador de shell de VTS en lugar de adb
shell
:
- Confiabilidad: El controlador de shell de VTS usa
nohup
para ejecutar comandos en la configuración predeterminada. Como las pruebas de VTS son principalmente pruebas de HAL y kernel de nivel inferior,nohup
garantiza que los comandos de shell no se bloqueen durante la ejecución. - Rendimiento. Si bien el comando
adb shell
almacena en caché algunos resultados (como la lista de archivos en un directorio), tiene una sobrecarga de conexión cuando realiza tareas como ejecutar un binario de prueba. El controlador de shell de VTS mantiene una conexión activa durante la prueba, por lo que la única sobrecarga es la comunicación USB. En nuestras pruebas, usar el controlador de shell de VTS para ejecutar un comando con 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 la comunicación de shell de VTS tiene un registro extenso. - Mantenimiento del estado: El controlador de shell de VTS mantiene una sesión de terminal para cada nombre de terminal (el nombre predeterminado es default). Las variables de entorno configuradas en una sesión de terminal solo están disponibles para los comandos posteriores en la misma sesión.
- Expandible: Las comunicaciones de comandos de Shell entre el framework de VTS y el controlador de dispositivos se unen en protobuf para permitir la compresión, la conexión remota, la encriptación, etc. en el futuro. También hay otras posibilidades para mejorar el rendimiento, incluido el análisis de resultados del dispositivo cuando la sobrecarga de comunicación se vuelve mayor que el análisis de cadenas de resultados.
Desventajas
Las desventajas de usar el controlador de shell de VTS en lugar de adb
shell
incluyen las siguientes:
- Objetos binarios adicionales. Los archivos del agente de VTS se deben enviar al dispositivo y limpiar después de la ejecución de la prueba.
- Requiere una conexión activa. Si se pierde la conexión TCP entre el host y el agente durante la prueba (debido a la desconexión USB, el cierre del puerto, la falla del dispositivo, etcétera), ya sea de forma intencional o no, no se puede transmitir un comando de shell 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ían desconocidos.
Ejemplos
Ejemplos del 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')
- Emite 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 después de la ejecución del comando de shell es un diccionario que contiene las claves stdouts
, stderrs
y return_codes
.
Independientemente de si el comando de shell se proporciona como una sola cadena o una lista de cadenas de comandos, cada valor del diccionario de resultados siempre es una lista.
Para verificar el código que se muestra de una lista de comandos, la secuencia de comandos de prueba debe verificar 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')