Test requirements

GTS tests (GtsSafetyCenterTestCases)

GTS tests impose constraints on the configuration file. See Update the configuration file. A device is exempted from these tests if the device doesn't support Safety Center.

The constraints are as follows:

  • There should be at least seven Safety Center source groups, which should remain in the unmodified or default state. Some specific fields such as sources titles, initial display state, and summary are sometimes backed by overlayable strings and can be modified.

  • For GoogleAppSecuritySources:

    • Don't remove or modify the GooglePlayProtect safety source.
    • You can remove or change the GoogleAppProtectionService safety source. If it's present:
      • It must support logging.
      • If the package name is unchanged, it must have initialDisplayState="hidden" in Android 13; in Android 14, it must be an issue-only-safety-source instead and the deduplicationGroup must remain unchanged.
      • If the package name is changed, it must hold the role "android.app.role.SYSTEM_APP_PROTECTION_SERVICE"; additionally in Android 14 it must not have a deduplicationGroup.

  • For AndroidLockScreenSources:

    • The summary instance of the group is required and you can modify it, including with a string overlay.
    • There must be at least one safety source.
    • The first safety source is intended to be the source that controls lock screen settings and it shouldn't be able to push issues or entries more severe than SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" or up to yellow entry or warning cards). In Android 14, the deduplicationGroup must remain unchanged.
    • The other safety sources are intended to be sources related to biometric unlock mechanisms and they should have maxSeverityLevel="0".

  • In Android 13, don't modify GoogleAccountSources, GoogleDeviceFinderSources, or AndroidAdvancedSources. In Android 14, you can remove some of the new sources that were introduced in these groups (e.g. backup & restore), you can also append new static sources to the AndroidAdvancedSources group.

  • For GoogleUpdateSources:

    • You can change intentAction for GoogleSecurityUpdates and can modify it with a string overlay.
    • Don't modify GooglePlaySystemUpdate.

  • For AndroidPrivacySources:

    • You can add, remove, or modify some sources, as long as they're issue-only.
    • They must keep packageName="com.google.android.permissioncontroller".
    • Don't modify the remainder of the AndroidPrivacySources sources.

  • For the remainder of safety source groups (if any):

    • Groups shouldn't have summary or statelessIconType, which result in a SAFETY_SOURCES_GROUP_TYPE_RIGID group (SAFETY_SOURCES_GROUP_TYPE_STATELESS in Android 14).
    • Each source within each group should either be static or have maxSeverityLevel="0", for example, allowed to send gray or green entries but no issues.

CTS tests (CtsSafetyCenterTestCases)

Starting in Android 13, CTS tests apply to all OEMs that support PermissionController.

Configuration file tests (XmlConfigTest)

These tests ensure:

  • The parsed XML configuration file matches the configuration parsed and exposed by Safety Center and that this parsing is successful.
  • If the intent action android.settings.PRIVACY_ADVANCED_SETTINGS is present in the XML file, then this action must resolve.
  • If the intent action android.settings.PRIVACY_CONTROLS is present in the XML file, then this action must resolve.

UI tests (SafetyCenterActivityTest)

These tests ensure:

  • The android.intent.action.SAFETY_CENTER intent action resolves and opens the Security & privacy settings screen when Safety Center is enabled, and the Settings screen when Safety Center is disabled.

API tests (SafetyCenterManagerTest)

The goal of the SafetyCenterManagerTest API tests is to ensure that the Safety Center APIs are working as intended.

These tests ensures the following:

  • SafetyCenterManager.isSafetyCenterEnabled is controlled by the associated DeviceConfig flag.
  • When disabled, the Safety Center APIs no-op.
  • The Safety Center APIs are usable only when the associated permissions are held.
  • Data can be provided to Safety Center only in accordance with the underlying configuration.
  • When data is provided to Safety Center, it surfaces accordingly.
  • The APIs match the specs described in Use the Safety Center source APIs, for example, refresh or rescan behavior, setting or clearing data, and reporting errors.
  • The internal APIs exposed to the UI are working properly, for example, the data is appropriately merged by Safety Center and data can be refreshed.

Safety Center unsupported test (SafetyCenterUnsupportedTest)

This test ensures that Safety Center is disabled when the device doesn't support it when support is disabled in the framework XML configuration file.

If the device supports Safety Center, this test doesn't run. If the device doesn't support Safety Center, only this test and the data classes tests does run.

This test ensures the following:

  • The android.intent.action.SAFETY_CENTER intent action opens the Settings screen.
  • SafetyCenterManager.isSafetyCenterEnabled returns false.
  • Most Safety Center APIs don't respond when called.

Data classes tests (SafetySourceDataTest, SafetySourceIssueTest, etc)

Data class tests such as SafetySourceDataTest and SafetySourceIssueTest ensure that the data classes exposed by Safety Center are working as intended, for example, SafetySourceData, SafetySourceIssue, and other related internal classes.

MTS tests (SafetyCenterFunctionalTestCases and others)

These tests are run across mainline updates and apply to all OEMs that support PermissionController. The requirements enforced by these tests may change across mainline updates.

API tests (SafetyCenterManagerTest)

These tests are similar to the CTS test SafetyCenterManagerTest, however they test requirements that could change across mainline updates, for example:

  • Checking the actual content of the data returned by the internal APIs exposed to the UI

UI tests (SafetyCenterActivityTest, SafetyCenterStatusCardTest, SafetyCenterQsActivityTest, etc)

These tests ensure:

  • Redirecting to Safety Center with specific parameters works as intended, for example, redirecting to a specific issue. See Redirect to Safety Center.
  • The UI displays the correct underlying safety state.
  • The UI allows navigating to separate screens.
  • The UI allows resolving safety issues directly from the Safety Center screen when specified by SafetySourceIssue.
  • The UI collapses multiple warning cards in one item and allows expanding this back into multiple warning cards.
  • The data is refreshed when the Safety Center page is opened for the relevant Safety Center sources.
  • The rescan button appears only under specific circumstances.
  • Tapping the rescan button fetches new data.

  • Similar tests are conducted for the Safety Center. See Create custom Quick Settings tiles for your app

  • Additional edge cases such as error states and pending states.

Multi users tests (SafetyCenterMultiUsersTest)

The goal of these tests is to ensure that the API works appropriately when data is provided for multiple users or profiles. See Provide data for multiple users and profiles. This setup is achieved by using an internal library that facilitates setting up separate users and profiles on the device using Bedstead.

This test ensures the following:

  • Data belonging to a user is merged together with its associated managed profile if it exists.
  • Only sources that are marked with profile="all_profiles" can provide data in the user's managed profile.
  • A new entry is created for each managed profile associated with a user.
  • Data belonging to one user doesn't leak onto another unrelated user.