Mehrere Nutzer testen

Auf dieser Seite werden wichtige Aspekte beim Testen mehrerer Nutzer auf der Android-Plattform. 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 Speicherstrategie von Android hat sich im Laufe der Zeit verändert. lies die Weitere Informationen

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 bei mehreren Nutzern hilfreich. 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. Bis ein Paket für alle Nutzer installiert ist, müssen Sie diese Methode für jeden Nutzer.
  • adb uninstall --user <userId> deinstalliert ein Paket für einen bestimmten Nutzer. Rufen Sie ohne das Flag --user auf, um die App für alle Nutzer zu deinstallieren.
  • 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.
  • Mit adb shell pm remove-user wird ein bestimmter Nutzer anhand seiner ID entfernt.
  • 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> listet Pakete auf (-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 (oder genauer der Daemon adbd) wird immer als System ausgeführt. Nutzer (Nutzer-ID = 0) unabhängig davon, welcher Nutzer aktuell ist. Dementsprechend „Gerät“ nutzerabhängige Pfade (z. B. /sdcard/) werden immer wie folgt aufgelöst: Systemnutzer. 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 und dann explizit --user <userId> für jeden Befehl, der dies unterstützt. Explizite Nutzerflags wurden bis Android 9 nicht für alle Befehle unterstützt.

  • Der Zugriff auf /sdcard Pfade sekundärer Nutzer wird verweigert in Android 9 Weitere Informationen finden Sie unter Contentanbieter für Daten mehrerer Nutzer mit weiteren Informationen um während des Tests Dateien abzurufen.

Contentanbieter für Daten mehrerer Nutzer

Da adb als Systemnutzer ausgeführt wird und Daten in Android 9 und höher in einer Sandbox gespeichert werden, müssen Sie Inhaltsanbieter verwenden, um Testdaten von einem nicht systeminternen Nutzer zu pushen oder zu pullen. Das ist in folgenden Fällen nicht erforderlich:

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

  • Sie verwenden die Handelsföderation (Tradefed) ITestDevice um die Dateien zu übertragen oder abzurufen. Verwenden Sie in diesem Fall /sdcard/-Pfade in Ihrem Test. Config (siehe Quellcode für pushFile in NativeDevice.java).

Wenn ein Inhaltsanbieter im sekundären Nutzer ausgeführt wird, können Sie mit dem Befehl adb shell content und den entsprechenden Parametern user, uri und anderen auf ihn 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. Von der Anwendung gehostete ContentProvider-Instanz erstellen, die Folgendes bereitstellen kann: und speichern Sie Dateien bei Bedarf. 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

Um Mediendateien per Push in die Medienpartition der SD-Karte zu übertragen, verwende MediaStore Public APIs 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 Contentanbieter, der Dateien auf der nutzerspezifischen /sdcard-Pfad.

Erstellen Sie den 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
```

Support für mehrere Nutzer der Handelsföderation

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

Statusprüfer

Systemstatus-Checker (System Status Checkers, SSK) werden vor den Zielvorbereitenden und deren Bereinigung nach die Vorbereitungen treffen.

UserChecker 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

Ziel-Preparer werden üblicherweise verwendet, um ein Gerät mit einer bestimmten Konfiguration. Bei Tests mit mehreren Nutzern können Bereitsteller für Tests erstellt werden, eines bestimmten Typs sowie zu anderen Nutzern wechseln.

Für Gerätetypen, für die es keinen sekundären Nutzer gibt, können Sie CreateUserPreparer, um einen sekundären Nutzer zu erstellen und zu einem sekundären Nutzer zu wechseln AndroidTest.xml. Am Ende des Tests wechselt der Vortragende zurück und Dadurch wird der sekundäre Nutzer gelöscht.

<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 zu diesem 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>

Hostgesteuerte 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 eine Test-Framework wie den hostgesteuerten Test von Tradefed Framework die Ihnen Zugriff auf ITestDevice, sodass Nutzende mögliche Änderungen vornehmen können.

UserChecker verwenden (siehe Beschreibung in Statusprüfungen) für hostgesteuerte Tests, die sich ändern denn damit wird sichergestellt, dass der Test ordnungsgemäß bereinigt wird.