Testowanie wielu użytkowników

Ta strona opisuje ważne aspekty testowania wielu użytkowników na platformie Android. Informacje o wdrażaniu obsługi wielu użytkowników znajdziesz w artykule Obsługa wielu użytkowników.

Ścieżki urządzeń

W tabeli poniżej znajdziesz kilka ścieżek urządzeń i sposobów ich rozwiązywania. Wszystkie wartości w kolumnie Ścieżka to odizolowane miejsce na dane konkretnego użytkownika. Miejsce na dane w Androidzie zmieniało się z czasem. Więcej informacji znajdziesz w dokumentacji dotyczącej miejsca na dane.

Ścieżka Ścieżka systemowa (opcjonalnie) Cel
/data/user/{userId}/{app.path} /data/data Pamięć aplikacji
/storage/emulated/{userId} /sdcard Udostępniona pamięć wewnętrzna
/data/media/{userId} brak dane multimedialne użytkownika (np. muzyka, filmy);
/data/system/users/{userId} brak Konfiguracja/stan systemu według użytkownika

Dostępny tylko dla aplikacji systemowych

Oto przykład użycia ścieżki dla konkretnego użytkownika:

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

interakcje adb między użytkownikami

W przypadku wielu użytkowników przydatne są niektóre polecenia adb. Niektóre z tych poleceń są obsługiwane tylko w Androidzie 9 i nowszych:

  • adb shell am instrument --user <userId> przeprowadza test z instrumentacją na konkretnym użytkowniku. Domyślnie jest używany bieżący użytkownik.
  • adb install --user <userId> instaluje pakiet dla konkretnego użytkownika. Aby mieć pewność, że pakiet jest zainstalowany dla wszystkich użytkowników, musisz wywołać tę funkcję dla każdego z nich.
  • adb uninstall --user <userId> odinstaluje pakiet dla konkretnego użytkownika. Wywołaj bez flagi --user, aby odinstalować aplikację dla wszystkich użytkowników.
  • adb shell am get-current-user zwraca identyfikator bieżącego (pierwotnego) użytkownika.
  • adb shell pm list users zwraca listę wszystkich obecnych użytkowników.
  • adb shell pm create-user tworzy nowego użytkownika i zwraca jego identyfikator.
  • adb shell pm remove-user usuwa określonego użytkownika według identyfikatora.
  • adb shell pm disable --user <userId> wyłącza pakiet dla konkretnego użytkownika.
  • adb shell pm enable --user <userId> włącza pakiet dla konkretnego użytkownika.
  • adb shell pm list packages --user <userId> zawiera listę pakietów (-e – włączone, -d – wyłączone) dla konkretnego użytkownika. Domyślnie jest to zawsze użytkownik systemowy.

Poniżej znajdziesz informacje o tym, jak działa adb w przypadku wielu użytkowników:

  • adb (a dokładniej demon adbd) zawsze działa jako systemowy użytkownik (identyfikator użytkownika = 0) niezależnie od tego, który użytkownik jest bieżący. Dlatego ścieżki urządzeń, które zależą od użytkownika (takie jak /sdcard/), zawsze są rozwiązywane jako użytkownik systemu. Więcej informacji znajdziesz w sekcji Ścieżki na urządzeniu.

  • Jeśli nie zostanie określony użytkownik domyślny, każdy podkomenda adb będzie miał innego użytkownika. Sprawdzoną metodą jest pobieranie identyfikatora użytkownika za pomocą funkcji am get-current-user, a następnie jawne użycie funkcji --user <userId> w przypadku dowolnego polecenia, które ją obsługuje. Dopiero od Androida 9 flagi użytkownika nie były obsługiwane w przypadku wszystkich poleceń.

  • Od Androida 9 dostęp do ścieżek /sdcard użytkowników dodatkowych jest zablokowany. Szczegółowe informacje o pobieraniu plików podczas testowania znajdziesz w artykule Dane wielu użytkowników – dostawca treści.

Dostawca treści dla danych wielu użytkowników

Aplikacja adb działa jako użytkownik systemowy, a dane są umieszczane w piaskownicy w Androidzie 9 i nowszych, dlatego do przesyłania i pobierania danych testowych od użytkownika niesystemowego musisz używać dostawców treści. Nie jest to konieczne, jeśli:

  • adbd działa jako root (poprzez adb root), co jest możliwe tylko w ramach wersji userdebug lub usereng.

  • Używasz pakietu Trade Federation (Tradefed) ITestDevice do przesyłania i ściągania plików. W takim przypadku w pliku testowym Config używaj ścieżek /sdcard/ (np. zobacz kod źródłowy pushFile w pliku NativeDevice.java).

Gdy dostawca treści działa na koncie użytkownika dodatkowego, możesz uzyskać do niego dostęp, używając polecenia adb shell content z odpowiednimi parametrami user, uri i innymi.

Sposób obejścia problemu przez deweloperów aplikacji

Interakcja z plikami testowymi za pomocą polecenia adb content i instancji ContentProvider zamiast polecenia push lub pull.

  1. Utwórz instancję ContentProvider hostowaną przez aplikację, która może udostępniać i przechowywać pliki w razie potrzeby. Korzystanie z pamięci wewnętrznej aplikacji.
  2. Użyj poleceń adb shell content read lub write, aby przesłać lub pobrać pliki.

Sposób obejścia problemu w przypadku plików multimedialnych

Aby przesłać pliki multimedialne na partycję multimediów karty SD, użyj publicznych interfejsów API MediaStore. Na przykład:

# 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

Instalowanie ogólnego dostawcy treści

Zainstaluj i użyj istniejącego dostawcy treści, który odczytuje i zapisze pliki na ścieżce /sdcard określonej dla danego użytkownika.

Utwórz TradefedContentProvider.apk na podstawie źródła za pomocą 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
```

Pomoc dla wielu użytkowników w Trade Federation

Tradefed to oficjalne narzędzie do testowania Androida. W tej sekcji omówiono niektóre wbudowane funkcje Tradefed na potrzeby testów z wieloma użytkownikami.

Sprawdzanie stanu

Sprawdzający stan systemu (SSC) są uruchamiane przed docelowymi narzędziami do przygotowywania danych, a ich czyszczenie jest wykonywane po tych narzędziach.

UserChecker jest zdefiniowany w sposób jawny, aby ułatwić programistom testowanie z udziałem wielu użytkowników. śledzi, czy test zmienił stan użytkowników na urządzeniu (np. czy utworzył użytkowników bez usuwania ich w ramach testu). Jeśli dodatkowo ustawisz parametr user-cleanup, test będzie automatycznie próbował wyczyścić dane po jego zakończeniu, a także podawać przydatne błędy, aby można było poprawić test.

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

Osoba przygotowująca dane docelowe

Przygotowywanie docelowych urządzeń jest zwykle wykorzystywane do konfigurowania urządzenia z określonymi ustawieniami. W przypadku testów z udziałem wielu użytkowników osoby przygotowujące mogą służyć do tworzenia użytkowników określonego typu i przełączania się między nimi.

W przypadku typów urządzeń, które nie mają drugiego użytkownika, możesz użyć CreateUserPreparer, aby utworzyć i przełączyć się na drugiego użytkownika w AndroidTest.xml. Po zakończeniu testu osoba przygotowująca dane przełącza się z powrotem i usuwa użytkownika dodatkowego.

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

Jeśli wybrany typ użytkownika już istnieje na urządzeniu, kliknij SwitchUserTargetPreparer, aby przejść do tego użytkownika. Typowe wartości w polu user-type to system lub secondary.

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

Testy sterowane przez hosta

W niektórych przypadkach test wymaga przełączenia użytkowników w ramach testu. Nie przełączaj się z ramy testowania po stronie urządzenia, np. UI Automator, ponieważ proces testowania może zostać przerwany w dowolnym momencie. Zamiast tego użyj frameworku testowego po stronie hosta, takiego jak framework testowy Host-driven firmy Tradefed, który zapewnia dostęp do ITestDevice, co umożliwia dowolną manipulację użytkownikami.

Używaj UserChecker (opisanego w funkcji sprawdzania stanu) w przypadku testów sterowanych przez hosta, które zmieniają stan użytkownika, ponieważ zapewnia to prawidłowe wyczyszczenie po teście.