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 do Google Play.

A partir de 31 de agosto de 2024:

• Os novos apps e atualizações precisam ser direcionados ao Android 14 (nível 34 da API) ou versões mais recentes para serem enviados ao Google Play. Os apps para Wear OS e Android TV precisam ser direcionados ao Android 13 (nível 33 da API) ou versões mais recentes.
• Os apps atuais precisam ser direcionados ao Android 13 (nível 33 da API) ou versões mais recentes para continuarem disponíveis a novos usuários em dispositivos com uma versão do SO Android mais recente que o nível desejado da API. Os apps direcionados 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 o SO Android igual ou anterior ao nível desejado da API do app.

Você pode pedir uma extensão até 1o de novembro de 2024 se precisar de mais tempo para atualizar o app. Você vai poder 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 restritos a usuários em uma organização específica e destinados somente à distribuição interna.
• Apps destinados ao Android Automotive OS ou empacotados com APKs destinados ao Android Automotive OS.

Observação: apps desatualizados não estão disponíveis para novos usuários de dispositivos com versões mais recentes do Android. Para mais informações, consulte a seção "Requisitos de disponibilidade do app" no artigo Requisitos de nível desejado da API para apps do Google Play na Ajuda do Play Console.

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 do Android. Algumas dessas mudanças se aplicam somente a apps que declaram o suporte explicitamente por meio do atributo de manifesto targetSdkVersion, também conhecido como o nível desejado da API.

Configurar o app para ser direcionado a um nível de API recente garante que os usuários se beneficiem dessas melhorias, enquanto o app ainda pode ser executado em versões mais antigas do Android. Segmentar um nível de API recente também permite que o app aproveite os últimos recursos da plataforma para encantar os usuários. Além disso, no Android 10 (nível 29 da API) os usuários verão um aviso ao iniciarem um app pela primeira vez se o app for direcionado 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.

Observação: se o arquivo Gradle contiver entradas de manifesto, será possível confirmar ou mudar o valor atual de targetSdkVersion no arquivo Gradle do app, conforme descrito em Configurar seu build. Como alternativa, você pode usar o atributo android:targetSdkVersion no arquivo de manifesto, conforme descrito na documentação do elemento de manifesto <uses-sdk>.

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

Para atualizar o app para uma versão mais recente do Android, siga a lista de mudanças de comportamento relevantes:

• Mudanças de comportamento do Android 13
• Mudanças de comportamento do Android 14

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

Segurança e permissões

• Bluetooth: é necessário substituir as declarações das permissões BLUETOOTH e BLUETOOTH_ADMIN pelas permissões BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE ou BLUETOOTH_CONNECT. Não é mais necessário fazer solicitações de permissão de execução de LOCATION para operações Bluetooth.
• Localização: os usuários podem solicitar que os apps recuperem apenas informações de local aproximado. Será necessário solicitar a permissão ACCESS_COARSE_LOCATION sempre que solicitar ACCESS_FINE_LOCATION.
  • Filtros de intent: se o app tiver atividades, serviços ou broadcast receivers que usam filtros de intent, declare explicitamente o atributo android:exported para esses componentes.
• Hibernação: os apps poderão ser colocados em modo de hibernação se não forem usados por um período. No modo de hibernação, as permissões de execução e o cache do app são redefinidos e não é possível executar jobs ou alertas. Você pode conferir o status de hibernação do app.
• Mutabilidade de intent pendente: é necessário especificar a mutabilidade de cada objeto PendingIntent criado pelo seu app.

Experiência do usuário

• Notificações personalizadas: as notificações com visualizações de conteúdo personalizadas não vão mais usar toda a área de notificação. Em vez disso, o sistema vai aplicar um modelo padrão. Esse modelo garante que as notificações personalizadas tenham a mesma decoração que outras notificações em todos os estados. Esse comportamento é quase idêntico ao comportamento 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 oferecem suporte ao esquema HTTPS.

Desempenho

• Restrições de inicialização de serviços em primeiro plano: para ser direcionado ao Android 12 ou versões mais recentes, 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 vai ocorrer (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 solicitadas pelo usuário, 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 do app que inicia a atividade que o usuário vê e com que interage. Esse componente do app é conhecido como uma notificação em trampolim.

  Os apps não podem iniciar atividades em serviços ou broadcast receivers que são usados como notificações em trampolim. Depois que um usuário toca em uma notificação ou 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:

• Android 5.0 (nível 21 da API)
• Android 4.4 (nível 19 da API)
• Android 4.1.x (nível 16 da API)

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 alterações introduzidas no Android 6.0 (nível 23 da API), consulte a página Alterações 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 alterações introduzidas no Android 7.0 (nível 24 da API), consulte a página Alterações 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:

• Limites de execução em segundo plano
  • O sistema restringe serviços para apps que não estão sendo executados em primeiro plano.
    • startService() agora gera uma exceção quando um app tenta invocá-lo enquanto startService() está proibido.
    • Para iniciar serviços em primeiro plano, um app precisa usar startForeground() e startForegroundService().
    • Analise com atenção as alterações feitas na API JobScheduler, conforme documentado na página Mudanças de comportamento do Android 8.0 (nível 26 da API).
    • O Firebase Cloud Messaging exige a versão 10.2.1 do SDK do Google Play Services ou mais recente.
    • Ao usar o Firebase Cloud Messaging, a entrega de mensagens está sujeita a limites de execução em segundo plano. Quando o trabalho em segundo plano é necessário no recebimento da mensagem, como para executar a sincronização de dados em segundo plano, o app precisa agendar tarefas usando o Firebase Job Dispatcher ou o JobIntentService. Para saber mais, consulte a documentação do Firebase Cloud Messaging.
  • Transmissões implícitas
    • Transmissões implícitas são restritas. Para saber mais sobre como lidar com eventos em segundo plano, consulte a documentação da API JobScheduler.
  • Limites da localização em segundo plano
    • Os apps executados em segundo plano têm acesso limitado aos dados de localização.
      • Em dispositivos com o Google Play Services, use o provedor de localização combinada para receber atualizações periódicas sobre a localização.
• Canais de notificação
  • É necessário definir as propriedades de interrupção de notificação por canal.
  • Atribua notificações a um canal para que elas apareçam.
  • Esta versão da plataforma é compatível com NotificationCompat.Builder.
• Privacidade
  • O ANDROID_ID é delimitado por chave de assinatura do app.

Para ver uma lista completa das alterações introduzidas no Android 8.0 (nível 26 da API), consulte a página Alterações 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)

• Gerenciamento de energia
  • Os buckets do App em espera trazem novas restrições de segundo plano com base no engajamento do app, como tarefas adiadas, alarmes e cotas em mensagens de alta prioridade
  • Os aprimoramentos da Economia de bateria aumentam as limitações do recurso App em espera.
• Permissão de serviço em primeiro plano
  • É preciso solicitar a permissão normal FOREGROUND_SERVICE (não a permissão de execução)
• Mudanças de privacidade
  • Acesso limitado a sensores em segundo plano
  • Acesso restrito a registros de chamadas, agora no grupo de permissões CALL_LOG
  • Acesso restrito a números de telefone, exigindo a permissão READ_CALL_LOG
  • Acesso restrito a informações de Wi-Fi

Para ver uma lista completa das mudanças 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)

• Notificações com uma intent para tela cheia
  • É preciso solicitar a permissão normal USE_FULL_SCREEN_INTENT (não a permissão de execução).
• Compatibilidade com dispositivos dobráveis e de tela grande
  • Agora várias atividades podem ser colocadas no estado "retomada" ao mesmo tempo, mas somente uma delas receberá destaque.
    • Essa mudança afeta o comportamento de onResume() e onPause().
    • Novo conceito de ciclo de vida de "principal atividade retomada", que pode ser detectado ao se inscrever em onTopResumedActivityChanged().
      • É possível marcar apenas um item como "principal atividade retomada".
  • Quando resizeableActivity é definido como false, os apps também podem especificar um minAspectRatio que coloca automaticamente o app com efeito letterbox em proporções mais estreitas.
• Mudanças de privacidade
  • Armazenamento com escopo
    • O acesso ao armazenamento externo é limitado somente a um diretório específico do app e a tipos específicos de mídia criados por ele.
  • O acesso à localização fica restrito enquanto o app está em segundo plano, exigindo a permissão ACCESS_BACKGROUND_LOCATION.
  • O acesso a identificadores não reconfiguráveis, como IMEI e número de série, fica restrito.
  • O acesso a informações de atividades físicas, como a contagem de passos do usuário, fica restrito, exigindo a permissão ACTIVITY_RECOGNITION.
  • O acesso fica restrito a algumas APIs de telefonia, Bluetooth e Wi-Fi, exigindo a permissão ACCESS_FINE_LOCATION.
  • Restringiu o acesso às configurações de Wi-Fi
    • Os apps não podem mais ativar ou desativar o Wi-Fi diretamente e precisam fazer isso usando painéis de configurações.
    • Restrições para iniciar uma conexão com uma rede Wi-Fi, exigindo o uso de WifiNetworkSpecifier ou WifiNetworkSuggestion.

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

• Privacidade
  • Aplicação do armazenamento com escopo: os apps precisam adotar o modelo de armazenamento com escopo. Nele, mídia e outros tipos de arquivo específicos do app são salvos e acessados por locais exclusivos.
  • Redefinição automática de permissões: se os usuários não interagirem com um app por alguns meses, o sistema redefinirá automaticamente as permissões confidenciais do app. Isso não afeta a maioria dos apps. Caso seu app funcione principalmente em segundo plano, sem interações com o usuário, solicite que os usuários desativem a redefinição automática.
  • Acesso à localização em segundo plano: os apps precisam solicitar a permissão de localização em primeiro e segundo plano separadamente. A concessão da permissão de localização em segundo plano só pode ser feita nas configurações do app, e não em caixas de diálogo de permissão de execução.
  • Visibilidade do pacote: quando um app consulta a lista de apps e serviços instalados no dispositivo, a lista retornada é filtrada.
    • Se você usar os serviços de conversão de texto em voz ou de reconhecimento de fala, será necessário adicionar elementos de consulta para serviços ao arquivo de manifesto.
• Segurança
  • Arquivos "resource.arsc" compactados não são mais compatíveis
  • O Esquema de assinatura do APK v2 agora é obrigatório. Por motivos de compatibilidade com versões anteriores, os desenvolvedores também precisam continuar assinando com o Esquema de assinatura do APK v1.
  • Restrição da interface não SDK. Não é recomendável usar interfaces não SDK para apps destinados ao nível 30 da API porque algumas delas foram bloqueadas. Consulte Interfaces não SDK que agora estão bloqueadas no Android 11 para ver uma lista abrangente dessas interfaces.

Para ver 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á na versão Beta, para aproveitar ao máximo a 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.
  • Ofereça suporte a proporções maiores (mais que 16:9) para aproveitar os avanços recentes no hardware. Verifique se o app é redimensionado para preencher o espaço disponível na tela. Declare uma proporção máxima apenas como último recurso. Para saber mais sobre as proporções máximas, consulte Declarar suporte restrito à tela.
  • Adicione suporte a várias janelas para ajudar seu app a aumentar a produtividade e gerenciar várias telas.
  • Se uma ótima experiência no app minimizado melhorar a experiência do usuário, adicione suporte ao picture-in-picture.
    • Otimize para dispositivos com corte de tela.
    • Não presuma a altura da barra de status. Em vez disso, use WindowInsets e View.OnApplyWindowInsetsListener. Para saber mais, assista ao vídeo do droidcon NYC 2017.
    • Não presuma que o app terá a janela inteira. Em vez disso, confirme a localização usando View.getLocationInWindow(), não View.getLocationOnScreen(). * Ao processar MotionEvent, use MotionEvent.getX() e MotionEvent.getY(), e não MotionEvent.getRawX(), MotionEvent.getRawY().

Verificar e atualizar SDKs e bibliotecas

Verifique se as dependências de terceiros do SDK oferecem suporte à API 31: alguns provedores de SDK as publicam no manifesto, outros exigirão uma investigação mais detalhada. Se você usa um SDK incompatível com a API 31, defina como prioridade trabalhar 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 privadas da plataforma Android. Consulte Vinculação de apps NDK a bibliotecas de plataforma para saber mais.

Verifique também se há restrições na versão da Biblioteca de Suporte do Android que você está usando. Como sempre, você precisa garantir a compatibilidade entre a versão principal da Biblioteca de Suporte do Android e a compileSdkVersion do app.

Recomendamos que você escolha 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

Depois de 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 é compilado 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 permissões a ele. 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.
    • Execute os principais testes de casos 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.
  • Coloque 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 novos vídeos/fotos sendo feitos.

  • Confira se o app processa as transmissões restritas ACTION_NEW_PICTURE e ACTION_NEW_VIDEO corretamente, ou seja, movidas para as tarefas do JobScheduler.
  • Verifique se todos os casos de uso críticos que dependem desses eventos ainda funcionam.

• Lida com o compartilhamento de arquivos com outros apps: teste qualquer caso de uso que compartilhe dados de arquivos com qualquer outro app (até mesmo outro app 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 a você atualizações e comunicados importantes do Android e do Google Play, incluindo nossa newsletter mensal para parceiros.