Cette page a été traduite par l'API Cloud Translation.

Tester plusieurs utilisateurs

Cette page décrit les aspects importants des tests de plusieurs utilisateurs sur la plate-forme Android. Pour en savoir plus sur l'implémentation de la compatibilité multi-utilisateur, consultez la section Prendre en charge plusieurs utilisateurs.

Chemins d'accès par appareils

Le tableau suivant répertorie plusieurs chemins d'accès aux appareils et la manière dont ils sont résolus. Toutes les valeurs de la colonne Chemin correspondent à un espace de stockage en bac à sable spécifique à l'utilisateur. L'histoire du stockage d'Android a changé au fil du temps. Pour en savoir plus, consultez la documentation sur le stockage.

Chemin d'accès	Chemin d'accès au système (facultatif)	Objectif
`/data/user/{userId}/{app.path}`	`/data/data`	Stockage des applications
`/storage/emulated/{userId}`	`/sdcard`	Espace de stockage interne partagé
`/data/media/{userId}`	none	Données multimédias de l'utilisateur (par exemple, musique, vidéos)
`/data/system/users/{userId}`	none	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 lorsque vous devez gérer plusieurs utilisateurs. Certaines de ces commandes ne sont compatibles qu'avec Android 9 ou version ultérieure:

adb shell am instrument --user <userId> exécute un test d'instrumentation sur un utilisateur spécifique. Par défaut, l'utilisateur actuel est utilisé.
adb install --user <userId> installe un package pour un utilisateur spécifique. Pour vous assurer qu'un package est installé pour tous les utilisateurs, vous devez l'appeler 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 récupère l'ID utilisateur actuel (au premier plan).
adb shell pm list users obtient la liste de tous les utilisateurs existants.
adb shell pm create-user crée un utilisateur et renvoie 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 affichée pour l'utilisateur système.

Les informations suivantes expliquent le comportement de adb avec plusieurs utilisateurs:

adb (ou plus précisément le daemon 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 d'appareil dépendants de l'utilisateur (tels que /sdcard/) sont toujours résolus en tant qu'utilisateur du système. Pour en savoir plus, consultez la section Chemins d'accès aux appareils.
Si aucun utilisateur par défaut n'est spécifié, chaque sous-commande adb a un utilisateur différent. Il est recommandé de récupérer l'ID utilisateur avec am get-current-user, puis d'utiliser explicitement --user <userId> pour toute commande compatible. Les indicateurs utilisateur explicites n'étaient pas compatibles avec toutes les commandes avant Android 9.
À partir d'Android 9, l'accès aux chemins /sdcard des utilisateurs secondaires est refusé. Pour savoir comment récupérer des fichiers lors des tests, consultez Fournisseur de contenu pour les données multi-utilisateurs.

Fournisseur de contenu pour les données multi-utilisateurs

Étant donné que adb s'exécute en tant qu'utilisateur système et que les données sont placées dans un bac à sable sous Android 9 et versions ultérieures, vous devez utiliser des fournisseurs de contenu pour envoyer ou extraire des données de test à partir d'un utilisateur non système. Cette étape n'est pas nécessaire si:

adbd s'exécute en tant que racine (via adb root), ce qui n'est possible qu'en utilisant des builds userdebug ou usereng.
Vous utilisez la méthode ITestDevice de la fédération commerciale (Tradefed) pour transférer ou extraire les fichiers. Dans ce cas, utilisez des chemins d'accès /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 les paramètres user, uri et autres appropriés spécifiés.

Solution de contournement pour les développeurs d'applications

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

Créez une instance de ContentProvider hébergée par l'application qui peut diffuser et stocker des fichiers si nécessaire. Utiliser la mémoire de stockage interne de l'application
Exécutez les commandes adb shell content read ou write pour transférer ou 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. 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

Installer un fournisseur de contenu générique

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

Créez TradefedContentProvider.apk à partir de la source à l'aide de 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
```

Compatibilité multi-utilisateur de Trade Federation

Tradefed est le harnais de test Android officiel. Cette section résume certaines fonctionnalités intégrées de Tradefed pour les scénarios de test multi-utilisateurs.

Outils de vérification de l'état

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 à tester plusieurs utilisateurs. Elle permet de savoir si un test a modifié l'état des utilisateurs de l'appareil (par exemple, s'il a créé des utilisateurs sans les supprimer lors de la suppression). En outre, 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 cible

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

Pour les types d'appareils qui ne disposent pas d'utilisateur secondaire, vous pouvez utiliser CreateUserPreparer pour créer un utilisateur secondaire et y passer dans AndroidTest.xml. À la fin du test, le préparateur revient à l'utilisateur principal 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 passer à l'utilisateur existant. Les valeurs courantes pour user-type sont 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 cours du test. Ne passez pas à un autre framework de test côté appareil, tel que UI Automator, car le processus de test peut être arrêté à tout moment. Utilisez plutôt un framework de test côté hôte, comme le framework de test basé sur l'hôte de Tradefed, qui permet d'accéder à ITestDevice, ce qui permet toute manipulation utilisateur nécessaire.

Utilisez UserChecker (décrit dans la section Outils de vérification de l'état) pour les tests gérés par l'hôte qui modifient l'état de l'utilisateur, car il garantit que le test se nettoie correctement.