Wymagania testowe

Testy GTS ( GtsSafetyCenterTestCases )

Testy GTS nakładają ograniczenia na plik konfiguracyjny. Zobacz Aktualizacja pliku konfiguracyjnego . Urządzenie jest zwolnione z tych testów, jeśli nie obsługuje Centrum bezpieczeństwa.

Ograniczenia są następujące:

  • Powinno istnieć co najmniej siedem grup źródłowych Centrum bezpieczeństwa, które powinny pozostać w stanie niezmodyfikowanym lub domyślnym. Niektóre określone pola, takie jak tytuły źródeł, początkowy stan wyświetlania i podsumowanie, są czasami wspierane przez nakładane ciągi znaków i można je modyfikować.
  • W przypadku GoogleAppSecuritySources :

    • Nie usuwaj ani nie modyfikuj źródła bezpieczeństwa GooglePlayProtect .
    • Możesz usunąć lub zmienić źródło bezpieczeństwa GoogleAppProtectionService . Jeśli jest obecny:
      • Musi obsługiwać logowanie.
      • Jeśli nazwa pakietu pozostaje niezmieniona, w systemie Android 13 musi mieć initialDisplayState="hidden" ; w systemie Android 14 musi to być issue-only-safety-source a deduplicationGroup musi pozostać niezmieniona.
      • Jeśli nazwa pakietu zostanie zmieniona, musi on posiadać rolę "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" ; dodatkowo w Androidzie 14 nie może mieć deduplicationGroup .
  • Dla AndroidLockScreenSources :

    • Wymagana jest instancja summary grupy, którą można modyfikować, w tym za pomocą nakładki tekstowej.
    • Musi istnieć co najmniej jedno źródło bezpieczeństwa.
    • Pierwsze źródło bezpieczeństwa ma być źródłem kontrolującym ustawienia ekranu blokady i nie powinno być w stanie przesyłać problemów ani wpisów poważniejszych niż SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" lub do żółtych wpisów lub kart ostrzegawczych). W systemie Android 14 deduplicationGroup musi pozostać niezmieniona.
    • Pozostałe źródła bezpieczeństwa mają być źródłami związanymi z mechanizmami odblokowywania biometrycznego i powinny mieć maxSeverityLevel="0" .
  • W Androidzie 13 nie modyfikuj GoogleAccountSources , GoogleDeviceFinderSources ani AndroidAdvancedSources . W Androidzie 14 możesz usunąć część nowych źródeł, które zostały wprowadzone w tych grupach (np. tworzenie kopii zapasowych i przywracanie), możesz także dołączać nowe źródła statyczne do grupy AndroidAdvancedSources .

  • W przypadku GoogleUpdateSources :

    • Możesz zmienić intentAction dla GoogleSecurityUpdates i zmodyfikować ją za pomocą nakładki ciągu.
    • Nie modyfikuj GooglePlaySystemUpdate .
  • Dla AndroidPrivacySources :

    • Możesz dodawać, usuwać lub modyfikować niektóre źródła, o ile są one issue-only .
    • Muszą zachować packageName="com.google.android.permissioncontroller" .
    • Nie modyfikuj pozostałych źródeł AndroidPrivacySources .
  • Dla pozostałych grup źródeł bezpieczeństwa (jeśli istnieją):

    • Grupy nie powinny mieć summary ani statelessIconType , co skutkuje grupą SAFETY_SOURCES_GROUP_TYPE_RIGID ( SAFETY_SOURCES_GROUP_TYPE_STATELESS w systemie Android 14).
    • Każde źródło w każdej grupie powinno być statyczne lub mieć na przykład maxSeverityLevel="0" zezwolenie na wysyłanie szarych lub zielonych wpisów, ale bez problemów.

Testy CTS ( CtsSafetyCenterTestCases )

Począwszy od Androida 13, testy CTS dotyczą wszystkich producentów OEM obsługujących PermissionController .

Testy plików konfiguracyjnych ( XmlConfigTest )

Testy te zapewniają:

  • Przeanalizowany plik konfiguracyjny XML jest zgodny z konfiguracją przeanalizowaną i udostępnioną przez Centrum bezpieczeństwa oraz czy ta analiza zakończyła się pomyślnie.
  • Jeśli zamierzona akcja android.settings.PRIVACY_ADVANCED_SETTINGS jest obecna w pliku XML, wówczas ta akcja musi zostać rozpatrzona.
  • Jeśli w pliku XML znajduje się zamierzona akcja android.settings.PRIVACY_CONTROLS , wówczas ta akcja musi zostać rozpatrzona.

Testy interfejsu użytkownika ( SafetyCenterActivityTest )

Testy te zapewniają:

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

Testy API ( SafetyCenterManagerTest )

Celem testów API SafetyCenterManagerTest jest upewnienie się, że interfejsy API Centrum bezpieczeństwa działają zgodnie z przeznaczeniem.

Testy te zapewniają, co następuje:

  • SafetyCenterManager.isSafetyCenterEnabled jest kontrolowany przez powiązaną flagę DeviceConfig .
  • Po wyłączeniu interfejsy API Centrum bezpieczeństwa nie działają.
  • Interfejsów API Centrum bezpieczeństwa można używać tylko wtedy, gdy posiadane są powiązane uprawnienia.
  • Dane mogą być przekazywane do Centrum bezpieczeństwa wyłącznie zgodnie z podstawową konfiguracją.
  • Gdy dane są dostarczane do Centrum bezpieczeństwa, są one odpowiednio wyświetlane.
  • Interfejsy API odpowiadają specyfikacjom opisanym w artykule Korzystanie ze źródłowych interfejsów API Centrum bezpieczeństwa , na przykład pod względem odświeżania lub ponownego skanowania, ustawiania lub czyszczenia danych oraz raportowania błędów.
  • Wewnętrzne interfejsy API udostępniane interfejsowi użytkownika działają poprawnie, na przykład dane są odpowiednio scalane przez Centrum bezpieczeństwa i można je odświeżyć.

Nieobsługiwany test Centrum bezpieczeństwa ( SafetyCenterUnsupportedTest )

Ten test zapewnia, że ​​Centrum bezpieczeństwa jest wyłączone, jeśli urządzenie go nie obsługuje, gdy obsługa jest wyłączona w pliku konfiguracyjnym XML platformy.

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

Ten test zapewnia, co następuje:

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

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 przeznaczeniem, na przykład SafetySourceData , SafetySourceIssue i inne powiązane klasy wewnętrzne.

Testy MTS ( SafetyCenterFunctionalTestCases i inne)

Testy te są przeprowadzane w głównych aktualizacjach i mają zastosowanie do wszystkich producentów OEM obsługujących PermissionController . Wymagania narzucone przez te testy mogą się zmieniać w zależności od głównych aktualizacji.

Testy API ( SafetyCenterManagerTest )

Testy te są podobne do testu CTS SafetyCenterManagerTest , jednak testują wymagania, które mogą się zmieniać w przypadku głównych aktualizacji, na przykład:

  • Sprawdzanie rzeczywistej zawartości danych zwracanych przez wewnętrzne API eksponowane na interfejsie użytkownika

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

Testy te zapewniają:

  • Przekierowanie do Centrum bezpieczeństwa z określonymi parametrami działa zgodnie z przeznaczeniem, np. przekierowanie do konkretnego problemu. Zobacz Przekierowanie do Centrum bezpieczeństwa .
  • Interfejs użytkownika wyświetla prawidłowy podstawowy stan bezpieczeństwa.
  • Interfejs użytkownika umożliwia nawigację do oddzielnych ekranów.
  • Interfejs użytkownika umożliwia rozwiązywanie problemów związanych z bezpieczeństwem bezpośrednio z ekranu Centrum bezpieczeństwa, jeśli zostało to określone przez SafetySourceIssue .
  • Interfejs użytkownika zwija wiele kart ostrzeżeń w jeden element i umożliwia ponowne rozwinięcie go w wiele kart ostrzeżeń.
  • Dane są odświeżane po otwarciu strony Centrum bezpieczeństwa dla odpowiednich źródeł Centrum bezpieczeństwa.
  • Przycisk ponownego skanowania pojawia się tylko w określonych okolicznościach.
  • Dotknięcie przycisku ponownego skanowania powoduje pobranie nowych danych.
  • Podobne testy przeprowadzane są dla Centrum Bezpieczeństwa. Zobacz Tworzenie niestandardowych kafelków Szybkich ustawień dla swojej aplikacji

  • Dodatkowe przypadki brzegowe, takie jak stany błędów i stany oczekujące.

Testy wielu użytkowników ( SafetyCenterMultiUsersTest )

Celem tych testów jest zapewnienie prawidłowego działania interfejsu API w przypadku udostępniania danych dla wielu użytkowników lub profili. Zobacz Dostarczanie danych dla wielu użytkowników i profili . Tę konfigurację osiąga się za pomocą wewnętrznej biblioteki, która ułatwia konfigurowanie oddzielnych użytkowników i profili na urządzeniu za pomocą Bedstead.

Ten test zapewnia, co następuje:

  • Dane należące do użytkownika są łączone z powiązanym z nim profilem zarządzanym, jeśli istnieje.
  • Tylko źródła oznaczone parametrem profile="all_profiles" mogą dostarczać dane w zarządzanym profilu użytkownika.
  • Dla każdego zarządzanego profilu powiązanego z użytkownikiem tworzony jest nowy wpis.
  • Dane należące do jednego użytkownika nie wyciekają do innego, niepowiązanego użytkownika.