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 są następujące:

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

  • Dla usługi GoogleAppSecuritySources:

    • Nie usuwaj ani nie modyfikuj źródła bezpieczeństwa GooglePlayProtect.
    • Źródło bezpieczeństwa GoogleAppProtectionService możesz usunąć lub zmienić. Jeśli jest dostępny:
      • Musi obsługiwać logowanie.
      • 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.
      • Jeśli nazwa pakietu zostanie zmieniona, musi mieć rolę "android.app.role.SYSTEM_APP_PROTECTION_SERVICE". Dodatkowo w Androidzie 14 nie może ona zawierać elementu deduplicationGroup.

  • AndroidLockScreenSources:

    • Wymagane jest wystąpienie grupy summary, które możesz modyfikować, w tym za pomocą nakładki ciągu.
    • Musi być co najmniej 1 źródło bezpieczeństwa.
    • Pierwsze źródło bezpieczeństwa to źródło, które kontroluje ustawienia ekranu blokady. Nie powinno ono mieć możliwości przesyłania problemów ani wpisów o większym priorytecie niż SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" lub karty z żółtymi wpisami lub karty ostrzegawcze). Na Androidzie 14, deduplicationGroup musi pozostać bez zmian.
    • Inne źródła bezpieczeństwa powinny być źródłami informacji biometrycznych mechanizmu odblokowywania i powinny mieć maxSeverityLevel="0".

  • W Androidzie 13 nie modyfikuj elementów GoogleAccountSources, GoogleDeviceFinderSources ani AndroidAdvancedSources. Na Androidzie 14, możesz usunąć niektóre nowe źródła, wprowadzonych w tych grupach (np. tworzenie i przywracanie kopii zapasowych), możesz też dołączyć nowe źródła statyczne do grupy AndroidAdvancedSources.

  • Dla usługi GoogleUpdateSources:

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

  • Dla usługi AndroidPrivacySources:

    • Niektóre źródła możesz dodawać, usuwać i modyfikować, o ile są one dostępne w Twoim kraju.issue-only
    • Musi zachować packageName="com.google.android.permissioncontroller".
    • Nie zmieniaj pozostałych źródeł AndroidPrivacySources.

  • Dla pozostałych grup źródeł bezpieczeństwa (jeśli występują):

    • Grupy nie powinny mieć parametru summary ani statelessIconType, co spowoduje grupa SAFETY_SOURCES_GROUP_TYPE_RIGID (SAFETY_SOURCES_GROUP_TYPE_STATELESS na Androida 14)
    • Każde źródło w każdej grupie powinno być statyczne lub mieć Na przykład atrybut maxSeverityLevel="0" może wysyłać kolor szary lub zielony wpisy, ale nie ma 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)

Testy te zapewniają:

  • Zanalizowany plik konfiguracji XML pasuje do przeanalizowanej konfiguracji i zostały ujawnione przez Centrum bezpieczeństwa i że ta analiza zakończyła się powodzeniem.
  • Jeśli występuje działanie intencji android.settings.PRIVACY_ADVANCED_SETTINGS w pliku XML, to działanie musi zostać rozwiązane.
  • Jeśli w pliku XML znajduje się działanie oparte na intencjach android.settings.PRIVACY_CONTROLS, musi ono zostać rozwiązane.

Testy interfejsu użytkownika (SafetyCenterActivityTest)

Te testy zapewniają:

  • Akcja intencji android.intent.action.SAFETY_CENTER jest rozwiązywana 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ą:

  • SafetyCenterManager.isSafetyCenterEnabled jest sterowane przez powiązaną DeviceConfig.
  • Gdy ta opcja jest wyłączona, interfejsy API Centrum bezpieczeństwa są niedostępne.
  • 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ą.
  • Po przekazaniu danych 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ć.

Nieobsługiwany test 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 się nie uruchomi. Jeśli urządzenie nie obsługuje Centrum bezpieczeństwa, tylko ten test i testy klas danych zostaną uruchomione.

Ten test daje pewność, że:

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

Testy klas danych (SafetySourceDataTest, SafetySourceIssueTest itp.)

Testy klas danych, takie jak SafetySourceDataTest i SafetySourceIssueTest, zapewniają, że klasy danych udostępniane przez Centrum bezpieczeństwa działają zgodnie z oczekiwaniami, np. SafetySourceData, SafetySourceIssue i inne powiązane wewnętrzne klasy.

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 egzekwowane w ramach tych testów mogą się zmienić w ramach aktualizacji głównych.

Testy interfejsu API (SafetyCenterManagerTest)

Te testy są podobne do testu CTS SafetyCenterManagerTest, ale wymagania testowe, które mogą się zmienić w przypadku aktualizacji mainline, na przykład:

  • Sprawdzanie rzeczywistej zawartości danych zwracanych przez wewnętrzne interfejsy API widoczna dla interfejsu użytkownika

testy interfejsu (SafetyCenterActivityTest, SafetyCenterStatusCardTest, SafetyCenterQsActivityTest itp.);

Testy te zapewniają:

  • Przekierowanie do Centrum bezpieczeństwa z określonymi parametrami jest zgodne z oczekiwaniami – na przykład przekierowując do konkretnego problemu. Patrz sekcja Przekierowanie do sekcji dotyczącej bezpieczeństwa pomocy.
  • Interfejs wyświetla prawidłowy stan bezpieczeństwa.
  • Interfejs użytkownika umożliwia przechodzenie do osobnych ekranów.
  • Interfejs umożliwia rozwiązywanie problemów z bezpieczeństwem bezpośrednio na ekranie Centrum bezpieczeństwa, jeśli jest to określone 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ą prowadzone w 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 wielu użytkowników (SafetyCenterMultiUsersTest)

Celem tych testów jest zapewnienie prawidłowego działania interfejsu API, gdy dane jest podany dla wielu użytkowników lub profili. Zapoznaj się z artykułem Przygotowanie danych 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 daje pewność, że:

  • Dane należące do użytkownika są scalone z danymi zarządzanymi profilu, jeśli 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 niepowiązanemu użytkownikowi.