Testare più utenti

Questa pagina descrive aspetti importanti del test di più utenti sulla piattaforma Android. Per informazioni sull'implementazione del supporto multiutente, vedi Supportare più utenti.

Percorsi per i dispositivi

La seguente tabella elenca alcuni percorsi del dispositivo e il modo in cui vengono risolti. Tutti i valori nella colonna Percorso sono uno spazio di archiviazione in sandbox specifico per l'utente. Lo spazio di archiviazione di Android è cambiato nel tempo. Per saperne di più, consulta la documentazione relativa allo spazio di archiviazione.

Ecco un esempio di utilizzo di un percorso specifico per l'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 su 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 assicurarti che un pacchetto sia installato per tutti gli utenti, devi chiamare questo per ogni utente.
• adb uninstall --user <userId> disinstalla un pacchetto per un utente specifico. Chiama senza il flag --user per disinstallare per tutti gli utenti.
• adb shell am get-current-user recupera l'ID utente corrente (in primo piano).
• adb shell pm list users riceve 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 in base all'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 attivato, -d per disattivato) per un utente specifico. Per impostazione predefinita, questo elenco è sempre per l'utente di sistema.

Le seguenti informazioni aiutano a spiegare come si comporta adb con più utenti:

• adb (o più precisamente il daemon adbd) viene sempre eseguito come utente di sistema (ID utente = 0) indipendentemente dall'utente corrente. Pertanto, i percorsi dei dispositivi che dipendono dall'utente (ad esempio /sdcard/) vengono sempre risolti come utente di sistema. Per maggiori dettagli, consulta Percorsi dei dispositivi.

• Se non viene specificato un utente predefinito, ogni comando secondario adb ha un utente diverso. La best practice consiste nel recuperare l'ID utente con am get-current-user e poi 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. Per informazioni dettagliate su come recuperare i file durante i test, consulta la sezione Fornitore di contenuti per dati multiutente.

Fornitore di contenuti per dati multiutente

Poiché adb viene eseguito come utente di sistema e i dati sono in sandbox in Android 9 e versioni successive, devi utilizzare i content provider per eseguire il push o il pull di qualsiasi dato di test da un utente non di sistema. Non è necessario se:

• adbd viene eseguito come root (tramite adb root), il che è possibile solo utilizzando le build userdebug o usereng.

• Stai utilizzando ITestDevice di Trade Federation (Tradefed) per eseguire il push o il pull dei file, nel qual caso utilizza i percorsi /sdcard/ nella configurazione del test (ad esempio, consulta il codice sorgente di pushFile in NativeDevice.java).

Quando un content provider è in esecuzione nell'utente secondario, puoi accedervi utilizzando il comando adb shell content con i parametri user, 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, anziché il comando push o pull.

1. Crea un'istanza di ContentProvider ospitata dall'app che può pubblicare e archiviare i file dove necessario. Utilizzare 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 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

Installa 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 di Trade Federation

Tradefed è il test harness ufficiale di Android. Questa sezione riassume alcuni dei supporti integrati di Tradefed per gli scenari di test multiutente.

Strumenti di controllo dello stato

I controlli dello stato del sistema (SSC) vengono eseguiti prima dei preparatori di destinazione e la loro pulizia viene eseguita dopo questi preparatori.

UserChecker è definito in modo esplicito per aiutare gli sviluppatori durante il test di più utenti. Monitora se un test ha modificato lo stato degli utenti sul dispositivo (ad esempio, ha creato utenti senza rimuoverli durante l'analisi). Inoltre, se è impostato 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>

Target preparer

I preparatori di destinazione vengono in genere utilizzati per configurare un dispositivo con una determinata configurazione. Nel caso di test multiutente, i preparatori 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 è già presente 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 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, ad esempio UI Automator, perché il processo di test può essere interrotto in qualsiasi momento. Utilizza invece un framework di test lato host come Host-driven test framework di Tradefed, che consente l'accesso a ITestDevice, permettendo qualsiasi manipolazione dell'utente necessaria.

Utilizza UserChecker (descritto in Controlli di stato) per i test basati sull'host che modificano lo stato dell'utente, perché garantisce che il test venga pulito correttamente.