Wymagania dotyczące testów

Testy GTS (GtsSafetyCenterTestCases)

Testy GTS narzucają ograniczenia na plik konfiguracji. Zobacz Zaktualizuj plik konfiguracji. Urządzenie jest zwolnione z tych testów, jeśli nie obsługuje Centrum bezpieczeństwa.

Ograniczenia te przedstawiają się następująco:

  • Powinna istnieć co najmniej 7 grup źródeł Centrum bezpieczeństwa, które powinny pozostać w stanie niezmodyfikowanym lub domyślnym. Niektóre pola, takie jak tytuły źródeł, początkowy stan wyświetlania i podsumowanie, są czasami obsługiwane przez nakładane ciągi tekstowe i można je modyfikować.

  • GoogleAppSecuritySources:

    • Nie usuwaj ani nie modyfikuj źródła bezpieczeństwa GooglePlayProtect.
    • Możesz usunąć lub zmienić GoogleAppProtectionService źródło zabezpieczeń. Jeśli jest dostępny:
      • Musi obsługiwać rejestrowanie.
      • Jeśli nazwa pakietu nie ulegnie zmianie, w Androidzie 13 musi zawierać initialDisplayState="hidden". W Androidzie 14 musi to być issue-only-safety-source, a wartość deduplicationGroup musi pozostać niezmieniona.
      • W przypadku zmiany nazwy pakietu musi on pełnić rolę "android.app.role.SYSTEM_APP_PROTECTION_SERVICE". Dodatkowo w Androidzie 14 pakiet nie może mieć roli deduplicationGroup.

  • AndroidLockScreenSources:

    • Instancja summary grupy jest wymagana. Możesz ją zmodyfikować, w tym z użyciem nakładki ciągu znaków.
    • Musi być co najmniej 1 źródło bezpieczeństwa.
    • Pierwsze źródło zabezpieczeń ma być źródłem, które kontroluje ustawienia ekranu blokady i nie powinno być w stanie przekazywać problemów lub wpisów o większym znaczeniu niż SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" lub żółte karty z ostrzeżeniem). W Androidzie 14 wartość deduplicationGroup musi pozostać niezmieniona.
    • Pozostałe źródła bezpieczeństwa powinny być źródłami informacji związanych z mechanizmami odblokowywania biometrycznego i powinny mieć parametr maxSeverityLevel="0".

  • W Androidzie 13 nie modyfikuj elementów GoogleAccountSources, GoogleDeviceFinderSources ani AndroidAdvancedSources. W Androidzie 14 możesz usunąć niektóre nowe źródła, które zostały wprowadzone w tych grupach (np. tworzenie i przywracanie kopii zapasowych), a także dołączać nowe źródła statyczne do grupy AndroidAdvancedSources.

  • GoogleUpdateSources:

    • Możesz zastąpić intentAction wartością GoogleSecurityUpdates i zmodyfikować ją za pomocą nakładki tekstu.
    • Nie zmieniaj wartości GooglePlaySystemUpdate.

  • Do witryn AndroidPrivacySources:

    • Możesz dodawać, usuwać lub modyfikować niektóre źródła, o ile mają status issue-only.
    • Musi zachować packageName="com.google.android.permissioncontroller".
    • Nie zmieniaj pozostałych źródeł AndroidPrivacySources.

  • W przypadku pozostałych grup źródeł zabezpieczeń (jeśli takie istnieją):

    • Grupy nie mogą zawierać summary ani statelessIconType, ponieważ spowoduje to utworzenie grupy SAFETY_SOURCES_GROUP_TYPE_RIGID (SAFETY_SOURCES_GROUP_TYPE_STATELESS w Androidzie 14).
    • Każde źródło w każdej grupie powinno być statyczne lub mieć atrybut maxSeverityLevel="0", np. może wysyłać szare lub zielone znaki, ale nie może powodować problemów.

Testy CTS (CtsSafetyCenterTestCases)

Od Androida 13 testy CTS są stosowane do wszystkich OEM-ów, które obsługują PermissionController.

Testy pliku konfiguracji (XmlConfigTest)

Te testy zapewniają:

  • Zanalizowany plik konfiguracji XML jest zgodny z konfiguracją przeanalizowaną i ujawnioną przez Centrum bezpieczeństwa, co oznacza, że analiza się powiodła.
  • Jeśli w pliku XML występuje działanie oparte na intencjach android.settings.PRIVACY_ADVANCED_SETTINGS, musi ono zostać wykonane.
  • Jeśli w pliku XML występuje działanie oparte na intencjach android.settings.PRIVACY_CONTROLS, musi ono zostać rozwiązane.

Testy interfejsu użytkownika (SafetyCenterActivityTest)

Testy te zapewniają:

  • Działanie intencji android.intent.action.SAFETY_CENTER rozwiązuje i otwiera ekran ustawień Bezpieczeństwo i prywatność, gdy Centrum bezpieczeństwa jest włączone, oraz ekran Ustawienia, gdy Centrum bezpieczeństwa jest wyłączone.

Testy interfejsu API (SafetyCenterManagerTest)

Celem testów interfejsu API SafetyCenterManagerTest jest sprawdzenie, czy interfejsy API SafetyCenter działają zgodnie z oczekiwaniami.

Te testy zapewniają:

  • Do kontroli SafetyCenterManager.isSafetyCenterEnabled steruje powiązana flaga DeviceConfig.
  • Gdy są wyłączone, interfejsy API Centrum bezpieczeństwa nie działają.
  • Interfejsy API Centrum Bezpieczeństwa są dostępne tylko wtedy, gdy powiązane z nimi uprawnienia są zablokowane.
  • Dane mogą być przekazywane do Centrum bezpieczeństwa tylko zgodnie z podstawową konfiguracją.
  • Gdy dane są przekazywane do Centrum bezpieczeństwa, są one odpowiednio wyświetlane.
  • Interfejsy API odpowiadają specyfikacji opisanej w artykule Korzystanie z interfejsów API źródła Centrum bezpieczeństwa, np. zachowanie odświeżania lub ponownego skanowania, ustawianie lub usuwanie danych oraz zgłaszanie błędów.
  • Wewnętrzne interfejsy API udostępnione interfejsowi użytkownika działają prawidłowo, np. dane są odpowiednio scalane przez Centrum bezpieczeństwa i można je odświeżać.

Test nieobsługiwany przez Centrum bezpieczeństwa (SafetyCenterUnsupportedTest)

Ten test zapewnia, że Centrum bezpieczeństwa jest wyłączone, gdy urządzenie go nie obsługuje, gdy obsługa jest wyłączona w pliku konfiguracji XML frameworku.

Jeśli urządzenie obsługuje Centrum bezpieczeństwa, ten test nie jest wykonywany. Jeśli urządzenie nie obsługuje Centrum bezpieczeństwa, uruchamiany jest tylko ten test oraz testy klas danych.

Ten test zapewnia:

  • Działanie o intencji android.intent.action.SAFETY_CENTER otwiera ekran Ustawienia.
  • SafetyCenterManager.isSafetyCenterEnabled zwraca false.
  • Większość interfejsów API Centrum bezpieczeństwa nie odpowiada na wywołania.

testy klas danych (SafetySourceDataTest, SafetySourceIssueTest itp.);

Dzięki testom klas danych, np. SafetySourceDataTest i SafetySourceIssueTest, można sprawdzić, czy klasy danych udostępniane przez Centrum bezpieczeństwa działają zgodnie z oczekiwaniami, np. SafetySourceData, SafetySourceIssue i inne powiązane klasy wewnętrzne.

Testy MTS (SafetyCenterFunctionalTestCases i inne)

Te testy są przeprowadzane w ramach aktualizacji głównych i dotyczą wszystkich OEM-ów, które obsługują PermissionController. Wymagania stosowane przez te testy mogą się zmieniać w ramach aktualizacji głównych.

Testy interfejsu API (SafetyCenterManagerTest)

Te testy są podobne do testu CTS SafetyCenterManagerTest, ale sprawdzają wymagania, które mogą się zmieniać w ramach aktualizacji głównej, na przykład:

  • sprawdzanie rzeczywistej zawartości danych zwróconych przez wewnętrzne interfejsy API udostępnione w interfejsie użytkownika;

testy interfejsu użytkownika (SafetyCenterActivityTest, SafetyCenterStatusCardTest, SafetyCenterQsActivityTest itp.);

Te testy zapewniają:

  • Przekierowanie do Centrum bezpieczeństwa z określonymi parametrami działa zgodnie z oczekiwaniami, np. przekierowanie do konkretnego problemu. Zobacz Przekierowanie do Centrum bezpieczeństwa.
  • Interfejs wyświetla prawidłowy stan bezpieczeństwa.
  • Interfejs umożliwia przechodzenie do poszczególnych ekranów.
  • Interfejs umożliwia rozwiązywanie problemów z bezpieczeństwem bezpośrednio na ekranie Centrum bezpieczeństwa, gdy określisz je przez SafetySourceIssue.
  • Interfejs składa wiele kart z ostrzeżeniem w jeden element i umożliwia rozwinięcie tego elementu z powrotem na wiele kart z ostrzeżeniem.
  • Dane są odświeżane, gdy otwierasz stronę Centrum bezpieczeństwa dla odpowiednich źródeł Centrum bezpieczeństwa.
  • Przycisk ponownego skanowania pojawia się tylko w określonych okolicznościach.
  • Kliknięcie przycisku ponownego skanowania powoduje pobranie nowych danych.

  • Podobne testy są przeprowadzane w przypadku Centrum Bezpieczeństwa. Zobacz Tworzenie niestandardowych kafelków Szybkich ustawień w aplikacji.

  • Dodatkowe przypadki skrajne, takie jak stany błędu i stany oczekujące.

Testy z udziałem wielu użytkowników (SafetyCenterMultiUsersTest)

Celem tych testów jest sprawdzenie, czy interfejs API działa prawidłowo, gdy dane są dostarczane dla wielu użytkowników lub profili. Przeczytaj artykuł Przesyłanie danych dla wielu użytkowników i profili. Ta konfiguracja jest osiągana dzięki wewnętrznej bibliotece, która ułatwia konfigurowanie oddzielnych użytkowników i profili na urządzeniu za pomocą Bedstead.

Ten test zapewnia:

  • Dane należące do użytkownika są łączone z powiązanym profilem zarządzanym, jeśli taki istnieje.
  • Tylko źródła oznaczone symbolem profile="all_profiles" mogą przesyłać dane na zarządzanym profilu użytkownika.
  • Dla każdego profilu zarządzanego powiązanego z użytkownikiem tworzony jest nowy wpis.
  • Dane należące do jednego użytkownika nie są udostępniane innemu, niezwiązanemu użytkownikowi.