Testowanie wielu użytkowników

Na tej stronie opisano ważne aspekty testowania wielu użytkowników na platformie Android. Aby uzyskać informacje na temat wdrażania obsługi wielu użytkowników, zobacz temat Obsługa wielu użytkowników .

Ścieżki urządzeń

W poniższej tabeli wymieniono kilka ścieżek urządzeń oraz sposoby ich rozwiązywania. Wszystkie wartości w kolumnie Ścieżka dotyczą magazynu w trybie piaskownicy specyficznego dla użytkownika. Historia pamięci masowej Androida zmieniała się z biegiem czasu; Aby uzyskać więcej informacji, przeczytaj dokumentację dotyczącą przechowywania .

Ścieżka Ścieżka systemowa (opcjonalnie) Zamiar
/data/user/{userId}/{app.path} /data/data Przechowywanie aplikacji
/storage/emulated/{userId} /sdcard Udostępniona pamięć wewnętrzna
/data/media/{userId} nic Dane multimedialne użytkownika (na przykład muzyka, filmy)
/data/system/users/{userId} nic Konfiguracja/stan systemu na użytkownika

Dostępne tylko przez aplikacje systemowe

Oto przykład użycia ścieżki specyficznej dla 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

Kilka poleceń adb jest przydatnych w przypadku wielu użytkowników. Niektóre z tych poleceń są obsługiwane tylko w systemie Android 9 i nowszych wersjach:

  • adb shell am instrument --user <userId> uruchamia test oprzyrządowania dla określonego użytkownika. Domyślnie używa bieżącego użytkownika.
  • adb install --user <userId> instaluje pakiet dla określonego użytkownika. Aby zagwarantować, że pakiet zostanie zainstalowany dla wszystkich użytkowników, musisz wywołać tę opcję dla każdego użytkownika.
  • adb uninstall --user <userId> odinstalowuje pakiet dla określonego użytkownika. Wywołaj bez flagi --user , aby odinstalować dla wszystkich użytkowników.
  • adb shell am get-current-user pobiera bieżący (pierwszy plan) identyfikator użytkownika.
  • adb shell pm list users pobiera listę wszystkich istniejących użytkowników.
  • adb shell pm create-user tworzy nowego użytkownika, zwracając identyfikator.
  • adb shell pm remove-user usuwa określonego użytkownika według identyfikatora.
  • adb shell pm disable --user <userId> wyłącza pakiet dla określonego użytkownika.
  • adb shell pm enable --user <userId> włącza pakiet dla określonego użytkownika.
  • adb shell pm list packages --user <userId> wyświetla listę pakietów ( -e dla włączonych, -d dla wyłączonych) dla określonego użytkownika. Domyślnie zawsze jest to lista dla użytkownika systemowego.

Poniższe informacje pomagają wyjaśnić, jak zachowuje się adb w przypadku wielu użytkowników:

  • adb (a dokładniej demon adbd ) zawsze działa jako użytkownik systemowy (ID użytkownika = 0) niezależnie od tego, który użytkownik jest aktualny . Dlatego ścieżki urządzeń zależne od użytkownika (takie jak /sdcard/ ) zawsze są rozpoznawane jako użytkownik systemowy. Aby uzyskać więcej informacji, zobacz Ścieżki urządzeń .

  • Jeśli nie określono domyślnego użytkownika, każda podkomenda adb ma innego użytkownika. Najlepszą praktyką jest pobranie identyfikatora użytkownika za pomocą polecenia am get-current-user , a następnie jawne użycie --user <userId> dla dowolnego polecenia, które je obsługuje. Wyraźne flagi użytkownika nie były obsługiwane dla wszystkich poleceń aż do Androida 9.

  • Dostęp do ścieżek /sdcard użytkowników dodatkowych jest zabroniony, począwszy od systemu Android 9. Zobacz dostawcę treści dla danych wielu użytkowników, aby uzyskać szczegółowe informacje na temat odzyskiwania plików podczas testowania.

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

Ponieważ adb działa jako użytkownik systemu, a dane są piaskownicą w systemie Android 9 i nowszych wersjach, musisz korzystać z dostawców treści, aby przesyłać lub pobierać dowolne 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 przy użyciu kompilacji userdebug lub usereng .

  • Używasz ITestDevice Federacji Handlowej (Tradefed) do przesyłania/wyciągania plików, w takim przypadku użyj /sdcard/ paths w konfiguracji testowej (na przykład zobacz kod źródłowy pushFile w NativeDevice.java ).

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

Rozwiązanie dla twórców aplikacji

Interakcja z plikami testowymi przy użyciu adb content i instancji ContentProvider zamiast polecenia push lub pull .

  1. Utwórz instancję ContentProvider hostowaną przez aplikację, która może udostępniać/przechowywać pliki w razie potrzeby. Użyj pamięci wewnętrznej aplikacji.
  2. Użyj poleceń read lub write adb shell content , aby wypychać/wyciągać pliki.

Rozwiązanie dla plików multimedialnych

Aby wypchnąć pliki multimedialne na partycję multimedialną 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 zapisuje pliki w specyficznej dla użytkownika ścieżce /sdcard .

Zbuduj plik TradefedContentProvider.apk ze źródła, używając 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
```

Wsparcie dla wielu użytkowników Federacji Handlowej

Tradefed to oficjalna uprząż testowa Androida. Ta sekcja podsumowuje niektóre wbudowane wsparcie Tradefed dla scenariuszy testowych dla wielu użytkowników.

Kontrolerzy stanu

Programy sprawdzające status systemu (SSC) są uruchamiane przed docelowymi programami przygotowującymi, a ich czyszczenie jest uruchamiane po tych programach przygotowujących.

UserChecker jest zdefiniowany wyraźnie, aby pomóc programistom podczas testowania wielu użytkowników. Śledzi, czy test zmienił stan użytkowników na urządzeniu (na przykład utworzył użytkowników bez usuwania ich podczas demontażu). Ponadto, jeśli ustawione jest user-cleanup , automatycznie podejmie ono próbę oczyszczenia po teście, jednocześnie wyświetlając pomocne błędy, dzięki którym test będzie mógł zostać naprawiony.

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

Osoba przygotowująca cel

Przygotowujące cele są zwykle używane do konfigurowania urządzenia o określonej konfiguracji. W przypadku testów wieloużytkownikowych, narzędzia przygotowujące mogą służyć do tworzenia użytkowników określonego typu, a także przełączania się na innych użytkowników.

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

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

Jeśli żądany typ użytkownika już istnieje na urządzeniu, użyj SwitchUserTargetPreparer , aby przełączyć się na istniejącego użytkownika. Typowe wartości user-type obejmują 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 w ramach testu konieczna jest zmiana użytkowników. Nie przełączaj się z poziomu środowiska testowego po stronie urządzenia, takiego jak UI Automator , ponieważ proces testowy może zostać przerwany w dowolnym momencie. Zamiast tego użyj platformy testowej po stronie hosta, takiej jak platforma testowa sterowana hostem firmy Tradefed, która zapewnia dostęp do ITestDevice , umożliwiając dowolną manipulację użytkownikami.

Użyj UserChecker (opisanego w Sprawdzanie stanu ) w przypadku testów sterowanych przez hosta, które zmieniają stan użytkownika, ponieważ zapewnia to, że test poprawnie się po sobie oczyści.