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 Daemonadbd
) 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 mitam 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 (überadb root
), was nur mituserdebug
- oderusereng
-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ürpushFile
inNativeDevice.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.
- Von der Anwendung gehostete
ContentProvider
-Instanz erstellen, die Folgendes bereitstellen kann: und speichern Sie Dateien bei Bedarf. Verwenden Sie den internen Speicher der App. - Verwenden Sie die Befehle
adb shell content
,read
oderwrite
, 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.