Testar vários usuários

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Esta página descreve aspectos importantes do teste com vários usuários no Plataforma Android. Para saber mais sobre a implementação do suporte a vários usuários, consulte Suporte a vários usuários.

Caminhos do dispositivo

A tabela a seguir lista vários caminhos de dispositivo e como eles são resolvidos. Todos os valores na coluna Path são um armazenamento em sandbox específico do usuário. A história de armazenamento do Android mudou ao longo do tempo. Leia a documentação do Armazenamento para mais informações.

Confira um exemplo de uso de um caminho específico do usuário:

# to access user 10's private application data for app com.bar.foo:
$ adb shell ls /data/user/10/com.bar.foo/

interações do adb entre usuários

Vários comandos adb são úteis ao lidar com vários usuários. Alguns desses comandos têm suporte apenas no Android 9 e versões mais recentes:

• adb shell am instrument --user <userId> executa um teste de instrumentação em um usuário específico. Por padrão, essa opção usa o usuário atual.
• O adb install --user <userId> instala um pacote para um usuário específico. Para garantir que um pacote seja instalado para todos os usuários, chame esse método para cada usuário.
• adb uninstall --user <userId> desinstala um pacote para um usuário específico. Chame sem a flag --user para desinstalar para todos os usuários.
• adb shell am get-current-user recebe o ID do usuário atual (em primeiro plano).
• adb shell pm list users recebe uma lista de todos os usuários existentes.
• adb shell pm create-user cria um novo usuário e retorna o ID.
• adb shell pm remove-user remove um usuário específico por ID.
• adb shell pm disable --user <userId> desativa um pacote para um usuário específico.
• adb shell pm enable --user <userId> ativa um pacote para um usuário específico.
• adb shell pm list packages --user <userId> lista pacotes (-e para ativada, -d para desativada) para um usuário específico. Por padrão, ele sempre lista para o usuário do sistema.

As informações a seguir ajudam a explicar como o adb se comporta com vários usuários:

• adb (ou, mais precisamente, o daemon adbd) sempre é executado como o usuário do sistema (ID do usuário = 0) independentemente de qual usuário está em uso. Portanto, o dispositivo caminhos que dependem do usuário (como /sdcard/) sempre são resolvidos como o usuário do sistema. Consulte Caminhos de dispositivos para mais detalhes.

• Se um usuário padrão não for especificado, cada subcomando adb terá uma forma diferente. usuário. A prática recomendada é recuperar o ID do usuário com am get-current-user e depois use --user <userId> explicitamente para qualquer comando compatível. Com linguagem explícita sinalizações de usuário não eram compatíveis com todos os comandos até o Android 9.

• O acesso aos caminhos /sdcard de usuários secundários é negado a partir de Android 9. Consulte Provedor de conteúdo para dados de vários usuários para saber como extrair arquivos durante o teste.

Provedor de conteúdo para dados de vários usuários

Como adb é executado como o usuário do sistema e os dados são isolados em um ambiente de teste no Android 9 e versões mais recentes, é necessário usar provedores de conteúdo para enviar ou extrair dados de teste de um usuário que não seja do sistema. Isso não é necessário se:

• adbd está sendo executado como raiz (usando adb root), o que só é possível usando builds userdebug ou usereng.

• Você está usando a Trade Federation (Tradefed) ITestDevice para enviar ou extrair os arquivos. Nesse caso, use caminhos /sdcard/ no teste. config. Por exemplo, consulte o código-fonte de pushFile em NativeDevice.java).

Quando um provedor de conteúdo está em execução no usuário secundário, é possível acessá-lo usando o comando adb shell content com os parâmetros user, uri e outros parâmetros especificados.

Alternativa para desenvolvedores de apps

Interaja com arquivos de teste usando adb content e uma instância do ContentProvider, em vez dos comandos push ou pull.

1. Criar uma instância de ContentProvider hospedada pelo app que possa veicular e armazenar arquivos quando necessário. Use o armazenamento interno do app.
2. Use os comandos adb shell content read ou write para enviar ou extrair os arquivos.

Alternativa para arquivos de mídia

Para enviar arquivos de mídia para a partição de mídia do cartão SD, use o MediaStore público APIs de terceiros. Exemplo:

# push MVIMG_20190129_142956.jpg to /storage/emulated/10/Pictures
# step 1
$ adb shell content insert --user 10 --uri content://media/external/images/media/ --bind _display_name:s:foo.jpg

# step 2
$ adb shell content query --user 10 --projection _id --uri content://media/external/images/media/ --where "_display_name=\'foo.jpg\'"

# step 3
$ adb shell content write --user 10 --uri content://media/external/images/media/8022 < MVIMG_20190129_142956.jpg

Instalar um provedor de conteúdo genérico

Instale e use um provedor de conteúdo que leia e gravasse arquivos no caminho /sdcard específico do usuário.

Crie o TradefedContentProvider.apk da origem usando make TradefedContentProvider:

```
# install content provider apk
$ adb install --user 10 -g TradefedContentProvider.apk

# pull some_file.txt
$ adb shell content read --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt > local_file.txt

# push local_file.txt
$ adb shell content write --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt < local_file.txt
```

Suporte a vários usuários da Trade Federation

O Tradefed é o arcabouço de teste oficial do Android. Esta seção resume alguns dos recursos integrados da Tradefed suporte a cenários de teste multiusuário.

Verificadores de status

Os verificadores de status do sistema (SSCs, na sigla em inglês) são executados antes dos preparadores de destino, e a limpeza deles é executada após esses preparadores.

UserChecker é definido explicitamente para ajudar os desenvolvedores a testar vários usuários. Ele rastreia se um teste mudou o estado dos usuários no dispositivo (por exemplo, criou usuários sem removê-los na desmontagem). Além disso, se user-cleanup estiver configurado, ele tenta limpar automaticamente após o teste, enquanto ainda fornecendo erros úteis para que o teste possa ser corrigido.

<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
    <option name="user-cleanup" value="true" />
</system_checker>

Preparador de destino

Os preparadores de destino geralmente são usados para configurar um dispositivo com uma configuração específica. No caso de testes com vários usuários, os preparadores podem ser usados para criar usuários de um tipo específico e alternar para outros usuários.

Para tipos de dispositivos que não têm um usuário secundário, é possível usar CreateUserPreparer para criar e alternar para um usuário secundário em AndroidTest.xml. No final do teste, o preparador volta e exclui o usuário secundário.

<target_preparer
  class="com.google.android.tradefed.targetprep.CreateUserPreparer" >
</target_preparer>

Se o tipo de usuário que você quer já existe no dispositivo, use SwitchUserTargetPreparer para alternar para o usuário existente. Os valores comuns para user-type incluem system ou secondary.

<target_preparer
  class="com.android.tradefed.targetprep.SwitchUserTargetPreparer">
    <option name="user-type" value="secondary" />
</target_preparer>

Testes orientados pelo host

Em alguns casos, um teste precisa trocar de usuário dentro do teste. Não mude de um framework de teste no dispositivo, como o UI Automator, porque o processo de teste pode ser encerrado a qualquer momento. Em vez disso, use um host de teste, como o teste orientado por host da Tradefed, framework, que dá acesso ITestDevice, permitindo qualquer manipulação de usuário necessária.

Use UserChecker (descrito em verificadores de status) para testes orientados por host que mudam o estado do usuário, porque garante que o teste seja devidamente limpo depois de si mesmo.