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
adeduplicationGroup
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
.
- Nie usuwaj ani nie modyfikuj źródła bezpieczeństwa
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 14deduplicationGroup
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"
.
- Wymagana jest instancja
W Androidzie 13 nie modyfikuj
GoogleAccountSources
,GoogleDeviceFinderSources
aniAndroidAdvancedSources
. 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 grupyAndroidAdvancedSources
.W przypadku
GoogleUpdateSources
:- Możesz zmienić
intentAction
dlaGoogleSecurityUpdates
i zmodyfikować ją za pomocą nakładki ciągu. - Nie modyfikuj
GooglePlaySystemUpdate
.
- Możesz zmienić
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
.
- Możesz dodawać, usuwać lub modyfikować niektóre źródła, o ile są one
Dla pozostałych grup źródeł bezpieczeństwa (jeśli istnieją):
- Grupy nie powinny mieć
summary
anistatelessIconType
, 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.
- Grupy nie powinny mieć
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.