Guia de testes do Android 6.0

O Android 6.0 oferece a oportunidade de garantir que seus apps funcionem com a próxima versão da plataforma. Essa versão inclui várias APIs e mudanças de comportamento que podem afetar seu app, conforme descrito em Visão geral da API e Mudanças de comportamento. Ao testar seu app com essa versão, há algumas mudanças específicas do sistema em que você precisa se concentrar para garantir que os usuários tenham uma boa experiência.

Este guia descreve quais recursos do Android 6.0 serão testados com seu app e como testá-los. Priorize o teste desses recursos específicos devido ao grande impacto potencial no comportamento do app:

Teste de permissões

O novo modelo de Permissões muda a maneira como as permissões são alocadas ao app pelo usuário. Em vez de conceder todas as permissões durante o procedimento de instalação, o app precisa pedir ao usuário permissões individuais no momento da execução. Para os usuários, esse comportamento oferece um controle mais granular sobre as atividades de cada app, além de um melhor contexto para entender por que o app está solicitando uma permissão específica. Os usuários podem conceder ou revogar as permissões concedidas a um app individualmente a qualquer momento. É provável que esse recurso da versão tenha um impacto no comportamento do app e possa impedir o funcionamento de alguns dos recursos do app, ou eles podem funcionar em um estado degradado.

Essa mudança afeta todos os apps em execução na nova plataforma, mesmo aqueles que não são destinados à versão nova da plataforma. A plataforma oferece um comportamento de compatibilidade limitado para apps legados, mas você precisa começar a planejar a migração do seu app para o novo modelo de permissões agora, com o objetivo de publicar uma versão atualizada do app no lançamento oficial da plataforma.

Dicas de teste

Use as dicas de teste a seguir para ajudar a planejar e executar testes do app com o novo comportamento de permissões.

  • Identifique as permissões atuais do aplicativo e os caminhos de código relacionados.
  • Teste o fluxo de usuários entre serviços e dados protegidos por permissão.
  • Teste várias combinações de permissões negadas/concedidas.
  • Use a ferramenta adb para gerenciar permissões na linha de comando:
    • Listar permissões e status por grupo:
      adb shell pm list permissions -d -g
    • Conceda ou revogue uma ou mais permissões usando a seguinte sintaxe:
      adb shell pm [grant|revoke] <permission.name> ...
  • Analise o aplicativo para descobrir os serviços que usam permissões.

Estratégia de teste

A mudança de permissões afeta a estrutura e o design do app, além da experiência do usuário e dos fluxos fornecidos a eles. Avalie o uso atual das permissões do seu app e comece a planejar os novos fluxos que você quer oferecer. O lançamento oficial da plataforma oferece um comportamento de compatibilidade, mas é importante planejar a atualização do app e não confiar nesses comportamentos.

Identifique as permissões que seu app realmente precisa e usa e, em seguida, encontre os vários caminhos de código que usam os serviços protegidos por permissões. É possível fazer isso por meio de uma combinação de testes na nova plataforma e análise de código. Nos testes, você precisa se concentrar em ativar as permissões de execução mudando a targetSdkVersion do app para o nível 23 da API.

Teste com várias combinações de permissões revogadas e adicionadas para destacar os fluxos de usuário que dependem de permissões. Quando uma dependência não for óbvia ou lógica, considere refatorar ou compartimentalizar esse fluxo para eliminar a dependência ou deixar claro por que a permissão é necessária.

Para saber mais sobre o comportamento das permissões de execução, testes e práticas recomendadas, consulte o desenvolvedor Como trabalhar com permissões do sistema.

Teste de soneca e App em espera

Os recursos de economia de energia dos modos Soneca e App em espera limitam a quantidade de processamento em segundo plano que o app pode realizar quando um dispositivo está em estado inativo ou enquanto não está em foco. As restrições que o sistema pode impor aos apps incluem acesso limitado ou nenhum acesso à rede, tarefas em segundo plano suspensas, notificações suspensas, solicitações de ativação ignoradas e alarmes. Para garantir que seu app se comporte corretamente com essas otimizações de economia de energia, é necessário testá-lo simulando esses estados de baixa energia.

Testar o app com o Soneca

Para testar a Soneca com o aplicativo:

  1. Configure um dispositivo de hardware ou dispositivo virtual com uma imagem do sistema Android 7.0 (API de nível 24).
  2. Conecte o dispositivo à máquina de desenvolvimento e instale o aplicativo.
  3. Execute o aplicativo e deixe-o ativo.
  4. Simule o dispositivo entrando no modo Soneca executando os seguintes comandos:
    $ adb shell dumpsys battery unplug
    $ adb shell dumpsys deviceidle step
    $ adb shell dumpsys deviceidle -h
    
  5. Observe o comportamento do aplicativo quando o dispositivo for reativado. Certifique-se de que ele se recupera normalmente quando o dispositivo sai do modo Soneca.

Testar aplicativos com App em espera

Para testar o modo App em espera:

  1. Configure um dispositivo de hardware ou dispositivo virtual com uma imagem do sistema Android 7.0 (API de nível 24).
  2. Conecte o dispositivo à máquina de desenvolvimento e instale o aplicativo.
  3. Execute o aplicativo e deixe-o ativo.
  4. Simule o app entrando no modo de espera executando os seguintes comandos:
    $ adb shell am broadcast -a android.os.action.DISCHARGING
    $ adb shell am set-idle <packageName> true
    
  5. Simule o despertar do app usando o seguinte comando:
    $ adb shell am set-idle <packageName> false
  6. Observe o comportamento do aplicativo quando ele for despertado. Certifique-se de que ele se recupera normalmente do modo de espera. É importante verificar se as notificações e os jobs em segundo plano do app continuam funcionando conforme o esperado.

Backup automático para aplicativos e identificadores específicos do dispositivo

Se o app estiver mantendo algum identificador específico do dispositivo, como o ID de registro do Google Cloud Messaging, no armazenamento interno, siga as práticas recomendadas para excluir o local de armazenamento do backup automático, conforme descrito em Fazer backup dos dados do usuário com o Backup automático.