Prueba varios usuarios

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En esta página, se describen aspectos importantes de la prueba de varios usuarios en la plataforma de Android. Para obtener información sobre la implementación de la compatibilidad con varios usuarios, consulta Cómo admitir varios usuarios.

Rutas de dispositivos

En la siguiente tabla, se enumeran varias de las rutas de acceso de los dispositivos y cómo se resuelven. Todos los valores de la columna Ruta corresponden a un almacenamiento en zona de pruebas específico del usuario. El almacenamiento de Android cambia con el tiempo. lee el Storage para obtener más información.

Este es un ejemplo del uso de una ruta de acceso específica para el usuario:

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

Interacciones de adb entre usuarios

Varios comandos adb son útiles cuando se trata de varios usuarios. Algunos de estos comandos solo son compatibles con Android 9 y mayor:

• adb shell am instrument --user <userId> ejecuta una prueba de instrumentación en relación con un usuario específico. De forma predeterminada, se usa el usuario actual.
• adb install --user <userId> instala un paquete para un usuario específico. Para asegúrate de que se instale un paquete para todos los usuarios, debes llamarlo para cada usuario.
• adb uninstall --user <userId> desinstala un paquete para un usuario específico. Llama sin la marca --user para desinstalar la app en todos los usuarios.
• adb shell am get-current-user obtiene el ID del usuario actual (en primer plano).
• adb shell pm list users obtiene una lista de todos los usuarios existentes.
• adb shell pm create-user crea un usuario nuevo y muestra el ID.
• adb shell pm remove-user quita un usuario específico por ID.
• adb shell pm disable --user <userId> inhabilita un paquete para un bucket específico usuario.
• adb shell pm enable --user <userId> habilita un paquete para un usuario específico.
• adb shell pm list packages --user <userId> muestra una lista de paquetes (-e para habilitado, -d para inhabilitado) de un usuario específico. De forma predeterminada, listas para el usuario del sistema.

La siguiente información ayuda a explicar cómo se comporta adb con varios usuarios:

• adb (o, con mayor precisión, el daemon adbd) siempre se ejecuta como el sistema user (user ID = 0) independientemente de cuál sea el usuario actual. Por lo tanto, las rutas de acceso del dispositivo que dependen del usuario (como /sdcard/) siempre se resuelven como el usuario del sistema. Para obtener más detalles, consulta Rutas de dispositivos.

• Si no se especifica un usuario predeterminado, cada subcomando adb tiene un usuario diferente. La práctica recomendada es recuperar el ID de usuario con am get-current-user y, luego, usa de forma explícita --user <userId> para cualquier comando que lo admita. Explícito Las marcas de usuario no eran compatibles con todos los comandos hasta Android 9.

• Se denegó el acceso a /sdcard rutas de usuarios secundarios a partir de Android 9 Consulta Proveedor de contenido para datos de varios usuarios para obtener detalles sobre cómo recuperar archivos durante las pruebas.

Proveedor de contenido para datos multiusuario

Debido a que adb se ejecuta como el usuario del sistema y los datos se encuentran en la zona de pruebas en Android 9 y versiones posteriores, debes usar proveedores de contenido para enviar o recuperar datos de prueba de un usuario que no sea del sistema. Esto no es necesario en los siguientes casos:

• adbd se ejecuta como raíz (a través de adb root), lo cual solo es posible si se usa Compilaciones userdebug o usereng.

• Estás usando ITestDevice de Trade Federation (Tradefed) para enviar o extraer archivos. En ese caso, usa las rutas de acceso /sdcard/ en la configuración de prueba (por ejemplo, consulta el código fuente de pushFile en NativeDevice.java).

Cuando se ejecuta un proveedor de contenido en el usuario secundario, puedes acceder a él Mediante el comando adb shell content con los valores de user, uri y otros parámetros especificados.

Solución para desarrolladores de apps

Interactúa con los archivos de prueba con adb content y una instancia de ContentProvider, en lugar del comando push o pull.

1. Crea una instancia de ContentProvider alojada por la app que pueda entregar contenido. y almacenar archivos cuando sea necesario. Usa el almacenamiento interno de la app.
2. Usa los comandos adb shell content read o write para enviar o extraer los archivos.

Solución para archivos multimedia

Para enviar archivos multimedia a la partición multimedia de la tarjeta SD, usa las APIs públicas de MediaStore. Por ejemplo:

# 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

Instala un proveedor de contenido genérico

Instala y usa un proveedor de contenido existente que lea y escriba archivos en la ruta de acceso /sdcard específica del usuario.

Compila el TradefedContentProvider.apk desde la fuente 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
```

Compatibilidad con varios usuarios de la Federación de Comercio

Tradefed es la Agente de prueba de Android En esta sección, se resumen algunas de las funciones compatibilidad con situaciones de prueba multiusuario.

Verificador de estado

Verificadores de estado del sistema (SSC) se ejecutan antes de los preparados de destino y su limpieza se ejecuta después a esos preparadores.

UserChecker se define de forma explícita para ayudar a los desarrolladores cuando prueban varios usuarios. Realiza un seguimiento de si una prueba cambió el estado de los usuarios en el dispositivo (por ejemplo, si se crearon usuarios sin quitarlos en el desmontaje). Además, si se configura user-cleanup, intenta limpiar automáticamente después de la prueba y, al mismo tiempo, proporciona errores útiles para que se pueda corregir la prueba.

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

Preparador de destino

Por lo general, los preparadores de destino se usan para configurar un dispositivo con una configuración particular. En el caso de las pruebas para varios usuarios, los preparadores se pueden usar para crear usuarios de un tipo específico y cambiar a otros usuarios.

En el caso de los tipos de dispositivos que no tienen un usuario secundario, puedes usar CreateUserPreparer para crear y cambiar a un usuario secundario en AndroidTest.xml Al final de la prueba, el preparador vuelve a cambiar y borra al usuario secundario.

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

Si el tipo de usuario que deseas ya existe en el dispositivo, usa SwitchUserTargetPreparer para cambiar al usuario existente. Entre los valores comunes para user-type, se incluyen system o secondary.

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

Pruebas controladas por el host

En algunos casos, una prueba debe cambiar de usuario dentro de la prueba. No realices el cambio desde un framework de prueba del dispositivo, como UI Automator, ya que el proceso de prueba se puede finalizar en cualquier momento. En su lugar, usa un framework de pruebas del host, como el framework de pruebas dirigido por el host de Tradefed, que brinda acceso a ITestDevice, lo que permite cualquier manipulación del usuario que sea necesaria.

Usa UserChecker (como se describe en verificadores de estado) para las pruebas controladas por el host que cambian el estado del usuario porque garantiza que la prueba se limpie correctamente después.