Mehrere Nutzer testen

Auf dieser Seite werden wichtige Aspekte des Testens mehrerer Nutzer auf der Android-Plattform beschrieben. Informationen zur Implementierung der Unterstützung mehrerer Nutzer finden Sie unter Mehrere Nutzer unterstützen.

Gerätepfade

In der folgenden Tabelle sind einige Gerätepfade und deren Auflösung aufgeführt. Alle Werte in der Spalte Pfad sind nutzerspezifischer Speicher in einer Sandbox. Die Speichernutzung bei Android hat sich im Laufe der Zeit geändert. Weitere Informationen finden Sie in der Speicherdokumentation.

Pfad Systempfad (optional) Zweck
/data/user/{userId}/{app.path} /data/data App-Speicher
/storage/emulated/{userId} /sdcard Freigegebener interner Speicher
/data/media/{userId} Keine Mediendaten von Nutzern (z. B. Musik, Videos)
/data/system/users/{userId} Keine Systemkonfiguration/-status pro Nutzer

Nur von System-Apps zugänglich

Hier ein Beispiel für die Verwendung eines nutzerspezifischen Pfads:

# to access user 10's private application data for app com.bar.foo:
$ adb shell ls /data/user/10/com.bar.foo/

adb-Interaktionen zwischen Nutzern

Mehrere adb-Befehle sind nützlich, wenn Sie mit mehreren Nutzern arbeiten. Einige dieser Befehle werden nur unter Android 9 und höher unterstützt:

  • adb shell am instrument --user <userId> führt einen Instrumentierungstest für einen bestimmten Nutzer aus. Standardmäßig wird der aktuelle Nutzer verwendet.
  • adb install --user <userId> installiert ein Paket für einen bestimmten Nutzer. Damit ein Paket für alle Nutzer installiert wird, müssen Sie diesen Befehl für jeden Nutzer aufrufen.
  • adb uninstall --user <userId> deinstalliert ein Paket für einen bestimmten Nutzer. Wenn Sie die Funktion für alle Nutzer deinstallieren möchten, rufen Sie sie ohne das Flag --user auf.
  • Mit adb shell am get-current-user wird die aktuelle Nutzer-ID (im Vordergrund) abgerufen.
  • adb shell pm list users ruft eine Liste aller vorhandenen Nutzer ab.
  • adb shell pm create-user erstellt einen neuen Nutzer und gibt die ID zurück.
  • adb shell pm remove-user entfernt einen bestimmten Nutzer anhand der ID.
  • adb shell pm disable --user <userId> deaktiviert ein Paket für einen bestimmten Nutzer.
  • adb shell pm enable --user <userId> aktiviert ein Paket für einen bestimmten Nutzer.
  • adb shell pm list packages --user <userId> enthält Pakete (-e für aktiviert, -d für deaktiviert) für einen bestimmten Nutzer. Standardmäßig wird immer die Liste für den Systemnutzer angezeigt.

Im Folgenden wird erläutert, wie sich adb bei mehreren Nutzern verhält:

  • adb (genauer gesagt der adbd-Daemon) wird immer als Systemnutzer (Nutzer-ID = 0) ausgeführt, unabhängig davon, welcher Nutzer gerade aktiv ist. Daher werden nutzerabhängige Gerätepfade wie /sdcard/ immer als Systemnutzer aufgelöst. Weitere Informationen finden Sie unter Gerätepfade.

  • Wenn kein Standardnutzer angegeben ist, hat jeder adb-Unterbefehl einen anderen Nutzer. Die Best Practice besteht darin, die User-ID mit am get-current-user abzurufen und dann explizit --user <userId> für jeden Befehl zu verwenden, der sie unterstützt. Explizite Nutzerflaggen wurden bis Android 9 nicht für alle Befehle unterstützt.

  • Der Zugriff auf /sdcard-Pfade von sekundären Nutzern wird ab Android 9 verweigert. Weitere Informationen zum Abrufen von Dateien während der Tests finden Sie unter Contentanbieter für Daten mehrerer Nutzer.

Contentanbieter für Daten mehrerer Nutzer

Da adb als Systemnutzer ausgeführt wird und die Daten unter Android 9 und höher in einer Sandbox ausgeführt werden, müssen Sie Contentanbieter verwenden, um Testdaten von einem Nutzer außerhalb des Systems zu übertragen oder abzurufen. Das ist nicht erforderlich, wenn:

  • adbd wird als Root (über adb root) ausgeführt, was nur mit userdebug- oder usereng-Builds möglich ist.

  • Sie verwenden das ITestDevice von Trade Federation (Tradefed) zum Übertragen oder Abrufen der Dateien. Verwenden Sie in diesem Fall /sdcard/-Pfade in Ihrer Testkonfiguration (siehe Quellcode für pushFile in NativeDevice.java).

Wenn ein Contentanbieter im sekundären Nutzer ausgeführt wird, können Sie mit dem Befehl adb shell content und den entsprechenden user-, uri- und anderen Parametern darauf zugreifen.

Problemumgehung für App-Entwickler

Sie können mit Testdateien über adb content und eine Instanz von ContentProvider interagieren, anstatt den Befehl push oder pull zu verwenden.

  1. Erstellen Sie eine von der App gehostete Instanz von ContentProvider, die Dateien bei Bedarf bereitstellen und speichern kann. Verwenden Sie den internen Speicher der App.
  2. Verwenden Sie die Befehle adb shell content read oder write, um die Dateien hoch- oder herunterzuladen.

Problemumgehung für Mediendateien

Verwenden Sie öffentliche MediaStore-APIs, um Mediendateien in die Medienpartition der SD-Karte zu übertragen. Beispiel:

# 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

Generischen Contentanbieter installieren

Installieren und verwenden Sie einen vorhandenen Inhaltsanbieter, der Dateien in den nutzerspezifischen /sdcard-Pfad liest und schreibt.

Erstellen Sie die TradefedContentProvider.apk aus der Quelle mit 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
```

Unterstützung mehrerer Nutzer für Trade Federation

Tradefed ist der offizielle Android-Test-Harness. In diesem Abschnitt werden einige der integrierten Funktionen von Tradefed für Tests mit mehreren Nutzern zusammengefasst.

Statusprüfer

Systemstatusprüfer (SSCs) werden vor den Zielvorbereitungen ausgeführt und die Bereinigung wird nach diesen Vorbereitungen ausgeführt.

UserChecker wurde ausdrücklich definiert, um Entwicklern beim Testen mehrerer Nutzer zu helfen. Es wird erfasst, ob sich durch einen Test der Status der Nutzer auf dem Gerät geändert hat, z. B. ob Nutzer erstellt wurden, ohne sie beim Rückbau zu entfernen. Wenn user-cleanup festgelegt ist, wird nach dem Test automatisch versucht, die Umgebung zu bereinigen. Außerdem werden hilfreiche Fehlermeldungen ausgegeben, damit der Test korrigiert werden kann.

<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
    <option name="user-cleanup" value="true" />
</system_checker>

Target Preparer

Zielvorbereitungen werden in der Regel verwendet, um ein Gerät mit einer bestimmten Konfiguration einzurichten. Bei Tests mit mehreren Nutzern können Sie mithilfe von Vorbereitenden Nutzer eines bestimmten Typs erstellen und zu anderen Nutzern wechseln.

Bei Gerätetypen ohne sekundären Nutzer können Sie unter CreateUserPreparer einen sekundären Nutzer erstellen und zu diesem wechseln.AndroidTest.xml Am Ende des Tests wechselt der Vorbereiter zurück und löscht den sekundären Nutzer.

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

Wenn der gewünschte Nutzertyp bereits auf dem Gerät vorhanden ist, wechseln Sie mit SwitchUserTargetPreparer zum vorhandenen Nutzer. Gängige Werte für user-type sind system oder secondary.

<target_preparer
  class="com.android.tradefed.targetprep.SwitchUserTargetPreparer">
    <option name="user-type" value="secondary" />
</target_preparer>

Host-driven tests

In einigen Fällen muss in einem Test innerhalb des Tests der Nutzer gewechselt werden. Führen Sie den Wechsel nicht über ein geräteseitiges Test-Framework wie UI Automator aus, da der Testvorgang jederzeit beendet werden kann. Verwenden Sie stattdessen ein hostseitiges Test-Framework wie das hostgestützte Test-Framework von Tradefed, das Zugriff auf ITestDevice gewährt und alle erforderlichen Nutzermanipulationen ermöglicht.

Verwenden Sie UserChecker (unter Statusprüfungen beschrieben) für hostgesteuerte Tests, bei denen der Nutzerstatus geändert wird, weil damit sichergestellt wird, dass der Test im Anschluss ordnungsgemäß bereinigt wird.