O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Comandos do shell do dispositivo

Durante o teste VTS, os comandos do shell são usados para executar um teste no lado do alvo. para receber/definir propriedades, variáveis de ambiente e informações do sistema, e para iniciar/parar o framework do Android. É possível executar o shell do dispositivo VTS usando o comando adb shell ou o driver de shell do VTS em execução no dispositivo (recomendado).

Usar o shell do adb

Testes que exigem o desligamento da porta USB ou a reinicialização do dispositivo durante testes devem usar o shell do ADB, pois o driver do shell do VTS não está disponível sem uma conexão USB permanente. É possível invocar o shell ADB pelo Objeto AndroidDevice no script de teste do Python. Exemplos:

Receba um objeto de dispositivo Android:
```
self.device = self.android_devices[0]
```
Emita um único comando shell:
```
result = self.device.adb.shell(‘ls')
```

Usar o driver do shell do VTS

O driver do shell do VTS é um binário de agente que é executado no dispositivo do shell do Cloud Shell. Por padrão, o VTS usa o driver shell se o driver estiver em execução no dispositivo, porque esse método tem menos latência do que usar o comando adb shell.

Figura 1. driver de shell do VTS.

O framework VTS oferece suporte a testes multidispositivo em que cada dispositivo Android é representado como um objeto AndroidDevice no executor base. Por padrão, o VTS o framework envia binários do agente VTS e do driver de shell do VTS para cada dispositivo Android e estabelece conexões TCP com os agentes VTS nesses dispositivos.

Para executar um comando shell, o script Python do lado do host cria uma função chamada para o objeto ShellMirror dentro do objeto AndroidDevice. ShellMirror empacota os textos do comando shell em um protobuf e a envia (pelo canal TCP) para o agente VTS no Android dispositivo. O agente em execução no dispositivo encaminha o comando shell para o shell do VTS por um soquete Unix.

Quando o driver do shell do VTS recebe um comando do shell, ele executa o comando via nohup em shell do dispositivo para evitar travamentos. Stdout, stderr e o código de retorno são recuperado de nohup e enviado de volta ao agente VTS. Por fim, o agente responde ao host encapsulando os resultados do comando protobuf mensagem.

Vantagens

As vantagens de usar o driver de shell do VTS em vez de adb shell incluem:

Confiabilidade. O driver do shell do VTS usa nohup para executar comandos na configuração padrão. Como os testes VTS são principalmente testes de kernel e HAL de nível inferior, o nohup garante que o shell não travam durante a execução.
Desempenho. Enquanto o comando adb shell armazena em cache alguns resultados (como listar arquivos em um diretório) de que há uma conexão ao realizar tarefas como a execução de um binário de teste. Driver de shell do VTS mantém uma conexão ativa durante todo o teste, de modo que a única sobrecarga é de USB. comunicação. Em nossos testes, usar o driver de shell do VTS para executar um comando com As chamadas 100 para um binário gtest vazio são cerca de 20% mais rápidas do que usar adb shell a diferença real é maior, já que o shell do VTS em nuvem tem registros extensivos.
Manutenção do estado. O driver do shell do VTS mantém um sessão para cada nome de terminal (o nome padrão do terminal é default). As variáveis de ambiente definidas em uma sessão do terminal são disponíveis apenas para comandos subsequentes na mesma sessão.
Extensível. Comunicação de comando do shell entre o VTS e o driver do dispositivo são unidos em protobuf para permitir possíveis compactação, comunicação remota, criptografia etc. no futuro. Outras possibilidades para melhorar o desempenho, incluindo a análise de resultados no lado do dispositivo quando a sobrecarga de comunicação se torna maior do que a análise da string resultante.

Desvantagens

As desvantagens de usar o driver de shell do VTS em vez de adb shell incluem:

Binários adicionais. Os arquivos do agente VTS precisam ser enviados no dispositivo e limpos após a execução do teste.
Requer conexão ativa. Se a conexão TCP entre host e agente são perdidos durante o teste (devido à desconexão do USB, encerramento da porta falha do dispositivo etc.) intencionalmente ou não, um comando shell não pode ser transmitido ao agente VTS. Mesmo com a mudança automática para adb shell, o resultado e o estado do comando antes da desconexão é desconhecido.

Exemplos

Exemplos de como usar comandos do shell em um script de teste Python no lado do host do VTS:

Receba um objeto de dispositivo Android:
```
self.device = self.android_devices[0]
```
Receba um objeto shell para o dispositivo selecionado:
```
self.shell = self.device.shell
```
Emita um único comando shell:
```
results = self.shell.Execute(‘ls')
```

Emita uma lista de comandos do shell:

results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])

Objeto de resultado do comando

O objeto de retorno da execução do comando shell é um dicionário que contém as chaves stdouts, stderrs e return_codes. Independentemente de o comando shell ser fornecido como uma única string ou uma lista de strings de comando, cada valor do dicionário de resultado é sempre uma lista.

Para verificar o código de retorno de uma lista de comandos, o script de teste deve verificar os índices. Exemplo:

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

Como alternativa, o script pode verificar cada índice de comando individualmente. Exemplo:

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

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