Tester plusieurs utilisateurs

Cette page décrit les aspects importants du test de plusieurs utilisateurs sur la plateforme Android. Pour plus d'informations sur la mise en œuvre de la prise en charge multi-utilisateurs, consultez Prise en charge de plusieurs utilisateurs .

Chemins d'accès aux appareils

Le tableau suivant répertorie plusieurs chemins de périphérique et la manière dont ils sont résolus. Toutes les valeurs de la colonne Chemin correspondent à un stockage en bac à sable spécifique à l'utilisateur. L'histoire du stockage d'Android a changé au fil du temps ; lisez la documentation sur le stockage pour plus d’informations.

Chemin Chemin d'accès système (facultatif) But
/data/user/{userId}/{app.path} /data/data Stockage d'applications
/storage/emulated/{userId} /sdcard Stockage interne partagé
/data/media/{userId} aucun Données multimédias utilisateur (par exemple, musique, vidéos)
/data/system/users/{userId} aucun Configuration/état du système par utilisateur

Accessible uniquement par les applications système

Voici un exemple d'utilisation d'un chemin spécifique à l'utilisateur :

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

interactions adb entre les utilisateurs

Plusieurs commandes adb sont utiles lorsqu'il s'agit de plusieurs utilisateurs. Certaines de ces commandes ne sont prises en charge que sous Android 9 et versions ultérieures :

  • adb shell am instrument --user <userId> exécute un test d'instrumentation sur un utilisateur spécifique. Par défaut, cela utilise l'utilisateur actuel.
  • adb install --user <userId> installe un package pour un utilisateur spécifique. Pour garantir qu'un package est installé pour tous les utilisateurs, vous devez appeler ceci pour chaque utilisateur.
  • adb uninstall --user <userId> désinstalle un package pour un utilisateur spécifique. Appelez sans l'indicateur --user pour désinstaller pour tous les utilisateurs.
  • adb shell am get-current-user obtient l'ID utilisateur actuel (au premier plan).
  • adb shell pm list users obtient une liste de tous les utilisateurs existants.
  • adb shell pm create-user crée un nouvel utilisateur, renvoyant l'ID.
  • adb shell pm remove-user supprime un utilisateur spécifique par ID.
  • adb shell pm disable --user <userId> désactive un package pour un utilisateur spécifique.
  • adb shell pm enable --user <userId> active un package pour un utilisateur spécifique.
  • adb shell pm list packages --user <userId> répertorie les packages ( -e pour activé, -d pour désactivé) pour un utilisateur spécifique. Par défaut, cette liste est toujours destinée à l'utilisateur du système.

Les informations suivantes permettent d'expliquer comment adb se comporte avec plusieurs utilisateurs :

  • adb (ou plus précisément le démon adbd ) s'exécute toujours en tant qu'utilisateur système (ID utilisateur = 0) , quel que soit l'utilisateur actuel . Par conséquent, les chemins de périphérique qui dépendent de l'utilisateur (tels que /sdcard/ ) sont toujours résolus en tant qu'utilisateur système. Voir Chemins d'accès aux appareils pour plus de détails.

  • Si aucun utilisateur par défaut n'est spécifié, chaque sous-commande adb a un utilisateur différent. La meilleure pratique consiste à récupérer l'ID utilisateur avec am get-current-user , puis à utiliser explicitement --user <userId> pour toute commande qui le prend en charge. Les indicateurs d'utilisateur explicites n'étaient pas pris en charge pour toutes les commandes jusqu'à Android 9.

  • L'accès aux chemins /sdcard des utilisateurs secondaires est refusé à partir d'Android 9. Consultez Fournisseur de contenu pour les données multi-utilisateurs pour plus de détails sur la façon de récupérer des fichiers pendant les tests.

Fournisseur de contenu pour les données multi-utilisateurs

Étant donné adb s'exécute en tant qu'utilisateur système et que les données sont mises en sandbox dans Android 9 et versions ultérieures, vous devez utiliser des fournisseurs de contenu pour transmettre ou extraire les données de test d'un utilisateur non système. Cela n'est pas nécessaire si :

  • adbd s'exécute en tant que root (via adb root ), ce qui n'est possible qu'en utilisant les builds userdebug ou usereng .

  • Vous utilisez ITestDevice de Trade Federation (Tradefed) pour pousser/extraire les fichiers, auquel cas utilisez les chemins /sdcard/ dans votre configuration de test (par exemple, consultez le code source de pushFile dans NativeDevice.java ).

Lorsqu'un fournisseur de contenu s'exécute dans l'utilisateur secondaire, vous pouvez y accéder à l'aide de la commande adb shell content avec l' user , uri et d'autres paramètres appropriés spécifiés.

Solution de contournement pour les développeurs d'applications

Interagissez avec les fichiers de test à l'aide adb content et d'une instance de ContentProvider , au lieu de la commande push ou pull .

  1. Créez une instance de ContentProvider hébergée par l'application qui peut servir/stocker des fichiers si nécessaire. Utilisez le stockage interne de l'application.
  2. Utilisez les commandes read ou write adb shell content pour pousser/extraire les fichiers.

Solution de contournement pour les fichiers multimédias

Pour transférer des fichiers multimédias vers la partition multimédia de la carte SD, utilisez les API publiques MediaStore . Par exemple:

# 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

Installation d'un fournisseur de contenu générique

Installez et utilisez un fournisseur de contenu existant qui lit et écrit des fichiers dans le chemin /sdcard spécifique à l'utilisateur.

Créez le TradefedContentProvider.apk à partir de la source en utilisant 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
```

Prise en charge multi-utilisateurs de la Fédération du commerce

Tradefed est le harnais de test Android officiel. Cette section résume une partie de la prise en charge intégrée de Tradefed pour les scénarios de test multi-utilisateurs.

Vérificateurs de statut

Les vérificateurs d'état du système (SSC) sont exécutés avant les préparateurs cibles et leur nettoyage est exécuté après ces préparateurs.

UserChecker est défini explicitement pour aider les développeurs lors du test de plusieurs utilisateurs. Il permet de savoir si un test a modifié l'état des utilisateurs sur l'appareil (par exemple, des utilisateurs créés sans les supprimer lors du démontage). De plus, si user-cleanup est défini, il tente automatiquement d'effectuer un nettoyage après le test, tout en fournissant des erreurs utiles afin que le test puisse être corrigé.

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

Préparateur de cibles

Les préparateurs cibles sont généralement utilisés pour configurer un appareil avec une configuration particulière. Dans le cas de tests multi-utilisateurs, les préparateurs peuvent être utilisés pour créer des utilisateurs d'un type spécifique ainsi que pour passer à d'autres utilisateurs.

Pour les types d’appareils qui n’ont pas d’utilisateur secondaire, vous pouvez utiliser CreateUserPreparer pour créer et basculer vers un utilisateur secondaire dans AndroidTest.xml . A la fin du test, le préparateur revient en arrière et supprime l'utilisateur secondaire.

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

Si le type d'utilisateur souhaité existe déjà sur l'appareil, utilisez SwitchUserTargetPreparer pour basculer vers l'utilisateur existant. Les valeurs courantes pour user-type incluent system ou secondary .

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

Tests pilotés par l'hôte

Dans certains cas, un test doit changer d'utilisateur au sein du test . N'effectuez pas la transition à partir d'un framework de test côté appareil, tel que UI Automator , car le processus de test peut être interrompu à tout moment. Utilisez plutôt un framework de test côté hôte comme le Host-Driven Test Framework de Tradefed, qui donne accès à ITestDevice , permettant toute manipulation utilisateur nécessaire.

Utilisez UserChecker (décrit dans Status checkers ) pour les tests pilotés par l'hôte qui modifient l'état de l'utilisateur, car il garantit que le test se nettoie correctement après lui-même.