Testowanie wielu użytkowników

Na tej stronie opisaliśmy ważne aspekty testowania wielu użytkowników na platformie Android. Informacje o wdrożeniu 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 piaskownica dla 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 (opcjonalna) 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 na 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 instrumentacji na konkretnym użytkowniku. Domyślnie używany jest 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> odinstalowuje pakiet dla konkretnego użytkownika. Wywołaj bez flagi --user, aby odinstalować aplikację u 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ń zależne od użytkownika (takie jak /sdcard/) zawsze są rozwiązywane jako użytkownik systemu. Więcej informacji znajdziesz w sekcji Ścieżki urządzeń.

  • Jeśli nie określisz domyślnego użytkownika, każda komenda podrzędna adb będzie miała innego użytkownika. Sprawdzoną metodą jest pobranie identyfikatora użytkownika za pomocą narzędzia am get-current-user, a następnie bezpośrednie użycie polecenia --user <userId> w każdym poleceniu, które go obsługuje. Dopiero od Androida 9 flagi użytkownika były obsługiwane w przypadku wszystkich poleceń.

  • Od Androida 9 odmawiamy dostępu do ścieżek /sdcard użytkowników dodatkowych. Szczegółowe informacje o pobieraniu plików podczas testowania znajdziesz w artykule Dostawcy treści dla danych wielu użytkowników.

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

Aplikacja adb działa jako użytkownik systemowy, a dane są umieszczane w sandboksie w Androidzie 9 i nowszych, dlatego musisz używać dostawców treści, aby przesyłać lub pobierać dane testowe od użytkownika niesystemowego. 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 lub pobierania plików. W takim przypadku w konfiguracji testowej użyj ścieżek /sdcard/ (np. zobacz kod źródłowy pushFileNativeDevice.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 parametrami.

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

Korzystaj z plików testowych za pomocą 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.

Obejście problemu z plikami multimedialnymi

Aby przesłać pliki multimedialne na partycję multimediów na karcie 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 obecnego dostawcę treści, który odczytuje i zapisuje pliki w odpowiedniej dla użytkownika ścieżce /sdcard, i korzystaj z niej.

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 ramach 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 przygotowującymi, 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. utworzyli użytkowników bez ich usuwania). Dodatkowo, jeśli parametr user-cleanupjest ustawiony, test automatycznie usuwa błędy po jego zakończeniu, jednocześnie podając przydatne informacje o błędach, 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

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 przełączyć się na 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 musi przełączyć użytkowników w ramach testu. Nie przełączaj się z ramy testowej po stronie urządzenia, takiej jak 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żyj UserChecker (opisanego w funkcji sprawdzania stanu) w przypadku testów sterowanych przez hosta, które zmieniają stan użytkownika, ponieważ dzięki temu test będzie się prawidłowo zamykać.