Questa pagina descrive aspetti importanti del test di più utenti sulla piattaforma Android. Per informazioni sull'implementazione del supporto multiutente, vedere Supporto di più utenti .
Percorsi del dispositivo
La tabella seguente elenca diversi percorsi del dispositivo e il modo in cui vengono risolti. Tutti i valori nella colonna Percorso rappresentano un archivio sandbox specifico dell'utente. La storia dello spazio di archiviazione di Android è cambiata nel tempo; leggere la documentazione relativa allo storage per ulteriori informazioni.
Sentiero | Percorso di sistema (facoltativo) | Scopo |
---|---|---|
/data/user/{userId}/{app.path} | /data/data | Archiviazione dell'app |
/storage/emulated/{userId} | /sdcard | Memoria interna condivisa |
/data/media/{userId} | nessuno | Dati multimediali dell'utente (ad esempio musica, video) |
/data/system/users/{userId} | nessuno | Configurazione/stato del sistema per utente Accessibile solo dalle app di sistema |
Ecco un esempio di utilizzo di un percorso specifico dell'utente:
# to access user 10's private application data for app com.bar.foo:
$ adb shell ls /data/user/10/com.bar.foo/
interazioni adb tra gli utenti
Diversi comandi adb
sono utili quando si ha a che fare con più utenti. Alcuni di questi comandi sono supportati solo in Android 9 e versioni successive:
-
adb shell am instrument --user <userId>
esegue un test di strumentazione su un utente specifico. Per impostazione predefinita, viene utilizzato l'utente corrente. -
adb install --user <userId>
installa un pacchetto per un utente specifico. Per garantire che un pacchetto sia installato per tutti gli utenti, è necessario richiamarlo per ogni utente. -
adb uninstall --user <userId>
disinstalla un pacchetto per un utente specifico. Chiama senza il flag--user
per eseguire la disinstallazione per tutti gli utenti. -
adb shell am get-current-user
ottiene l'ID utente corrente (in primo piano). -
adb shell pm list users
ottiene un elenco di tutti gli utenti esistenti. -
adb shell pm create-user
crea un nuovo utente, restituendo l'ID. -
adb shell pm remove-user
rimuove un utente specifico in base all'ID. -
adb shell pm disable --user <userId>
disabilita un pacchetto per un utente specifico. -
adb shell pm enable --user <userId>
abilita un pacchetto per un utente specifico. -
adb shell pm list packages --user <userId>
elenca i pacchetti (-e
per abilitato,-d
per disabilitato) per un utente specifico. Per impostazione predefinita, viene sempre elencato per l'utente del sistema.
Le seguenti informazioni aiutano a spiegare come si comporta adb
con più utenti:
adb
(o più precisamente il demoneadbd
) viene sempre eseguito come utente di sistema (ID utente = 0) indipendentemente da quale utente sia corrente . Pertanto i percorsi del dispositivo che dipendono dall'utente (come/sdcard/
) si risolvono sempre come utente del sistema. Vedi Percorsi del dispositivo per maggiori dettagli.Se non viene specificato un utente predefinito, ogni sottocomando
adb
ha un utente diverso. La procedura migliore consiste nel recuperare l'ID utente conam get-current-user
e quindi utilizzare esplicitamente--user <userId>
per qualsiasi comando che lo supporti. I flag utente espliciti non erano supportati per tutti i comandi fino ad Android 9.L'accesso ai percorsi
/sdcard
degli utenti secondari è negato a partire da Android 9. Consulta Provider di contenuti per dati multiutente per dettagli su come recuperare i file durante il test.
Fornitore di contenuti per dati multiutente
Poiché adb
viene eseguito come utente di sistema e i dati sono sottoposti a sandbox in Android 9 e versioni successive, è necessario utilizzare i provider di contenuti per inviare o estrarre qualsiasi dato di test da un utente non di sistema. Ciò non è necessario se:
adbd
è in esecuzione come root (tramiteadb root
), cosa possibile solo utilizzando le builduserdebug
ousereng
.Stai utilizzando
ITestDevice
di Trade Federation (Tradefed) per eseguire il push/pull dei file, nel qual caso utilizza/sdcard/
percorsi nella configurazione di test (ad esempio, vedi il codice sorgente perpushFile
inNativeDevice.java
).
Quando un fornitore di contenuti è in esecuzione nell'utente secondario, puoi accedervi utilizzando il comando adb shell content
con l' user
appropriato, uri
e altri parametri specificati.
Soluzione alternativa per gli sviluppatori di app
Interagisci con i file di test utilizzando adb content
e un'istanza di ContentProvider
, invece del comando push
o pull
.
- Crea un'istanza di
ContentProvider
ospitata dall'app che possa servire/archiviare file dove necessario. Utilizza la memoria interna dell'app. - Utilizza
adb shell content
read
owrite
comandi per eseguire il push/pull dei file.
Soluzione alternativa per i file multimediali
Per inviare file multimediali alla partizione multimediale della scheda SD, utilizzare le API pubbliche MediaStore
. Per esempio:
# 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
Installazione di un fornitore di contenuti generico
Installa e utilizza un provider di contenuti esistente che legge e scrive file nel percorso /sdcard
specifico dell'utente.
Crea TradefedContentProvider.apk
dall'origine utilizzando 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
```
Supporto multiutente della Federazione dei Mercanti
Tradefed è il sistema di test Android ufficiale. Questa sezione riassume parte del supporto integrato di Tradefed per scenari di test multiutente.
Controllori dello stato
I controlli dello stato del sistema (SSC) vengono eseguiti prima dei preparatori di destinazione e la loro pulizia viene eseguita dopo tali preparatori.
UserChecker
è definito esplicitamente per aiutare gli sviluppatori durante il test di più utenti. Tiene traccia se un test ha modificato lo stato degli utenti sul dispositivo (ad esempio, ha creato utenti senza rimuoverli durante lo smontaggio). Inoltre, se è impostata user-cleanup
, tenta automaticamente di eseguire la pulizia dopo il test, fornendo comunque errori utili in modo che il test possa essere corretto.
<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
<option name="user-cleanup" value="true" />
</system_checker>
Preparatore di obiettivi
I preparatori di target vengono generalmente utilizzati per impostare un dispositivo con una configurazione particolare. Nel caso di test multiutente è possibile utilizzare i preparatori per creare utenti di un tipo specifico e passare ad altri utenti.
Per i tipi di dispositivi che non hanno un utente secondario, puoi utilizzare CreateUserPreparer
per creare e passare a un utente secondario in AndroidTest.xml
. Al termine del test il preparatore torna indietro ed elimina l'utente secondario.
<target_preparer
class="com.google.android.tradefed.targetprep.CreateUserPreparer" >
</target_preparer>
Se il tipo di utente desiderato esiste già nel dispositivo, utilizzare SwitchUserTargetPreparer
per passare all'utente esistente. I valori comuni per user-type
includono system
o secondary
.
<target_preparer
class="com.android.tradefed.targetprep.SwitchUserTargetPreparer">
<option name="user-type" value="secondary" />
</target_preparer>
Test guidati dall'host
In alcuni casi, un test deve cambiare utente all'interno del test . Non effettuare il passaggio da un framework di test lato dispositivo, come UI Automator , perché il processo di test potrebbe essere interrotto in qualsiasi momento. Utilizzare invece un framework di test lato host come Host-Driven Test Framework di Tradefed, che fornisce l'accesso a ITestDevice
, consentendo qualsiasi manipolazione da parte dell'utente necessaria.
Utilizza UserChecker
(descritto in Controllo dello stato ) per i test gestiti dall'host che modificano lo stato dell'utente perché garantisce che il test si ripulisca correttamente.