テストの要件

GTS テスト（GtsSafetyCenterTestCases）

GTS テストでは、構成ファイルに対する制約が適用されます。構成ファイルをアップデートするを参照してください。 デバイスは、セーフティ センターをサポートしていない場合、これらのテストから除外されます。

制約の内容は次のとおりです。

  • 未変更またはデフォルトの状態のままになっているセーフティ センターのソースグループが少なくとも 7 つ存在している必要があります。ソースタイトル、初期ディスプレイ状態、サマリーなどの特定のフィールドによっては、オーバーレイ可能な文字列で指定されるため、変更することができます。

  • GoogleAppSecuritySources の場合:

    • GooglePlayProtect 安全性ソースを削除または変更しないでください。
    • GoogleAppProtectionService 安全性ソースを削除または変更できます。 存在する場合:
      • ロギングをサポートする必要があります。
      • Android 13 では、パッケージ名が変更されない場合、initialDisplayState="hidden" が必要です。Android 14 では、issue-only-safety-source になっている必要があります。deduplicationGroup は未変更のままにしなければなりません。
      • パッケージ名が変更される場合は、ロール "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" を保持する必要があります。また、Android 14 では、deduplicationGroup は不要となります。

  • AndroidLockScreenSources の場合:

    • グループの summary インスタンスは必須ですが、文字列のオーバーレイがある場合も含めて変更可能です。
    • 1 つ以上の安全性ソースが必要です。
    • 最初の安全性ソースは、ロック画面設定を制御するソースになることが前提で、SEVERITY_LEVEL_RECOMMENDATION よりも重大度の高い問題やエントリ（maxSeverityLevel="300" か黄色のエントリまたは警告カードまでの範囲）をプッシュできるものではありません。Android 14 では、deduplicationGroup は未変更のままにする必要があります。
    • その他の安全性ソースは、生体認証のロック解除機構用のソースであり、maxSeverityLevel="0" コードが必要です。

  • Android 13 では、GoogleAccountSources、GoogleDeviceFinderSources、または AndroidAdvancedSources を変更しないでください。Android 14 では、これらのグループに導入された新しいソースの一部を削除できます（バックアップと復元など）。また、新しい静的ソースを AndroidAdvancedSources グループにアペンドすることも可能です。

  • GoogleUpdateSources の場合:

    • intentAction を GoogleSecurityUpdates に対して変更できます。文字列のオーバーレイも含めて変更可能です。
    • GooglePlaySystemUpdate は変更しないでください。

  • AndroidPrivacySources の場合:

    • issue-only である限りは、一部のソースの追加、削除または変更を行うことができます。
    • packageName="com.google.android.permissioncontroller" を維持する必要があります。
    • その他の AndroidPrivacySources ソースは変更しないでください。

  • その他の安全性ソースグループの場合（存在する場合）:

    • グループには summary または statelessIconType があってはなりません。これらは SAFETY_SOURCES_GROUP_TYPE_RIGID グループ（Android 14 では SAFETY_SOURCES_GROUP_TYPE_STATELESS）となるものです。
    • それぞれのグループ内の各ソースは、静的であるか maxSeverityLevel="0" が存在している必要があります。たとえば、グレーまたは緑色のエントリ（問題がない）を送信できるようにする必要があります。

CTS テスト（CtsSafetyCenterTestCases）

Android 13 以降では、CTS テストは、PermissionController をサポートするすべての OEM に適用されます。

構成ファイルテスト（XmlConfigTest）

これらのテストでは以下のことを確認します。

  • 解析された XML 構成ファイルが、セーフティ センターによって解析および公開された構成ファイルに一致していて、しかもこの解析が正しく行われている。
  • インテントのアクション android.settings.PRIVACY_ADVANCED_SETTINGS が XML ファイル内に存在している場合は、このアクションを解決する必要がある。
  • インテントのアクション android.settings.PRIVACY_CONTROLS が XML ファイル内に存在している場合は、このアクションを解決する必要がある。

UI テスト（SafetyCenterActivityTest）

これらのテストでは以下のことを確認します。

  • インテントのアクション android.intent.action.SAFETY_CENTER を解決し、セーフティ センターが有効な場合は、[セキュリティとプライバシー] 設定画面を開き、セーフティ センターが無効な場合は、[設定] 画面を開く。

API テスト（SafetyCenterManagerTest）

SafetyCenterManagerTest API テストの目標は、セーフティ センター API が意図どおりに確実に動作できるようにすることです。

これらのテストでは、以下のことを確認します。

  • SafetyCenterManager.isSafetyCenterEnabled が関連付けられた DeviceConfig フラグによって制御されている。
  • 無効になっている場合、セーフティ センター API は no-op となる。
  • セーフティ センター API は、関連の許可が保持されているときにだけ使用可能になる。
  • データは、基礎となる構成に従っている場合にのみセーフティ センターに提供できる。
  • データがセーフティ センターに提供されると、それに従って正しく表示される。
  • 更新または再スキャンの動作、データの設定またはクリア、エラーの報告などの用途で、セーフティ センターのソース API を使用するで説明されている仕様に API が一致している。
  • UI に公開されている内部 API が正しく動作する。たとえば、データがセーフティ センターによって適切に統合される、データを更新できるなど。

セーフティ センターのサポート対象外テスト（SafetyCenterUnsupportedTest）

このテストでは、デバイスがセーフティ センターをサポートしておらず、サポートがフレームワーク XML 構成ファイルで無効になっているときに、セーフティ センターが無効になることを確認します。

デバイスがセーフティ センターをサポートしている場合、このテストは実行されません。デバイスがセーフティ センターをサポートしていない場合は、このテストとデータクラス テストのみが実行されます。

このテストでは以下のことを確認します。

  • android.intent.action.SAFETY_CENTER のインテント アクションによって [設定] 画面が開く。
  • SafetyCenterManager.isSafetyCenterEnabled が false を返す。
  • 呼び出されたときにほとんどのセーフティ センター API が応答しない。

データクラス テスト（SafetySourceDataTest、SafetySourceIssueTest など）

SafetySourceDataTest や SafetySourceIssueTest などのデータクラス テストでは、セーフティ センターによって公開されたデータクラスが意図どおりに動作することを確認します。たとえば、SafetySourceData、SafetySourceIssue および他の関連の内部クラスなどが対象となります。

MTS テスト（SafetyCenterFunctionalTestCases など）

これらのテストはそれぞれのメインライン アップデートで実行され、PermissionController をサポートするすべての OEM に適用されます。これらのテストによって適用される要件は、それぞれのメインライン アップデートで変更される場合があります。

API テスト（SafetyCenterManagerTest）

これらのテストは、CTS テスト SafetyCenterManagerTest に似ていますが、テストの対象になるのは、それぞれのメインライン アップデートで変更される可能性がある要件です。たとえば、以下のように実行されます。

  • UI に公開された内部 API によって返されるデータの実際のコンテンツをチェックする。

UI テスト（SafetyCenterActivityTest、SafetyCenterStatusCardTest、SafetyCenterQsActivityTest など）

これらのテストでは以下のことを確認します。

  • 特定のパラメータを持つセーフティ センターへのリダイレクトが、意図どおりに動作する。たとえば、特定の問題へのリダイレクトなど。セーフティ センターにリダイレクトするを参照してください。
  • UI に基礎となる安全性状態が正しく表示される。
  • UI で個別の画面に移動できる。
  • SafetySourceIssue によって指定されているときに、UI で、セーフティ センターの画面から安全性の問題を直接解決できる。
  • UI で、1 つのアイテムでの複数の警告カードを閉じて、これを再度複数の警告カードへと展開できる。
  • 関連性のあるセーフティ センター ソースに対してセーフティ センター ページが開かれると、データが更新される。
  • 再スキャンボタンが、特定の状況下のみで表示される。
  • 再スキャンボタンをタップすると、新しいデータが取得される。

  • セーフティ センターに対して同様のテストが実施される。アプリ用のカスタム クイック設定タイルを作成するを参照してください。

  • エラー状態や保留状態などのその他のエッジケース。

マルチユーザー テスト（SafetyCenterMultiUsersTest）

これらのテストの目標は、複数のユーザーまたはプロファイル向けにデータが提供されたときに、API が適切に動作できるようにすることです。複数のユーザーとプロファイル向けにデータを提供するを参照してください。このセットアップを行うには、Bedstead を使用するデバイス上の個別のユーザーとプロファイルの設定を促進する内部ライブラリを使用します。

このテストでは以下のことを確認します。

  • ユーザーに属するデータが、関連の管理対象プロファイル（存在する場合）と結合される。
  • profile="all_profiles" とマークされたソースのみが、ユーザーの管理対象プロファイルにデータを提供できる。
  • ユーザーに関連付けられた管理対象プロファイルごとに新しいエントリが作成される。
  • 一人のユーザーに属するデータが、別の関連のないユーザーに漏洩することがない。