Target API level 36 no Google Play: prorrogação até 1º/11/2026 e a correção em Expo, Flutter e React Native

A exigência de target API level 36 no Google Play significa que uma versão compilada com alvo abaixo do Android 16 não pode ser publicada. Em outubro de 2026, o Play rejeita todo app novo e toda atualização com alvo em um nível inferior, muitas vezes com a mensagem Target SDK of artifact is too low. Apps que receberam um aviso de política puderam pedir mais prazo, mas a prorrogação termina em 1º de novembro de 2026. Este guia mostra o que a prorrogação ainda garante, como levar Expo, Flutter e React Native para a API 36 e o que costuma quebrar quando você faz isso.

O que a exigência de target API level 36 realmente bloqueia?

Ela bloqueia envios. Desde 31 de agosto de 2026, você não consegue enviar um app novo para celular nem uma atualização a menos que ele tenha como alvo a API 36. Apps já publicados com alvo na API 35 ou superior continuam totalmente disponíveis, inclusive para novos usuários.

Segundo os requisitos de nível desejado da API do Google, "apps novos e atualizações de apps precisam ter como alvo o Android 16 (API level 36) ou superior para serem enviados ao Google Play". Os requisitos variam conforme o formato do dispositivo, e a única exceção completa é para apps permanentemente privados, destinados à distribuição interna em uma única organização.

Um app existente abaixo desses níveis "só ficará disponível em dispositivos com uma versão do Android igual ou inferior ao nível desejado da API do app". Quem já instalou continua usando normalmente. Já uma pessoa com um celular mais novo recebe o aviso de que o app "foi criado para uma versão mais antiga do Android".

Ainda dá para conseguir a prorrogação antes de 1º de novembro de 2026?

Só se o Play enviou um aviso de política para o seu app e o formulário de solicitação ainda aparece nele. Mesmo assim, a prorrogação vai no máximo até 1º de novembro de 2026, então ela serve como alguns dias extras para uma correção quase pronta, não como um novo plano.

O Google diz que envia "um link para o formulário de solicitação de prorrogação pelas Notificações" aos apps afetados e que o formulário fica "disponível na página de detalhes do aviso ou problema na página Status da política". O Google não mostra o formulário para apps que já estão em conformidade.

1. Abra o Play Console e selecione o app.
2. Procure na Caixa de entrada ou nas Notificações a mensagem sobre o nível desejado da API. Se ela estiver lá, siga o link.
3. Se não estiver, vá até Status da política, abra o aviso ou problema de nível desejado da API e procure o formulário de solicitação de prorrogação na página de detalhes.
4. Preencha o formulário para cada app afetado. Cada app tem o próprio aviso.
5. Com ou sem prorrogação concedida, planeje enviar um build com API 36 antes de 1º de novembro de 2026. Depois dessa data, atualizações exigem API 36.

Como levar Expo, Flutter e React Native para a API 36?

O caminho mais limpo é atualizar para uma versão do framework que já tenha a API 36 como alvo: Expo SDK 54, React Native 0.81 ou Flutter 3.38. Se ainda não der para atualizar, você pode subir o número manualmente, mas aí também precisa lidar por conta própria com as mudanças de comportamento do Android 16.

Expo. O changelog do SDK 54 informa que o SDK 54 e o React Native 0.81 estão "agora com alvo no Android 16". Atualize com npx expo install expo@^54.0.0 --fix, rode npx expo-doctor@latest e, se você usa Continuous Native Generation, "apague os diretórios android e ios se você os gerou para uma versão anterior do SDK". No SDK 53 dá para tentar definir targetSdkVersion: 36 pelo plugin expo-build-properties, mas o React Native 0.79 ainda trata o voltar via onBackPressed, então leia a próxima seção antes de publicar.

Flutter. As notas de versão do Flutter 3.38 listam como padrões flutter.compileSdkVersion (API 36) e flutter.targetSdkVersion (API 36), e "recomendam fortemente usar nos arquivos de build as variáveis de API level fornecidas pelo Flutter SDK". A versão 3.38 também exige no mínimo Java 17. Se targetSdk = 35 estiver fixo no módulo do app, a atualização do Flutter não vai mudá-lo, então confira o arquivo.

React Native bare. Defina compileSdkVersion e targetSdkVersion como 36 em android/build.gradle. Na 0.81 ou superior, isso praticamente resolve. Em versões mais antigas, adicione também android:enableOnBackInvokedCallback="false" ao <application> no AndroidManifest.xml. Sem isso, o botão voltar físico e o gesto de voltar ignoram a navegação em JavaScript.

O que quebra quando um app passa a ter o Android 16 como alvo?

A navegação de voltar e os layouts de telas grandes são o que mais quebra. Com a API 36 como alvo, o Android deixa de chamar onBackPressed, não permite mais desativar o edge-to-edge e ignora travas de orientação e de redimensionamento em telas com pelo menos 600dp de largura.

As mudanças que mais afetam apps multiplataforma, segundo as mudanças de comportamento do Android 16 publicadas pelo Google:

• Predictive back: "onBackPressed não é chamado e KeyEvent.KEYCODE_BACK não é mais despachado." Definir android:enableOnBackInvokedCallback="false" é uma forma temporária de desativar.
• Edge-to-edge: windowOptOutEdgeToEdgeEnforcement está "descontinuado e desativado", então um cabeçalho ou botão inferior pode acabar embaixo da barra de status ou da barra de gestos.
• Telas grandes: em telas com 600dp de largura ou mais, screenOrientation, resizableActivity e limites de proporção são ignorados, o que pode esticar layouts feitos só para retrato. Jogos estão isentos. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY é uma forma temporária de desativar que "não se aplicará ao ter como alvo a API level 37".
• Texto: elegantTextHeight é ignorado, o que pode alterar a altura de linha em árabe, tailandês, tâmil e vários outros sistemas de escrita.
• Sensores de saúde: BODY_SENSORS é substituído por permissões de saúde granulares, como READ_HEART_RATE.

Que problemas outros desenvolvedores encontraram ao migrar para a API 36?

Os relatos públicos até agora mostram dois tipos de problema: o comportamento do botão voltar mudando sem nenhum erro, e bibliotecas que fazem o nível desejado do bundle recebido pelo Play ser diferente do que está nos arquivos do projeto.

Audius (React Native 0.79). No pull request #14635, a equipe do Audius conta que o Google Play rejeitou os dois envios da versão Android 1.5.186 com Target SDK of artifact is too low. Eles mudaram compileSdk e targetSdk de 35 para 36, definiram as build tools como 36.0.0 e adicionaram android.suppressUnsupportedCompileSdk=36, porque "o RN 0.79 fixa o AGP 8.8". Também definiram enableOnBackInvokedCallback="false", já que sem isso o voltar "ignoraria o React Navigation". Um PR posterior removeu essa desativação depois da migração para o React Native 0.81, que registra um OnBackPressedCallback por conta própria.

Um app Flutter 3.35.2. Na issue #174516 do Flutter, um desenvolvedor definiu targetSdk 36 no Gradle e no manifest, mas o Play Console continuou informando "Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version" (o bundle tem alvo no SDK 34, mas usa uma biblioteca Play Core incompatível com essa versão). Remover a antiga biblioteca com.google.android.play:core:1.10.3 gerou erros "Missing classes" do R8. Corrigir esses erros levou a "You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles" (não é possível lançar a versão porque nenhum usuário atual conseguiria atualizar para os novos app bundles). O bundle só foi aceito depois de adicionar regras keep do ProGuard, definir o minSdk explicitamente e desativar os splits de idioma, densidade e ABI, ao custo de um download maior.

A lição em comum: mudar o número no Gradle não encerra o trabalho. O Audius precisou corrigir o comportamento em tempo de execução, e o desenvolvedor Flutter precisou corrigir uma dependência que alterava o que o Play lia do bundle. Verifique o artefato gerado e teste em um dispositivo com Android 16, não só o arquivo de configuração.

Como verificar um build com API 36 antes de enviar?

Leia o nível desejado direto do bundle de release, depois coloque o bundle em uma faixa de teste interno ou fechado e teste a navegação de voltar, os insets e um layout de tablet no Android 16. Uma rejeição ou um bug em produção custa muito mais tempo do que essas verificações.

Exemplo prático: um app Expo SDK 53 com alvo na API 35 que precisa de mais uma atualização.

1. Rode npx expo install expo@^54.0.0 --fix, depois npx expo-doctor@latest, e corrija o que ele apontar.
2. Se o projeto usa Continuous Native Generation, apague as pastas antigas android e ios e gere o build de novo. Caso contrário, aplique manualmente as mudanças nativas da atualização.
3. Gere o AAB de release, por exemplo com eas build -p android --profile production.
4. Confirme o alvo com bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. O resultado deve ser 36.
5. Envie para teste interno. Em um celular com Android 16, pressione voltar em todas as telas aninhadas, confira se cabeçalhos e botões inferiores não ficam escondidos sob as barras do sistema e gire um tablet ou um emulador redimensionável.
6. Promova para produção com notas de versão que mencionem as correções para o Android 16.

Para acelerar os testes, use a configuração de testadores do nosso guia de teste fechado do Google Play e aproveite ideias de texto para a atualização nos nossos exemplos de notas de versão. Se preferir delegar o lançamento, nosso serviço de envio para as lojas cobre Play Console e App Store Connect por $599 para as duas lojas. As taxas das contas de desenvolvedor são cobradas à parte.