Atender ao requisito de nível desejado da API do Google Play

Quando você faz upload de um APK, ele precisa atender aos requisitos de nível desejado da API para apps do Google Play.

Confira os requisitos em vigor partir de 31 de agosto de 2024:

  • Os novos apps e as atualizações precisarão ser direcionados ao Android 14 (nível 34 da API) ou mais recente para serem enviados ao Google Play. Os apps para Wear OS e Android TV são uma exceção e precisam ser direcionados ao Android 13 (nível 33 da API) ou mais recente.
  • Os apps atuais precisam ser direcionados ao Android 13 (nível 33 da API) ou versões mais recentes para continuarem disponíveis aos novos usuários em dispositivos com uma versão do SO Android mais recente que o nível desejado da API dos apps. Os apps destinados ao Android 12 (nível 31 da API) ou versões anteriores (Android 10 (nível 29 da API) ou versões anteriores para Wear OS e Android 11 (nível 30 da API) ou versões anteriores para Android TV) só vão estar disponíveis em dispositivos com uma versão do SO Android anterior ou igual ao nível desejado da API dos apps.

Se precisar de mais tempo para atualizar o app, você poderá pedir uma prorrogação até 1º de novembro de 2024. Será possível acessar os formulários de extensão do app no Play Console ainda este ano.

Confira abaixo as exceções aos requisitos:

  • Apps permanentemente particulares que são restritos a usuários em uma organização e destinados somente à distribuição interna.
  • Apps direcionados ao Android Automotive OS ou empacotados com APKs que segmentam essa versão.

Por que preferir os SDKs mais recentes?

Cada nova versão do Android apresenta mudanças que trazem melhorias de segurança e desempenho e aprimoram a experiência do usuário no Android. Algumas dessas mudanças se aplicam apenas a apps que declaram o suporte explicitamente pelo atributo de manifesto targetSdkVersion, também conhecido como o nível desejado da API.

Configurar o app para segmentar um nível de API recente garante que os usuários se beneficiem dessas melhorias. Ao mesmo tempo, o app ainda poderá ser executado em versões mais antigas do Android. Segmentar um nível de API recente também permite que o app aproveite os mais novos recursos da plataforma para conquistar seus usuários. Além disso, a partir do Android 10 (nível 29 da API), os usuários recebem um aviso ao iniciar um app pela primeira vez se ele for destinado ao Android 5.1 (nível 22 da API) ou versões anteriores.

Este documento destaca pontos importantes que você precisa saber ao atualizar o nível desejado da API para atender ao requisito do Google Play. Consulte as instruções nas seções a seguir, dependendo da versão para a qual você está migrando.

Migrar do Android 12 e versões mais recentes (nível 31 da API) para uma versão mais recente

Para atualizar o app e direcioná-lo a uma versão mais recente do Android, siga a lista de mudanças de comportamento relevantes:

Migrar do Android 11 (nível 30 da API) para o Android 12 (nível 31 da API)

Segurança e permissões

Experiência do usuário

  • Notificações personalizadas: as notificações com visualizações de conteúdo personalizadas não vão mais usar a área inteira. Em vez disso, o sistema vai aplicar um modelo padrão. Esse modelo garante que as notificações personalizadas tenham o mesmo estilo que outras notificações em todos os estados. Esse comportamento é quase idêntico ao de Notification.DecoratedCustomViewStyle.
  • Mudanças na verificação de Links do app Android: ao usar a verificação de links do app Android, confira se os filtros de intent incluem a categoria BROWSABLE e têm suporte ao esquema HTTPS.

Desempenho

  • Restrições de inicialização de serviços em primeiro plano: para ser direcionado ao Android 12 ou mais recente, o app não pode iniciar serviços em primeiro plano enquanto é executado em segundo plano, exceto em alguns casos especiais. Se um app tentar iniciar um serviço em primeiro plano durante a execução em segundo plano, uma exceção será gerada (exceto em alguns casos especiais).

    Considere usar o WorkManager para programar e iniciar o trabalho priorizado enquanto o app é executado em segundo plano. Para concluir ações urgentes que o usuário solicita, inicie serviços em primeiro plano com um alarme exato.

  • Restrições de trampolim de notificação: quando os usuários tocam em notificações, alguns apps respondem iniciando um componente de app que inicia a atividade que o usuário visualiza e com a qual interage. Esse componente de app é conhecido como notificação em trampolim.

    Os apps não podem iniciar atividades de serviços ou broadcast receivers que são usados como trampolins de notificação. Depois que um usuário toca em uma notificação ou em um botão de ação na notificação, o app não pode chamar startActivity() dentro de um serviço ou broadcast receiver.

Confira o conjunto completo de mudanças que afetam apps destinados ao Android 12 (nível 31 da API).

Migrar de versões anteriores ao Android 11 (nível 30 da API)

Selecione a versão do Android da qual será feita a migração:

Migrar para o Android 5 (nível 21 da API)

Consulte a página "Mudanças de comportamento" de cada uma das versões abaixo para garantir que seu app tenha considerado as mudanças apresentadas:

Continue seguindo as instruções na próxima seção.

Migrar para o Android 6 (nível 23 da API)

As seguintes considerações se aplicam a apps que segmentam o Android 6.0 e versões mais recentes da plataforma:

  • Permissões de tempo de execução

    • Permissões perigosas são concedidas somente em tempo de execução. Os fluxos de interface do usuário precisam fornecer affordances para conceder essas permissões.

    • Sempre que possível, o app precisa estar preparado para lidar com a rejeição de solicitações de permissão. Por exemplo, se um usuário recusar uma solicitação para acessar o GPS do dispositivo, o app precisará ter outra maneira de prosseguir.

Para ver uma lista completa das mudanças aplicadas no Android 6.0 (nível 23 da API), consulte a página Mudanças de comportamento dessa versão da plataforma.

Continue seguindo as instruções na próxima seção.

Migrar para o Android 7 (nível 24 da API)

As seguintes considerações se aplicam a apps que segmentam o Android 7.0 e versões mais recentes da plataforma:

  • Soneca e App em espera

    Projete para os comportamentos descritos no artigo Otimizar para o "Soneca" e "App em espera", que engloba outras mudanças introduzidas em várias versões de plataforma.

    Quando um dispositivo está nos modos Soneca e App em espera, o sistema se comporta da seguinte maneira:

    • Restringe o acesso à rede.
    • Adia alarmes, sincronizações e trabalhos.
    • Restringe as verificações de GPS e Wi-Fi.
    • Restringe mensagens do Firebase Cloud Messaging de prioridade normal.

  • Mudanças de permissão

    • O sistema restringe o acesso aos diretórios privados do app.
    • A exposição de um URI file:// fora do app aciona uma FileUriExposedException. Caso você precise compartilhar arquivos fora do app, implemente o FileProvider.

  • O sistema proíbe a vinculação a bibliotecas não NDK.

Para ver uma lista completa das mudanças aplicadas no Android 7.0 (nível 24 da API), consulte a página Mudanças de comportamento dessa versão da plataforma.

Continue seguindo as instruções na próxima seção.

Migrar para o Android 8 (nível 26 da API)

As seguintes considerações se aplicam a apps que segmentam o Android 8.0 e versões mais recentes da plataforma:

Para ver uma lista completa das mudanças aplicadas no Android 8.0 (nível 26 da API), consulte a página Mudanças de comportamento dessa versão da plataforma.

Migrar do Android 8 (nível 26 da API) para o Android 9 (nível 28 da API)

Para ver uma lista completa de alterações introduzidas no Android 9.0 (nível 28 da API), consulte as Mudanças de comportamento.

Migrar do Android 9 (nível 28 da API) para o Android 10 (nível 29 da API)

Migrar do Android 10 (nível 29 da API) para o Android 11 (nível 30 da API)

Para uma lista completa das mudanças introduzidas no Android 11 (nível 30 da API), consulte a página Mudanças de comportamento.

Atualize para o nível 31 da API seguindo as instruções da seção anterior.

Modernize seus apps

Ao atualizar o nível desejado da API para os apps, considere adotar recursos recentes da plataforma para modernizá-los e conquistar os usuários.

  • Use o CameraX, que está em Beta, para aproveitar ao máximo o uso da câmera.
  • Use os componentes do Jetpack para seguir as práticas recomendadas, eliminar a escrita de código boilerplate e simplificar tarefas complexas para que você possa se concentrar no código de seu interesse.
  • Use o Kotlin para escrever apps melhores, mais rapidamente e com menos código.
  • Verifique se você está seguindo os requisitos e as práticas recomendadas de privacidade.
  • Adicione suporte ao tema escuro aos seus apps.
  • Adicione compatibilidade com a navegação por gestos aos seus apps.
  • Migre o app do Google Cloud Messaging (GCM) para a versão mais recente do Firebase Cloud Messaging.
  • Aproveite o gerenciamento avançado de janelas.

Verificar e atualizar SDKs e bibliotecas

Verifique se as dependências de terceiros do SDK oferecem suporte à API 31: alguns provedores de SDK publicam isso no manifesto, outros exigem uma investigação maior. Se você usa um SDK incompatível com a API 31, defina como prioridade o trabalho com o provedor do SDK para resolver o problema.

Além disso, observe que o targetSdkVersion do app ou jogo pode restringir o acesso a bibliotecas particulares da plataforma Android. Consulte Vinculação de apps NDK às bibliotecas de plataforma para saber mais.

Também é necessário verificar quaisquer restrições que possam existir na versão da Biblioteca de Suporte do Android que você está usando. Como sempre, é preciso garantir a compatibilidade entre a versão principal da Biblioteca de Suporte do Android e o compileSdkVersion do app.

É recomendável escolher um targetSdkVersion menor ou igual à versão principal da Biblioteca de Suporte. Sugerimos a atualização para uma biblioteca de suporte compatível mais recente, a fim de aproveitar os recursos de compatibilidade e correções de bugs mais novos.

Testar o app

Após atualizar o nível e os recursos da API do app, conforme apropriado, teste alguns casos de uso principais. As sugestões a seguir não são completas, mas visam orientar o processo de teste. Sugerimos testar nos seguintes casos:

  • Se o app compila para a API 29 sem erros nem avisos.

  • Se o app tem uma estratégia para os casos em que o usuário rejeita solicitações de permissão e pede autorizações ao usuário. Para fazer isso, siga estas etapas:

    • Vá para a tela Informações do app e desative cada permissão.
    • Abra o app e garanta que não haja falhas.
      • Realize os principais testes de caso de uso e garanta que as permissões necessárias sejam solicitadas novamente.

  • Se lida com a Soneca com os resultados esperados e sem erros.

    • Usando o adb, coloque seu dispositivo de teste em Soneca enquanto o app estiver em execução.
      • Teste todos os casos de uso que acionam mensagens do Firebase Cloud Messaging.
      • Teste todos os casos de uso que usam alarmes ou tarefas.
      • Elimine todas as dependências nos serviços em segundo plano.
    • Colocar o app no modo "App em espera"
      • Teste todos os casos de uso que acionam mensagens do Firebase Cloud Messaging.
      • Teste todos os casos de uso que usam alarmes.

  • Se lida com novas fotos / vídeos sendo feitos.

  • Processa o compartilhamento de arquivos com outros apps - Teste todos os casos de uso que compartilhem dados de arquivos com qualquer outro app (até do mesmo desenvolvedor).

    • Verifique se o conteúdo é visível no outro app e não aciona falhas.

Mais informações

Ative os e-mails no Google Play Console para que possamos enviar atualizações e comunicados importantes do Android e do Google Play, incluindo nossa newsletter mensal de parceiros.