Testare più utenti

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 daemon adbd) 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 con am 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 (tramite adb root), il che è possibile solo utilizzando le build userdebug o usereng.

  • 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 di pushFile in NativeDevice.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.

  1. Crea un'istanza di ContentProvider ospitata dall'app che possa caricare e memorizzare i file dove necessario. Utilizza la memoria interna dell'app.
  2. Usa i comandi adb shell content read o write 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.