Testare più utenti

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina vengono descritti gli aspetti importanti del test di più utenti sul la piattaforma Android. Per informazioni sull'implementazione del supporto multiutente, vedi Supportare più utenti.

Percorsi dispositivo

La tabella seguente elenca diversi percorsi del dispositivo e la relativa risoluzione. Tutti i valori nella colonna Percorso sono uno spazio di archiviazione con 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.

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 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 superiore:

• 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. A per assicurarti che sia installato un pacchetto per tutti gli utenti, devi chiamare questo 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 ottiene 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 e restituisce 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 attivata, -d per disattivata) per un utente specifico. Per impostazione predefinita, per l'utente del sistema.

Le seguenti informazioni spiegano il comportamento di adb con più utenti:

• adb (o, in modo più preciso, il daemon adbd) viene sempre eseguito come sistema user (ID utente = 0) indipendentemente da quale utente sia corrente. Di conseguenza, il dispositivo i percorsi dipendenti dall'utente (ad esempio /sdcard/) si risolvono sempre come l'utente del sistema. Per ulteriori dettagli, consulta Percorsi del dispositivo.

• Se non viene specificato un utente predefinito, ogni comando secondario adb ha un utente diverso. La best practice consiste nel recuperare lo User-ID con am get-current-user e poi usare esplicitamente --user <userId> per qualsiasi comando che lo supporta. Esplicito i flag utente non erano supportati per tutti i comandi fino ad Android 9.

• L'accesso a /sdcard percorsi di utenti secondari verrà negato a partire tra Android 9. Consulta Fornitore di contenuti per i dati multiutente per informazioni dettagliate su come per recuperare i file durante il test.

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 essere gestita e archiviare i file dove necessario. Utilizza la memoria interna dell'app.
2. Utilizza 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

Installare e utilizzare un fornitore di contenuti esistente che legga e scriva file nel percorso /sdcard specifico per l'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 della Trade Federation

Tradefed è il test harness ufficiale di Android. Questa sezione riassume alcune delle funzionalità di supporto predefinite di TradeFed per gli scenari di test multiutente.

Controlli di stato

Controlli dello stato del sistema (SSC) vengono eseguiti prima dei preparativi target e la loro pulizia viene eseguita dopo i 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 del target vengono in genere usati per configurare un dispositivo con un particolare configurazione. Nel caso dei preparativi dei test multiutente, è possibile usare utenti di un determinato tipo 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 e elimina l'utente secondario.

<target_preparer
  class="com.google.android.tradefed.targetprep.CreateUserPreparer" >
</target_preparer>

Se il tipo di utente desiderato esiste già sul dispositivo, utilizza 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 su 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.