Testare più utenti

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

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

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