À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

Tester plusieurs utilisateurs
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page décrit les aspects importants du test de plusieurs utilisateurs sur le 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 appareil

Le tableau suivant liste 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 sur 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 système (facultatif)	Objectif
`/data/user/{userId}/{app.path}`	`/data/data`	Stockage des applications
`/storage/emulated/{userId}`	`/sdcard`	Stockage interne partagé
`/data/media/{userId}`	none	Données multimédias de l'utilisateur (musique, vidéos, etc.)
`/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 pour traiter 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 s'assurer qu'un package est installé pour tous les utilisateurs, vous devez appeler cette méthode 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 (plan premier).
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 une utilisateur.
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ée, -d pour désactivée) pour un utilisateur spécifique. Par défaut, cette liste est toujours affichée pour l'utilisateur système.

Les informations suivantes expliquent comment adb se comporte 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 une valeur différente utilisateur. 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.
L'accès aux chemins /sdcard des utilisateurs secondaires est refusé à partir d'Android 9. Voir Fournisseur de contenu pour les données multi-utilisateurs pour savoir comment pour récupérer des fichiers pendant les tests.

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 exécutées en bac à sable dans Android 9 ou version ultérieure, vous devez utiliser des fournisseurs de contenu pour transférer ou extraire les données de test d’un utilisateur hors système. Cette étape n'est pas nécessaire si :

adbd est exécuté en tant que racine (via adb root), ce qui n'est possible qu'en utilisant Builds userdebug ou usereng.
Vous utilisez ITestDevice de Trade Federation (Tradefed) pour transférer les fichiers. Dans ce cas, utilisez des 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 les paramètres user, uri et autres appropriés spécifiés.

Solution 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éer une instance de ContentProvider hébergée par l'application pouvant être diffusée et stocker des fichiers si nécessaire. Utiliser la mémoire de stockage interne de l'application
Utilisez les commandes adb shell content, read ou write pour transférer ou extraire les fichiers.

Solution 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.

Compilez 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-utilisateur de la fédération de commerce

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 outils de vérification de l'é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. Il suit si un test a modifié l'état des utilisateurs de l'appareil (par exemple, créés par les utilisateurs sans les supprimer lors de la suppression). De plus, si user-cleanup est défini, il tente automatiquement de nettoyer après le test, tout en fournissant des erreurs utiles pour 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 cibles sont généralement utilisés pour configurer un appareil avec un configuration. Dans le cas des préparateurs de tests multi-utilisateurs peuvent être utilisés pour créer les utilisateurs d'un type spécifique ainsi que 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 une configuration côté hôte comme le framework de test géré par l'hôte de Tradefed framework, qui donne accès à ITestDevice, permettant toute manipulation utilisateur nécessaire.

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