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 está isento desses testes se não for compatível com o Safety Center.

As restrições são as seguintes:

  • Deve haver pelo menos sete grupos de origem do Safety Center, que devem permanecer no estado inalterado ou padrão. 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 alterar a fonte de segurança GoogleAppProtectionService . Se estiver presente:
      • Deve suportar o registro em log.
      • Se o nome do pacote não for alterado, ele deverá ter initialDisplayState="hidden" no Android 13; no Android 14, ela deve ser uma issue-only-safety-source e o deduplicationGroup deve permanecer inalterado.
      • Se o nome do pacote for alterado, ele deverá manter a função "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" ; além disso, no Android 14, ele não deve ter um deduplicationGroup .

  • Para AndroidLockScreenSources :

    • A instância summary do grupo é necessária e você pode modificá-la, inclusive com uma sobreposição de string.
    • Deve haver pelo menos uma fonte de segurança.
    • A primeira fonte de segurança pretende ser a fonte que controla as configurações da tela de bloqueio e não deve ser capaz de enviar problemas ou entradas mais graves do que SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" ou até entradas amarelas ou cartões de aviso). No Android 14, o deduplicationGroup deve permanecer inalterado.
    • As demais fontes de segurança pretendem 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, você pode remover algumas das novas fontes que foram introduzidas nesses grupos (por exemplo, backup e restauração), você também pode anexar novas fontes estáticas ao grupo AndroidAdvancedSources .

  • Para GoogleUpdateSources :

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

  • Para AndroidPrivacySources :

    • Você pode adicionar, remover ou modificar algumas fontes, desde que sejam issue-only .
    • Eles devem manter packageName="com.google.android.permissioncontroller" .
    • Não modifique o restante das fontes AndroidPrivacySources .

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

    • Os grupos não devem ter summary ou statelessIconType , o que resulta em um grupo SAFETY_SOURCES_GROUP_TYPE_RIGID ( SAFETY_SOURCES_GROUP_TYPE_STATELESS no Android 14).
    • Cada fonte dentro de cada grupo deve ser estática ou ter maxSeverityLevel="0" , por exemplo, com permissão para enviar entradas cinza ou verdes, mas sem problemas.

Testes CTS ( CtsSafetyCenterTestCases )

A partir do Android 13, os testes CTS se aplicam a todos os OEMs compatíveis com PermissionController .

Testes de arquivo de configuração ( XmlConfigTest )

Esses testes garantem:

  • O arquivo de configuração XML analisado corresponde à configuração analisada e exposta pelo Safety Center e que esta análise foi bem-sucedida.
  • Se a ação de intenção android.settings.PRIVACY_ADVANCED_SETTINGS estiver presente no arquivo XML, essa ação deverá ser resolvida.
  • Se a ação de intenção android.settings.PRIVACY_CONTROLS estiver presente no arquivo XML, essa ação deverá ser resolvida.

Testes de IU ( SafetyCenterActivityTest )

Esses testes garantem:

  • A ação de intenção 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á habilitada e a tela Configurações quando a Central de segurança está desabilitada.

Testes de API ( SafetyCenterManagerTest )

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

Esses testes garantem o seguinte:

  • SafetyCenterManager.isSafetyCenterEnabled é controlado pelo sinalizador DeviceConfig associado.
  • Quando desativado, as APIs do Safety Center ficam inoperantes.
  • As APIs do Safety Center só podem ser usadas quando as permissões associadas são mantidas.
  • Os dados podem ser fornecidos ao Safety Center somente de acordo com a configuração subjacente.
  • Quando os dados são fornecidos ao Safety Center, eles aparecem de acordo.
  • As APIs correspondem às especificações descritas em Usar as APIs de origem do Safety Center , por exemplo, atualizar ou verificar novamente o comportamento, configurar ou limpar dados e relatar erros.
  • As APIs internas expostas à UI estão funcionando corretamente, por exemplo, os dados são mesclados adequadamente pelo Safety Center e os dados podem ser atualizados.

Teste sem suporte do Safety Center ( SafetyCenterUnsupportedTest )

Este teste garante que o Safety Center seja desabilitado quando o dispositivo não for compatível com ele quando o suporte estiver desabilitado no arquivo de configuração XML da estrutura.

Se o dispositivo for compatível com o Safety Center, esse teste não será executado. Se o dispositivo não suportar o Safety Center, apenas este teste e os testes de classes de dados serão executados.

Este teste garante o seguinte:

  • A ação de intenção 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 chamadas.

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

Testes de classe 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 que oferecem suporte PermissionController . Os requisitos impostos por esses testes podem mudar nas atualizações principais.

Testes de API ( SafetyCenterManagerTest )

Esses testes são semelhantes ao teste CTS SafetyCenterManagerTest , porém testam requisitos que podem mudar nas atualizações da linha principal, por exemplo:

  • Verificando o conteúdo real dos dados retornados pelas APIs internas expostas à IU

Testes de IU ( SafetyCenterActivityTest , SafetyCenterStatusCardTest , SafetyCenterQsActivityTest , etc)

Esses testes garantem:

  • Redirecionar para o Safety Center com parâmetros específicos funciona conforme o esperado, por exemplo, redirecionando para um problema específico. Consulte Redirecionar para a Central de Segurança .
  • A IU exibe o estado de segurança subjacente correto.
  • A UI permite navegar para telas separadas.
  • A UI permite resolver problemas de segurança diretamente na tela do Safety Center quando especificado por SafetySourceIssue .
  • A IU recolhe vários cartões de aviso em um item e permite expandi-los novamente em vários cartões de aviso.
  • Os dados são atualizados quando a página Safety Center é aberta para as fontes relevantes do Safety Center.
  • O botão de nova verificação aparece apenas em circunstâncias específicas.
  • Tocar no botão de nova varredura busca novos dados.

  • Testes semelhantes são realizados para o Centro de Segurança. Consulte Criar blocos personalizados de configurações rápidas para seu aplicativo

  • Casos extremos adicionais, como estados de erro e estados pendentes.

Testes multiusuários ( SafetyCenterMultiUsersTest )

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

Este teste garante o seguinte:

  • Os dados pertencentes a um usuário são mesclados com seu perfil gerenciado associado, se existir.
  • Somente 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 pertencentes a um usuário não vazam para outro usuário não relacionado.