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 do dispositivo

A tabela a seguir lista vários caminhos de dispositivo 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 de armazenamento do Android mudou ao longo do tempo; leia a documentação do Storage 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úsica, 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 como usar 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 desses 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 todos os usuários.
  • 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 (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> desativa 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 lista 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 do dispositivo dependentes do usuário (como /sdcard/ ) sempre são resolvidos como o usuário do sistema. Consulte Caminhos do dispositivo para obter mais detalhes.

  • Se um usuário padrão não for especificado, cada subcomando adb terá um usuário diferente. A melhor prática é recuperar o ID do usuário com am get-current-user e então explicitamente usar --user <userId> para qualquer comando que o suporte. Sinalizações de usuário explícitas não eram suportadas para 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ário 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 área restrita no Android 9 e superior, 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. Isso não é necessário se:

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

  • Você está usando ITestDevice da Trade Federation (Tradefed) para enviar/receber 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 os comandos adb shell content read ou write para enviar/puxar 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 as 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.

Crie 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 Trade Federation

Tradefed é o equipamento de teste oficial do Android. Esta seção resume parte do suporte interno 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 após esses 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 for definida, ela tentará automaticamente limpar após o teste, enquanto ainda 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 alvo

Os preparadores de destino geralmente são usados ​​para configurar um dispositivo com uma configuração específica. No caso de preparadores de teste multiusuário, podem ser usados ​​para criar usuários de um tipo específico, bem como alternar 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. 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 controlados por host

Em alguns casos, um teste precisa alternar os usuários dentro do teste . Não faça a troca de dentro de 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 a estrutura de teste acionada por host da Tradefed, que dá acesso a ITestDevice , permitindo qualquer manipulação do usuário que seja necessária.

Use UserChecker (descrito em Verificadores de status ) para testes controlados por host que alteram o estado do usuário porque ele garante que o teste seja devidamente limpo depois de si mesmo.