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 é isento desses testes se não for compatível com o Centro de segurança.

As restrições são as seguintes:

  • Deve haver pelo menos sete grupos de origem do Safety Center, que precisam permanecer no estado padrão ou não modificado. 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.
    • É possível remover ou mudar a fonte de segurança 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 e 15, ele precisa ser um issue-only-safety-source e o deduplicationGroup precisa permanecer inalterado. No Android 16, ele precisa ser um dynamic-safety-source, ter initialDisplayState="hidden" e o deduplicationGroup precisa permanecer inalterado.
      • 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 string.
    • É preciso ter pelo menos uma fonte de segurança.
    • A primeira origem de segurança é destinada a ser a origem que controla as configurações da tela de bloqueio e não pode enviar problemas ou entradas mais graves que SEVERITY_LEVEL_RECOMMENDATION (maxSeverityLevel="300" ou até a entrada amarela ou cartões de aviso). 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 fontes AndroidPrivacySources.

  • Para os demais grupos de origem 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, para enviar entradas cinza ou verde, 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:

  • 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 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 só podem ser fornecidos ao Safety Center 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 do Safety Center, por exemplo, comportamento de atualização ou reexibição, configuração ou exclusão de dados e relatório 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 oferece suporte a ele quando o suporte é 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 ao Safety Center, apenas este teste e os testes de classes de dados serão 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 expostas à 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 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 de nova verificação busca 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 de 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 de um usuário não são vazados para outro usuário não relacionado.