Requisitos de teste

Testes GTS (GtsSafetyCenterTestCases)

Os testes GTS impõem restrições ao arquivo de configuração. Consulte Atualizar o arquivo de configuração. Um dispositivo é dispensado desses testes se não for compatível com o Centro de segurança.

As restrições são as seguintes:

  • É necessário haver pelo menos sete grupos de origem da Central de segurança, que precisam permanecer no estado padrão ou sem modificações. Alguns campos específicos, como títulos de fontes, estado de exibição inicial e resumo, às vezes são apoiados por strings sobrepostas e podem ser modificados.

  • Para GoogleAppSecuritySources:

    • Não remova nem modifique a fonte de segurança GooglePlayProtect.
    • Você pode remover ou mudar a fonte de segurança do GoogleAppProtectionService. Se estiver presente:
      • Ele precisa oferecer suporte à geração de registros.
      • Se o nome do pacote não for alterado, ele precisará ter initialDisplayState="hidden" no Android 13. No Android 14, ele precisará ser um issue-only-safety-source, e o deduplicationGroup não poderá ser alterado.
      • Se o nome do pacote for alterado, ele precisará ter o papel "android.app.role.SYSTEM_APP_PROTECTION_SERVICE". Além disso, no Android 14, ele não pode ter um deduplicationGroup.

  • Para AndroidLockScreenSources:

    • A instância summary do grupo é obrigatória e pode ser modificada, inclusive com uma sobreposição de strings.
    • É preciso ter pelo menos uma fonte de segurança.
    • A primeira fonte de segurança precisa ser aquela que controla as configurações da tela de bloqueio e não pode enviar problemas ou entradas mais graves do que SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" ou até cartões amarelos de entrada ou de alerta). No Android 14, o deduplicationGroup precisa permanecer inalterado.
    • As outras fontes de segurança devem ser fontes relacionadas a mecanismos de desbloqueio biométrico e devem ter maxSeverityLevel="0".

  • No Android 13, não modifique GoogleAccountSources, GoogleDeviceFinderSources ou AndroidAdvancedSources. No Android 14, é possível remover algumas das novas fontes que foram introduzidas nesses grupos (por exemplo, backup e restauração). Também é possível anexar novas fontes estáticas ao grupo AndroidAdvancedSources.

  • Para GoogleUpdateSources:

    • Você pode mudar intentAction para GoogleSecurityUpdates e modificá-lo com uma sobreposição de string.
    • Não modifique GooglePlaySystemUpdate.

  • Para AndroidPrivacySources:

    • É possível adicionar, remover ou modificar algumas fontes, desde que elas sejam issue-only.
    • Eles precisam manter packageName="com.google.android.permissioncontroller".
    • Não modifique o restante das origens AndroidPrivacySources.

  • Para o restante dos grupos de fontes de segurança (se houver):

    • Os grupos não podem ter summary ou statelessIconType, o que resulta em um grupo SAFETY_SOURCES_GROUP_TYPE_RIGID (SAFETY_SOURCES_GROUP_TYPE_STATELESS no Android 14).
    • Cada origem em cada grupo precisa ser estática ou ter maxSeverityLevel="0", por exemplo, que pode enviar entradas cinzas ou verdes, mas sem problemas.

Testes CTS (CtsSafetyCenterTestCases)

A partir do Android 13, os testes do CTS são aplicados a todos os OEMs que oferecem suporte a PermissionController.

Testes de arquivos de configuração (XmlConfigTest)

Esses testes garantem:

  • O arquivo de configuração XML analisado corresponde à configuração analisada e exposta pelo Safety Center, e essa análise foi concluída.
  • Se a ação de intent android.settings.PRIVACY_ADVANCED_SETTINGS estiver presente no arquivo XML, ela precisará ser resolvida.
  • Se a ação de intent android.settings.PRIVACY_CONTROLS estiver presente no arquivo XML, ela precisará ser resolvida.

Testes de interface (SafetyCenterActivityTest)

Esses testes garantem que:

  • A ação de intent android.intent.action.SAFETY_CENTER resolve e abre a tela de configurações de Segurança e privacidade quando a Central de segurança está ativada e a tela de configurações quando ela está desativada.

Testes de API (SafetyCenterManagerTest)

O objetivo dos testes da API SafetyCenterManagerTest é garantir que as APIs do Safety Center estejam funcionando conforme o esperado.

Esses testes garantem o seguinte:

  • O SafetyCenterManager.isSafetyCenterEnabled é controlado pela flag DeviceConfig associada.
  • Quando desativado, as APIs do Safety Center não são executadas.
  • As APIs do Safety Center só podem ser usadas quando as permissões associadas são retidas.
  • Os dados podem ser fornecidos à Central de segurança apenas de acordo com a configuração subjacente.
  • Quando os dados são fornecidos ao Safety Center, eles são exibidos de acordo.
  • As APIs correspondem às especificações descritas em Usar as APIs de origem da Central de segurança. Por exemplo, comportamento de atualização ou nova verificação, configuração ou limpeza de dados e relatórios de erros.
  • As APIs internas expostas à interface funcionam corretamente. Por exemplo, os dados são mesclados adequadamente pelo Safety Center e podem ser atualizados.

Teste sem suporte da Central de segurança (SafetyCenterUnsupportedTest)

Esse teste garante que o Safety Center seja desativado quando o dispositivo não tiver suporte ou quando o suporte for desativado no arquivo de configuração XML do framework.

Se o dispositivo for compatível com o Safety Center, esse teste não será executado. Se o dispositivo não oferecer suporte à Central de segurança, apenas esse teste e os testes de classes de dados vão ser executados.

Esse teste garante o seguinte:

  • A ação de intent android.intent.action.SAFETY_CENTER abre a tela "Configurações".
  • SafetyCenterManager.isSafetyCenterEnabled retorna false.
  • A maioria das APIs do Safety Center não responde quando chamada.

Testes de classes de dados (SafetySourceDataTest, SafetySourceIssueTest etc.)

Os testes de classes de dados, como SafetySourceDataTest e SafetySourceIssueTest, garantem que as classes de dados expostas pelo Safety Center estejam funcionando conforme o esperado, por exemplo, SafetySourceData, SafetySourceIssue e outras classes internas relacionadas.

Testes MTS (SafetyCenterFunctionalTestCases e outros)

Esses testes são executados nas atualizações principais e se aplicam a todos os OEMs com suporte para PermissionController. Os requisitos aplicados por esses testes podem mudar nas atualizações principais.

Testes de API (SafetyCenterManagerTest)

Esses testes são semelhantes ao teste CTS SafetyCenterManagerTest, mas testam requisitos que podem mudar nas atualizações principais, por exemplo:

  • Verificar o conteúdo real dos dados retornados pelas APIs internas expostos à interface

Testes de interface (SafetyCenterActivityTest, SafetyCenterStatusCardTest, SafetyCenterQsActivityTest etc.)

Esses testes garantem:

  • O redirecionamento para a Central de segurança com parâmetros específicos funciona como esperado, por exemplo, redirecionando para um problema específico. Consulte a página Redirecionar para a Central de segurança.
  • A interface mostra o estado de segurança correto.
  • A interface permite navegar para telas separadas.
  • A interface permite resolver problemas de segurança diretamente na tela da Central de segurança quando especificado por SafetySourceIssue.
  • A interface compacta vários cards de aviso em um item e permite que eles sejam expandidos de volta para vários cards de aviso.
  • Os dados são atualizados quando a página da Central de segurança é aberta para as fontes relevantes.
  • O botão de nova verificação aparece apenas em circunstâncias específicas.
  • Tocar no botão "Nova verificação" recupera novos dados.

  • Testes semelhantes são realizados para a Central de segurança. Consulte Criar blocos personalizados de Configurações rápidas para seu app.

  • Outros casos extremos, como estados de erro e pendentes.

Testes com vários usuários (SafetyCenterMultiUsersTest)

O objetivo desses testes é garantir que a API funcione adequadamente quando os dados são fornecidos para vários usuários ou perfis. Consulte Fornecer dados para vários usuários e perfis. Essa configuração é alcançada usando uma biblioteca interna que facilita a configuração de usuários e perfis separados no dispositivo usando o Bedstead.

Esse teste garante o seguinte:

  • Os dados de um usuário são mesclados com o perfil gerenciado associado, se ele existir.
  • Somente as fontes marcadas com profile="all_profiles" podem fornecer dados no perfil gerenciado do usuário.
  • Uma nova entrada é criada para cada perfil gerenciado associado a um usuário.
  • Os dados que pertencem a um usuário não vazam para outro usuário não relacionado.