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émonadbd
) 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 avecam 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 (viaadb root
), ce qui n'est possible qu'en utilisant les buildsuserdebug
ouusereng
.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 depushFile
dansNativeDevice.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
.
- 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. - Utilisez les commandes
read
ouwrite
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.