Testando vários usuários

Esta página descreve aspectos importantes do teste de vários usuários na plataforma Android. Para obter informações sobre como implementar o suporte multiusuário, consulte Suporte a vários usuários .

Caminhos de dispositivo

A tabela a seguir lista vários caminhos de dispositivos e como eles são resolvidos. Todos os valores na coluna Caminho são um armazenamento em área restrita específico do usuário. A história do armazenamento do Android mudou com o tempo; leia a documentação de armazenamento para obter mais informações.

Caminho Caminho do sistema (opcional) Propósito
/data/user/{userId}/{app.path} /data/data Armazenamento de aplicativos
/storage/emulated/{userId} /sdcard Armazenamento interno compartilhado
/data/media/{userId} nenhum Dados de mídia do usuário (por exemplo, músicas, vídeos)
/data/system/users/{userId} nenhum Configuração/estado do sistema por usuário

Acessível apenas por aplicativos do sistema

Aqui está 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 adb entre usuários

Vários comandos adb são úteis ao lidar com vários usuários. Alguns destes comandos são suportados apenas no Android 9 e superior:

  • adb shell am instrument --user <userId> executa um teste de instrumentação em um usuário específico. Por padrão, isso usa o usuário atual.
  • 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, você deve chamar isso para cada usuário.
  • adb uninstall --user <userId> desinstala um pacote para um usuário específico. Chame sem o sinalizador --user para desinstalar para todos os usuários.
  • adb shell am get-current-user obtém o ID do usuário atual (em primeiro plano).
  • adb shell pm list users obtém uma lista de todos os usuários existentes.
  • adb shell pm create-user cria um novo usuário, retornando o ID.
  • adb shell pm remove-user remove um usuário específico por ID.
  • adb shell pm disable --user <userId> desabilita um pacote para um usuário específico.
  • adb shell pm enable --user <userId> habilita um pacote para um usuário específico.
  • adb shell pm list packages --user <userId> lista pacotes ( -e para habilitado, -d para desabilitado) para um usuário específico. Por padrão, isso sempre é listado para o usuário do sistema.

As informações a seguir ajudam a explicar como 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 seja o atual . Portanto, os caminhos de dispositivos que dependem do usuário (como /sdcard/ ) sempre são resolvidos como o usuário do sistema. Consulte Caminhos de dispositivos para obter mais detalhes.

  • Se um usuário padrão não for especificado, cada subcomando adb terá um usuário diferente. A prática recomendada é recuperar o ID do usuário com am get-current-user e, em seguida, usar explicitamente --user <userId> para qualquer comando que o suporte. As sinalizações de usuário explícitas 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 do Android 9. Consulte Provedor de conteúdo para dados multiusuários para obter detalhes sobre como recuperar arquivos durante o teste.

Provedor de conteúdo para dados multiusuário

Como adb é executado como o usuário do sistema e os dados são colocados em sandbox no Android 9 e versões posteriores, você deve usar provedores de conteúdo para enviar ou extrair quaisquer dados de teste de um usuário que não seja do sistema. Isto não é necessário se:

  • adbd está sendo executado como root (por meio adb root ), o que só é possível usando compilações userdebug ou usereng .

  • Você está usando ITestDevice da Trade Federation (Tradefed) para enviar/extrair os arquivos; nesse caso, use /sdcard/ paths em sua configuração de teste (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, você pode acessá-lo usando o comando adb shell content com o user apropriado, uri e outros parâmetros especificados.

Solução alternativa para desenvolvedores de aplicativos

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

  1. Crie uma instância de ContentProvider hospedada pelo aplicativo que pode servir/armazenar arquivos quando necessário. Use o armazenamento interno do aplicativo.
  2. Use comandos read ou write adb shell content para enviar/extrair os arquivos.

Solução alternativa para arquivos de mídia

Para enviar arquivos de mídia para a partição de mídia do cartão SD, use APIs públicas MediaStore . Por 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

Instalando um provedor de conteúdo genérico

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

Construa o TradefedContentProvider.apk a partir da fonte 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 multiusuário da Federação de Comércio

Tradefed é o equipamento de teste oficial do Android. Esta seção resume alguns dos suportes integrados do Tradefed para cenários de teste multiusuário.

Verificadores de status

Os verificadores de status do sistema (SSCs) são executados antes dos preparadores de destino e sua limpeza é executada depois desses preparadores.

UserChecker é definido explicitamente para ajudar os desenvolvedores ao testar vários usuários. Ele rastreia se um teste alterou o estado dos usuários no dispositivo (por exemplo, criou usuários sem removê-los na desmontagem). Além disso, se user-cleanup estiver definida, ela tentará limpar automaticamente após o teste, ao mesmo tempo em que fornecerá 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 alvo

Os preparadores de destino normalmente são usados ​​para configurar um dispositivo com uma configuração específica. No caso de testes multiusuário, os preparadores podem ser usados ​​para criar usuários de um tipo específico, bem como mudar para outros usuários.

Para tipos de dispositivos que não têm um usuário secundário, você pode 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 desejado já existir no dispositivo, use SwitchUserTargetPreparer para alternar para o usuário existente. 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 controlados por host

Em alguns casos, um teste precisa trocar de usuário dentro do teste . Não faça a mudança em uma estrutura de teste do lado do dispositivo, como UI Automator , porque o processo de teste pode ser encerrado a qualquer momento. Em vez disso, use uma estrutura de teste do lado do host, como Host-Driven Test Framework da Tradefed, que dá acesso a ITestDevice , permitindo qualquer manipulação necessária do usuário.

Use UserChecker (descrito em Verificadores de status ) para testes controlados por host que alteram o estado do usuário, pois garante que o teste seja limpo adequadamente.