Questa pagina descrive aspetti importanti del test di più utenti sulla piattaforma Android. Per informazioni sull'implementazione del supporto multiutente, consulta Supportare più utenti.
Percorsi dei dispositivi
La tabella seguente elenca diversi percorsi del dispositivo e la relativa risoluzione. Tutti i valori nella colonna Percorso sono uno spazio di archiviazione in sandbox specifico per l'utente. La storia dello spazio di archiviazione di Android è cambiata nel tempo. Per saperne di più, consulta la documentazione relativa allo spazio di archiviazione.
Percorso | Percorso di sistema (facoltativo) | Finalità |
---|---|---|
/data/user/{userId}/{app.path}
|
/data/data
|
Spazio di archiviazione app |
/storage/emulated/{userId}
|
/sdcard
|
Spazio di archiviazione interno condiviso |
/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 per 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 soltanto su Android 9 e versioni successive:
adb shell am instrument --user <userId>
esegue un test di strumentazione con un utente specifico. Per impostazione predefinita viene utilizzato l'utente corrente.adb install --user <userId>
installa un pacchetto per un utente specifico. Per assicurarti che un pacchetto sia installato per tutti gli utenti, devi chiamare questa funzione per ogni utente.adb uninstall --user <userId>
disinstalla un pacchetto per un utente specifico. Esegui la chiamata senza il flag--user
per la disinstallazione per tutti gli utenti.adb shell am get-current-user
recupera l'ID utente corrente (in primo piano).adb shell pm list users
restituisce 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 tramite ID.adb shell pm disable --user <userId>
disattiva un pacchetto per un utente specifico.adb shell pm enable --user <userId>
attiva un pacchetto per un utente specifico.adb shell pm list packages --user <userId>
elenca i pacchetti (-e
per abilitato,-d
per disabilitato) per uno specifico utente. Per impostazione predefinita, viene sempre visualizzato per l'utente di sistema.
Le seguenti informazioni aiutano a spiegare il comportamento di adb
con più utenti:
adb
(o, più precisamente, il daemonadbd
) viene sempre eseguito come utente di sistema (ID utente = 0), indipendentemente da quale utente sia corrente. Pertanto, i percorsi del dispositivo dipendenti dall'utente (ad esempio/sdcard/
) vengono sempre risolti come utente di sistema. Per ulteriori dettagli, consulta Percorsi del dispositivo.Se non è specificato un utente predefinito, ogni sottocomando
adb
avrà un utente diverso. La best practice è recuperare l'ID utente conam get-current-user
e poi utilizzare esplicitamente--user <userId>
per qualsiasi comando che lo supporti. I flag dell'utente espliciti non erano supportati per tutti i comandi fino ad Android 9.L'accesso a
/sdcard
percorsi di utenti secondari è negato a partire da Android 9. Per informazioni dettagliate su come recuperare i file durante il test, consulta Fornitore di contenuti per dati multiutente.
Fornitore di contenuti per dati di più utenti
Poiché adb
viene eseguito come utente di sistema e i dati sono in sandbox in Android 9 e versioni successive, devi utilizzare i fornitori di contenuti per inviare o recuperare i dati di test da un utente non di sistema. Questa operazione non è necessaria se:
adbd
viene eseguito come root (tramiteadb root
), il che è possibile solo utilizzando le builduserdebug
ousereng
.Utilizzi
ITestDevice
di Trade Federation (TradeFed) per spingere o estrarre i file. In questo caso, utilizza i percorsi/sdcard/
nella configurazione del test (ad esempio, consulta il codice sorgente dipushFile
inNativeDevice.java
).
Quando un provider di contenuti è in esecuzione nell'utente secondario, puoi accedervi utilizzando il comando adb shell content
con i parametri user
, uri
e altri parametri appropriati 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 caricare e memorizzare i file dove necessario. Utilizza la memoria interna dell'app. - Usa i comandi
adb shell content
read
owrite
per eseguire il push o il pull dei file.
Soluzione alternativa per i file multimediali
Per trasferire i file multimediali nella partizione multimediale della scheda SD, utilizza le API pubbliche di MediaStore
. Ad 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
Installare un fornitore di contenuti generico
Installa e utilizza un provider di contenuti esistente che legga e scriva file nel percorso /sdcard
specifico dell'utente.
Crea TradefedContentProvider.apk
dal codice sorgente 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 di Trade Federation
Tradefed è il test harness ufficiale di Android. Questa sezione riassume alcuni del supporto integrato di Tradefed per scenari di test multiutente.
Verificatori dello stato
I controllori dello stato del sistema (SSC) vengono eseguiti prima dei preparativi di destinazione e la loro pulizia viene eseguita dopo questi preparativi.
UserChecker
viene definito esplicitamente per aiutare gli sviluppatori a testare più utenti. Monitora se un test ha modificato lo stato degli utenti sul dispositivo (ad esempio, se ha creato utenti senza rimuoverli nel teardown). Inoltre, se è impostato user-cleanup
, viene eseguito automaticamente il tentativo di pulizia dopo il test, fornendo al contempo errori utili per la correzione del test.
<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
<option name="user-cleanup" value="true" />
</system_checker>
Preparatore target
I preparativi della destinazione in genere vengono utilizzati per impostare un dispositivo con una particolare configurazione. Nel caso di test multiutente, i preparativi possono essere utilizzati 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 che vuoi esiste già sul dispositivo, usa
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 basati sull'host
In alcuni casi, un test deve cambiare utente all'interno del test. Non eseguire il passaggio da un framework di test lato dispositivo, come UI Automator, perché il processo di test può essere interrotto in qualsiasi momento. Utilizza invece un framework di test lato host come il framework di test basato sull'host di Tradefed, che consente di accedere a ITestDevice
e di eseguire qualsiasi manipolazione da parte dell'utente.
Utilizza UserChecker
(descritto in
Controllori dello stato) per i test basati sull'host che modificano
lo stato dell'utente perché garantisce che il test elimini correttamente i dati al termine.