Exigences d'essai

Tests GTS ( GtsSafetyCenterTestCases )

Les tests GTS imposent des contraintes sur le fichier de configuration. Voir Mettre à jour le fichier de configuration . Un appareil est exempté de ces tests s’il ne prend pas en charge Safety Center.

Les contraintes sont les suivantes :

  • Il doit y avoir au moins sept groupes sources Safety Center, qui doivent rester dans l'état non modifié ou par défaut. Certains champs spécifiques tels que les titres des sources, l'état d'affichage initial et le résumé sont parfois soutenus par des chaînes superposables et peuvent être modifiés.

  • Pour GoogleAppSecuritySources :

    • Ne supprimez pas et ne modifiez pas la source de sécurité GooglePlayProtect .
    • Vous pouvez supprimer ou modifier la source de sécurité GoogleAppProtectionService . S'il est présent :
      • Il doit prendre en charge la journalisation.
      • Si le nom du package est inchangé, il doit avoir initialDisplayState="hidden" dans Android 13 ; dans Android 14, il doit s’agir d’une issue-only-safety-source et le deduplicationGroup doit rester inchangé.
      • Si le nom du package est modifié, il doit détenir le rôle "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" ; de plus, sous Android 14, il ne doit pas avoir de deduplicationGroup .

  • Pour AndroidLockScreenSources :

    • L'instance summary du groupe est obligatoire et vous pouvez la modifier, y compris avec une superposition de chaînes.
    • Il doit y avoir au moins une source de sécurité.
    • La première source de sécurité est destinée à être la source qui contrôle les paramètres de l'écran de verrouillage et elle ne devrait pas être en mesure de pousser les problèmes ou les entrées plus graves que SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" ou jusqu'à des entrées ou des cartes d'avertissement jaunes). Sous Android 14, le deduplicationGroup doit rester inchangé.
    • Les autres sources de sécurité sont censées être des sources liées aux mécanismes de déverrouillage biométrique et doivent avoir maxSeverityLevel="0" .

  • Sous Android 13, ne modifiez pas GoogleAccountSources , GoogleDeviceFinderSources ou AndroidAdvancedSources . Dans Android 14, vous pouvez supprimer certaines des nouvelles sources introduites dans ces groupes (par exemple, sauvegarde et restauration), vous pouvez également ajouter de nouvelles sources statiques au groupe AndroidAdvancedSources .

  • Pour GoogleUpdateSources :

    • Vous pouvez changer intentAction pour GoogleSecurityUpdates et le modifier avec une superposition de chaîne.
    • Ne modifiez pas GooglePlaySystemUpdate .

  • Pour AndroidPrivacySources :

    • Vous pouvez ajouter, supprimer ou modifier certaines sources, à condition qu'elles issue-only .
    • Ils doivent conserver packageName="com.google.android.permissioncontroller" .
    • Ne modifiez pas le reste des sources AndroidPrivacySources .

  • Pour le reste des groupes de sources de sécurité (le cas échéant) :

    • Les groupes ne doivent pas avoir summary ou statelessIconType , ce qui donne lieu à un groupe SAFETY_SOURCES_GROUP_TYPE_RIGID ( SAFETY_SOURCES_GROUP_TYPE_STATELESS dans Android 14).
    • Chaque source au sein de chaque groupe doit être statique ou avoir maxSeverityLevel="0" , par exemple, autorisée à envoyer des entrées grises ou vertes mais aucun problème.

Tests CTS ( CtsSafetyCenterTestCases )

À partir d'Android 13, les tests CTS s'appliquent à tous les OEM prenant en charge PermissionController .

Tests du fichier de configuration ( XmlConfigTest )

Ces tests garantissent :

  • Le fichier de configuration XML analysé correspond à la configuration analysée et exposée par Safety Center et cette analyse a réussi.
  • Si l'action d'intention android.settings.PRIVACY_ADVANCED_SETTINGS est présente dans le fichier XML, cette action doit être résolue.
  • Si l'action d'intention android.settings.PRIVACY_CONTROLS est présente dans le fichier XML, cette action doit être résolue.

Tests d'interface utilisateur ( SafetyCenterActivityTest )

Ces tests garantissent :

  • L'action d'intention android.intent.action.SAFETY_CENTER résout et ouvre l'écran des paramètres de sécurité et de confidentialité lorsque le centre de sécurité est activé, et l'écran des paramètres lorsque le centre de sécurité est désactivé.

Tests API ( SafetyCenterManagerTest )

L'objectif des tests de l'API SafetyCenterManagerTest est de garantir que les API Safety Center fonctionnent comme prévu.

Ces tests garantissent ce qui suit :

  • SafetyCenterManager.isSafetyCenterEnabled est contrôlé par l'indicateur DeviceConfig associé.
  • Lorsqu'elles sont désactivées, les API Safety Center ne fonctionnent pas.
  • Les API Safety Center sont utilisables uniquement lorsque les autorisations associées sont détenues.
  • Les données peuvent être fournies à Safety Center uniquement conformément à la configuration sous-jacente.
  • Lorsque les données sont fournies à Safety Center, elles apparaissent en conséquence.
  • Les API correspondent aux spécifications décrites dans Utiliser les API sources de Safety Center , par exemple, le comportement d'actualisation ou de nouvelle analyse, la définition ou la suppression des données et le signalement des erreurs.
  • Les API internes exposées à l'interface utilisateur fonctionnent correctement. Par exemple, les données sont fusionnées de manière appropriée par Safety Center et les données peuvent être actualisées.

Test non pris en charge par Safety Center ( SafetyCenterUnsupportedTest )

Ce test garantit que Safety Center est désactivé lorsque l'appareil ne le prend pas en charge lorsque la prise en charge est désactivée dans le fichier de configuration XML du framework.

Si l'appareil prend en charge Safety Center, ce test ne s'exécute pas. Si l'appareil ne prend pas en charge Safety Center, seuls ce test et les tests de classes de données sont exécutés.

Ce test garantit les éléments suivants :

  • L'action d'intention android.intent.action.SAFETY_CENTER ouvre l'écran Paramètres.
  • SafetyCenterManager.isSafetyCenterEnabled renvoie false .
  • La plupart des API Safety Center ne répondent pas lorsqu'elles sont appelées.

Tests de classes de données ( SafetySourceDataTest , SafetySourceIssueTest , etc.)

Les tests de classe de données tels que SafetySourceDataTest et SafetySourceIssueTest garantissent que les classes de données exposées par Safety Center fonctionnent comme prévu, par exemple SafetySourceData , SafetySourceIssue et d'autres classes internes associées.

Tests MTS ( SafetyCenterFunctionalTestCases et autres)

Ces tests sont exécutés sur les mises à jour principales et s'appliquent à tous les OEM prenant en charge PermissionController . Les exigences imposées par ces tests peuvent changer au fil des mises à jour principales.

Tests API ( SafetyCenterManagerTest )

Ces tests sont similaires au test CTS SafetyCenterManagerTest , mais ils testent des exigences qui peuvent changer au fil des mises à jour principales, par exemple :

  • Vérifier le contenu réel des données renvoyées par les API internes exposées à l'interface utilisateur

Tests d'interface utilisateur ( SafetyCenterActivityTest , SafetyCenterStatusCardTest , SafetyCenterQsActivityTest , etc.)

Ces tests garantissent :

  • La redirection vers Safety Center avec des paramètres spécifiques fonctionne comme prévu, par exemple, la redirection vers un problème spécifique. Voir Redirection vers le centre de sécurité .
  • L'interface utilisateur affiche l'état de sécurité sous-jacent correct.
  • L'interface utilisateur permet de naviguer vers des écrans séparés.
  • L'interface utilisateur permet de résoudre les problèmes de sécurité directement à partir de l'écran Safety Center lorsque cela est spécifié par SafetySourceIssue .
  • L'interface utilisateur regroupe plusieurs cartes d'avertissement en un seul élément et permet de l'étendre en plusieurs cartes d'avertissement.
  • Les données sont actualisées lorsque la page Safety Center est ouverte pour les sources Safety Center pertinentes.
  • Le bouton de nouvelle analyse n'apparaît que dans des circonstances spécifiques.
  • En appuyant sur le bouton de nouvelle analyse, vous récupérez de nouvelles données.

  • Des tests similaires sont menés pour le Centre de Sécurité. Voir Créer des vignettes de paramètres rapides personnalisées pour votre application

  • Cas extrêmes supplémentaires tels que les états d’erreur et les états en attente.

Tests multi-utilisateurs ( SafetyCenterMultiUsersTest )

L'objectif de ces tests est de garantir que l'API fonctionne correctement lorsque les données sont fournies pour plusieurs utilisateurs ou profils. Voir Fournir des données pour plusieurs utilisateurs et profils . Cette configuration est réalisée à l'aide d'une bibliothèque interne qui facilite la configuration d'utilisateurs et de profils distincts sur l'appareil à l'aide de Bedstead.

Ce test garantit les éléments suivants :

  • Les données appartenant à un utilisateur sont fusionnées avec son profil géré associé s'il existe.
  • Seules les sources marquées avec profile="all_profiles" peuvent fournir des données dans le profil géré de l'utilisateur.
  • Une nouvelle entrée est créée pour chaque profil géré associé à un utilisateur.
  • Les données appartenant à un utilisateur ne sont pas divulguées à un autre utilisateur non lié.