Exigences concernant les tests

Tests GTS (GtsSafetyCenterTestCases)

Les tests GTS imposent des contraintes au fichier de configuration. Consultez la section Mettre à jour le fichier de configuration. Un appareil est exempté de ces tests s'il n'est pas compatible avec le Centre de sécurité.

Les contraintes sont les suivantes :

  • Il doit y avoir au moins sept groupes de 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 basés sur 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. Si elle est présente :
      • Il doit être compatible avec la journalisation.
      • Si le nom du package n'est pas modifié, il doit comporter initialDisplayState="hidden" dans Android 13. Dans Android 14, il doit s'agir d'un 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"; également dans Android 14 ne doit pas disposer deduplicationGroup

  • Pour AndroidLockScreenSources :

    • L'instance summary du groupe est obligatoire et vous pouvez la modifier, y compris avec une superposition de chaîne.
    • 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. Elle ne doit pas pouvoir transmettre des problèmes ou des entrées plus graves que SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" ou jusqu'à des fiches jaunes ou des fiches d'avertissement). Dans Android 14, le deduplicationGroup doit rester inchangé.
    • Les autres sources de sécurité sont destinées à être liées à la biométrie des mécanismes de déverrouillage, et ils doivent comporter maxSeverityLevel="0".

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

  • Pour GoogleUpdateSources :

    • Vous pouvez remplacer intentAction par 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 soient issue-only.
    • Il doit conserver packageName="com.google.android.permissioncontroller".
    • Ne modifiez pas le reste des sources AndroidPrivacySources.

  • Pour les autres groupes de sources de sécurité (le cas échéant):

    • Les groupes ne doivent pas avoir de summary ni de statelessIconType, ce qui entraîne la création d'un groupe SAFETY_SOURCES_GROUP_TYPE_RIGID (SAFETY_SOURCES_GROUP_TYPE_STATELESS sous Android 14).
    • Chaque source de chaque groupe doit être statique ou autorisée à envoyer des entrées grises ou vertes, mais sans problème (par exemple, maxSeverityLevel="0").

Tests CTS (CtsSafetyCenterTestCases)

À partir d'Android 13, les tests CTS s'appliquent à tous les OEM compatibles avec PermissionController.

Tests de fichiers de configuration (XmlConfigTest)

Ces tests garantissent que:

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

Tests de l'interface utilisateur (SafetyCenterActivityTest)

Ces tests garantissent que:

  • L'action d'intent android.intent.action.SAFETY_CENTER se résout et ouvre l'écran de paramètres Sécurité et 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 d'API (SafetyCenterManagerTest)

L'objectif des tests de l'API SafetyCenterManagerTest est de s'assurer que le niveau de sécurité les API Center fonctionnent comme prévu.

Ces tests permettent de vérifier les points suivants :

  • SafetyCenterManager.isSafetyCenterEnabled est contrôlé par l'entité associée DeviceConfig.
  • Lorsque cette option est désactivée, les API du centre de sécurité sont no-op.
  • Les API Safety Center ne sont utilisables que lorsque les autorisations associées sont détenues.
  • Les données ne peuvent être fournies au Centre de sécurité que conformément à la configuration sous-jacente.
  • Lorsque des données sont fournies au Centre de sécurité, elles s'affichent en conséquence.
  • Les API correspondent aux spécifications décrites dans Utiliser les API sources du Centre de sécurité, par exemple, le comportement d'actualisation ou de nouvelle analyse, la définition ou la suppression de données et le signalement d'erreurs.
  • Les API internes exposées à l'UI fonctionnent correctement. Par exemple, les données sont fusionnées de manière appropriée par Safety Center et peuvent être actualisées.

Test non compatible avec le centre de sécurité (SafetyCenterUnsupportedTest)

Ce test permet de s'assurer que le centre de sécurité est désactivé lorsque l'appareil n'est pas compatible lorsque la prise en charge est désactivée dans le fichier de configuration XML du framework.

Si l'appareil est compatible avec le Centre de sécurité, ce test n'est pas effectué. Si l'appareil n'est pas compatible avec le Centre de sécurité. Seul ce test et les tests des classes de données le permettent exécuter.

Ce test permet de vérifier les éléments suivants:

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

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

Tests de classe de données tels que SafetySourceDataTest et SafetySourceIssueTest s'assurer que les classes de données exposées par le centre de sécurité fonctionnent comme prévu (par exemple, SafetySourceData, SafetySourceIssue et d'autres requêtes internes associées) classes.

Tests MTS (SafetyCenterFunctionalTestCases et d'autres)

Ces tests sont exécutés sur les mises à jour principales et s'appliquent à tous les OEM compatibles PermissionController Les exigences appliquées par ces tests peuvent changer d'une mise à jour principale à l'autre.

Tests d'API (SafetyCenterManagerTest)

Ces tests sont semblables au test CTS SafetyCenterManagerTest, mais ils Exigences de test susceptibles de changer lors des mises à jour principales, par exemple:

  • Vérification du contenu réel des données renvoyées par les API internes exposées à l'UI

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

Ces tests permettent de vérifier les points suivants :

  • La redirection vers le Centre de sécurité avec des paramètres spécifiques fonctionne comme prévu. exemple, rediriger vers un problème spécifique. Consultez Redirection vers le centre de sécurité.
  • L'UI affiche l'état de sécurité sous-jacent correct.
  • L'UI permet d'accéder à des écrans distincts.
  • L'UI permet de résoudre les problèmes de sécurité directement depuis l'écran du centre de sécurité lorsque SafetySourceIssue est spécifié.
  • L'UI réduit plusieurs fiches d'avertissement en un seul élément et permet de développer dans plusieurs fiches d'avertissement.
  • Les données sont actualisées lorsque la page du centre de sécurité est ouverte pour le Sources du Centre de sécurité.
  • Le bouton de nouvelle analyse ne s'affiche que dans des circonstances spécifiques.
  • Le fait d'appuyer sur le bouton de nouvelle recherche permet de récupérer de nouvelles données.

  • Des tests similaires sont effectués pour le Centre de sécurité. Voir la section Créer des Mosaïques de paramètres pour votre l'appli

  • Autres cas limites, tels que les états d'erreur et les états en attente.

Tests multi-utilisateurs (SafetyCenterMultiUsersTest)

L'objectif de ces tests est de s'assurer que l'API fonctionne correctement lorsque des données sont fournies pour plusieurs utilisateurs ou profils. Voir la section Fournir des données pour plusieurs utilisateurs et profils. Ce est effectuée à l'aide d'une bibliothèque interne qui facilite des utilisateurs et des profils distincts sur l'appareil à l'aide de Bedstead.

Ce test permet de vérifier les éléments suivants:

  • Les données appartenant à un utilisateur sont fusionnées avec les données profil 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 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 sans rapport.