Prazo da API 36 no Google Play: o que muda em 31 de agosto de 2026

O Google sobe o piso de API de destino da Play Store uma vez por ano, e 2026 é o ciclo da API 36. O número não é a parte confusa. A parte confusa é que "o requisito de nível de API de destino" são na verdade duas regras usando o mesmo nome: uma manda no que você pode enviar, e outra, mais baixa, manda em quem ainda consegue instalar o que já está publicado. Quase toda página que ranqueia para essa pergunta mistura as duas, e é assim que desenvolvedores acabam refazendo um aplicativo que não precisava ser refeito, ou ignorando um aviso do Play Console que importava.

Este post separa as duas, dá os números por tipo de dispositivo e depois responde à pergunta que a nossa caixa de suporte realmente recebe em agosto: o que isso faz com um app que está na metade de um teste fechado (closed testing) de 12 testadores e 14 dias consecutivos? A PrimeTestLab cuida desse lado do teste para desenvolvedores, então vemos essa colisão de agendas o tempo todo, e a orientação daquela seção vale tanto para quem usa um serviço quanto para quem recruta os testadores sozinho. Cada data e cada nível abaixo foram conferidos nas próprias páginas do Google em 9 de agosto de 2026, e tudo o que o Google não documentou de fato aparece marcado como tal, em vez de preenchido com um palpite confiante.

A regra em uma frase

A partir de 31 de agosto de 2026, um app comum de celular, tablet, dobrável ou Android Auto precisa ter como destino o Android 16, API de nível 36 ou superior para ser enviado ao Google Play, seja um app totalmente novo, seja uma atualização de um app já publicado. Essa única frase cobre a maioria dos leitores. As exceções, e o piso mais baixo e separado para apps em que você não vai mexer, são o assunto do resto deste post.

Um nome, duas regras diferentes

O Google usa a expressão "requisito de nível de API de destino" para duas coisas que não se parecem em nada. Manter as duas separadas é a coisa mais valiosa que você pode fazer com esta página.

Ou seja: um app parado na API 35, sem atualizações planejadas, está em conformidade em 31 de agosto pela regra 2, e fica fora de conformidade no instante em que você tenta publicar qualquer coisa pela regra 1. Isso não é uma contradição, é o desenho: o Google sobe a barreira do que entra na loja mais rápido do que sobe a barreira do que fica nela.

As três palavras que o Google define com precisão

A política se apoia em três termos, e cada um tem um significado específico que decide sob qual regra você está:

• App novo: um app "ainda não publicado no Google Play". Primeiro envio de um nome de pacote.
• App existente: um app que já está publicado no Google Play.
• Atualização do app: uma nova versão de um app existente enviada para análise para substituir a atual. Uma atualização é julgada pela regra de envio, não pela regra de disponibilidade.

Requisitos por tipo de dispositivo

"App Android" não é uma linha só. Celulares, tablets, dobráveis e Android Auto vão para a API 36. Wear OS e Android Automotive OS param na API 35. Android TV e Android XR param na API 34. Os pisos para um app que você não vai atualizar são ainda mais baixos, e o botão abaixo alterna entre os dois conjuntos.

Android Auto não é Android Automotive OS

Esses dois nomes custam tempo real aos desenvolvedores todo ano. O Android Auto projeta um app do celular na tela do carro, então o app é um app de celular e segue a regra dos celulares: API 36. O Android Automotive OS é o sistema operacional que roda no próprio veículo, e é uma das exceções nomeadas de destino mais baixo: API 35. Se você faz um app de mídia ou navegação que roda nos dois, precisa do maior entre eles.

Isso afeta você? Responda três perguntas

Se 31 de agosto é problema seu depende de três coisas: o que você está prestes a fazer, para qual tipo de dispositivo você publica e qual nível a sua versão atual realmente tem como destino. A ferramenta abaixo aplica os pisos publicados pelo Google a essa combinação e diz sob qual das duas regras você está.

Se o veredito disser que você está livre, ainda vale a pena ver o checklist antes do prazo lá no fim, porque "meu código define destino 36" e "o artefato que o Google avaliou declara 36" não são a mesma afirmação. A falsa sensação de segurança mais comum de todo este ciclo é um desenvolvedor lendo o arquivo do Gradle em vez do pacote que enviou.

O que acontece de verdade se você perder o prazo de 31 de agosto

Duas coisas diferentes, dependendo da regra sob a qual você está. Se você tentar enviar uma versão abaixo do piso, o envio não atende ao requisito. Se você simplesmente deixar um app publicado parado abaixo do piso de disponibilidade, ele deixa de ser encontrado e instalado por novos usuários em dispositivos que rodam uma versão do Android mais nova do que a que ele tem como destino. Nenhum dos dois desfechos é remoção.

Se você tentar enviar

Repare a que essa consequência está presa: ao ato de enviar. O calendário sozinho não faz nada com uma versão que já está no ar. É por isso que um app pode estar perfeitamente em conformidade no dia 1º de setembro e bloqueado no dia 2, puramente porque você decidiu publicar uma correção de bug.

Se você deixar um app publicado abaixo do piso

Esta é a parte que os concorrentes descrevem como "seu app some", o que está errado de um jeito que importa. A formulação do Google é que o app vai "deixar de ser encontrado" por um grupo específico de usuários. Na prática:

• Novos usuários em dispositivos mais novos perdem o acesso. Se o dispositivo de um usuário roda uma versão do Android maior do que o destino do seu app, o Google Play deixa de mostrar e de instalar o app para ele.
• Novos usuários em dispositivos mais antigos não são afetados. Um dispositivo que roda o mesmo nível de API do destino do app, ou um nível menor, continua conseguindo receber o app.
• Quem já instalou não é afetado. Qualquer pessoa que já instalou o app continua conseguindo encontrar, reinstalar e usar nas versões compatíveis do Android.
• Os links diretos dizem a verdade. Um usuário em um dispositivo mais novo e inelegível que abrir o link da Play Store recebe o aviso de que o app foi "feito para uma versão mais antiga do Android".

O que não acontece

Todo mês de agosto essa política gera os mesmos quatro medos nos fóruns de suporte do Google. Nenhum deles é o que a página de nível de API de destino descreve.

Migrar para a API 36 acaba com o suporte a celulares antigos?

Não, não por si só. O targetSdk declara o nível de comportamento do Android para o qual seu app foi feito e testado. O minSdk decide a versão mais antiga do Android em que ele pode ser instalado. São números separados, e subir o destino para 36 não sobe o mínimo por conta própria: seu app pode continuar dando suporte a versões antigas do Android até esse mínimo, desde que o seu código e as dependências atualizadas continuem compatíveis.

Este é o mal-entendido que gera mais alarme todo ciclo. Um desenvolvedor lê "precisa ter como destino o Android 16", supõe que isso quer dizer "só roda no Android 16" e conclui que o Google acabou de apagar a maior parte dos aparelhos que ele alcança. Arraste o mínimo abaixo e veja o que muda de verdade.

Os três números, e qual deles o Google Play fiscaliza

O que isso significa se o seu app está em teste fechado agora

Se você tem uma conta pessoal de desenvolvedor nova e está rodando o teste fechado obrigatório de 12 testadores por 14 dias consecutivos, o prazo cai bem no meio da sua janela. O movimento seguro é colocar a versão com API 36 na mesma faixa fechada antes de 31 de agosto, manter todos os testadores participando e nunca deixar um prazo forçar você a trocar de faixa ou recomeçar com outros testadores.

A página de API de destino do Google e a página de teste fechado do Google são escritas por times diferentes com objetivos diferentes, e nenhuma das duas trata da outra. Isso deixa uma lacuna real, e o honesto a fazer é mostrar exatamente onde o terreno documentado acaba.

O que está verificado

• Uma conta pessoal nova que se enquadra "precisa realizar um teste fechado" com pelo menos 12 testadores participando continuamente nos últimos 14 dias antes de poder solicitar o acesso de produção. Isso vale para contas pessoais criadas após 13 de novembro de 2023. Verificado
• A documentação para desenvolvedores do Google diz que um APK enviado precisa atender aos requisitos de API de destino do Play, e não publica nenhuma exceção para faixas de teste. Essa formulação vale para qualquer faixa, não é específica de teste, então planeje um envio novo para a faixa fechada depois do prazo como se ele precisasse de API 36. Isso é uma inferência forte, não uma regra documentada para faixas de teste. Parcial
• A orientação do próprio Google incentiva os desenvolvedores a continuar atualizando o app em teste fechado enquanto corrigem problemas, e define o período que conta em torno da continuidade da participação dos testadores, não em torno de um artefato congelado. Verificado
• O teste interno tem limite de 100 testadores e não substitui o teste fechado que qualifica. Verificado

O que o Google não documentou

Como a resposta é desconhecida, a estratégia certa não é tentar prevê-la. É tornar a pergunta irrelevante, tendo uma versão em conformidade na faixa antes da data. Isso é seguro nos dois desfechos e não custa nada a você se o artefato antigo fosse mesmo continuar rodando.

A sequência que é segura de qualquer jeito

1. Mantenha a mesma faixa fechada e o mesmo grupo de testadores

   Não crie uma faixa nova para receber a versão com API 36 e não remova testadores que estão participando. A continuidade de 14 dias que o Google conta é sobre os testadores permanecerem inscritos, então a inscrição é o ativo que você está protegendo.

2. Compile e teste a API 36 antes do prazo, não em cima dele

   Trate a migração como uma tarefa própria, com um ciclo de testes próprio. Descobrir uma quebra de layout de ponta a ponta em 30 de agosto é um dia muito diferente de descobrir a mesma coisa em 10 de agosto.

3. Envie para a faixa fechada existente com um versionCode maior

   Todo pacote que substitui outro precisa de um versionCode incrementado. O Google define o período que conta em torno da continuidade da participação dos testadores e incentiva explicitamente os desenvolvedores a continuar corrigindo problemas durante o teste, mas não publica uma garantia absoluta que cubra todos os cenários de substituição de versão. Mantenha a mesma faixa e os mesmos testadores participando, e confira o contador do Play Console depois. A mecânica completa de atualizar no meio do teste vale a leitura se este é o seu primeiro ciclo.

4. Confirme que a versão chegou mesmo aos testadores

   Uma versão publicada não é a mesma coisa que uma versão entregue. Verifique se a versão fechada está no ar, se o versionCode é maior e se os testadores da lista conseguem ver a atualização.

5. Confira o status da política de novo depois do processamento

   Dê tempo para o pacote ser processado e então reabra a página de status da política do app. Se o aviso de API de destino continuar, trabalhe a lista de diagnóstico em vez de sair apagando versões a esmo.

6. Peça a prorrogação só se a migração realmente não couber no prazo

   Ela compra tempo até 1º de novembro de 2026 e é solicitada por app afetado. Não é motivo para pausar o trabalho técnico.

Como solicitar a prorrogação até 1º de novembro de 2026

Desenvolvedores afetados podem pedir uma prorrogação que mantém a distribuição funcionando até 1º de novembro de 2026. Ela é solicitada por app, a partir do aviso de política daquele app no Play Console. O Google não a descreve como automática, garantida ou uma isenção permanente, então continue a migração enquanto o pedido estiver aberto.

Google Play Console · captura de tela real Clique para ampliar

1. Abra o app afetado no Play Console

   O acesso à prorrogação é por app, não por conta. Se você publica vários apps, conte com repetir isso para cada um dos afetados.

   Verificado
2. Vá até o status da política

   Só os apps que o Google considera fora de conformidade devem carregar o problema de API de destino. Se o app já está em conformidade, não há nada aqui para prorrogar e não existe formulário para encontrar.

   Verificado
3. Abra o aviso de API de destino ou os detalhes do problema

   O título do problema mostrado na captura de tela acima é App must target Android 16 (API level 36) or higher. A redação ainda pode variar por app e pelo estágio do lançamento, então trate isso como o que uma conta real viu, e não como uma string universal garantida.

   Verificado
4. Siga o link de prorrogação no problema ou nas notificações

   O Google leva parte dos desenvolvedores afetados pela notificação do app em vez do painel do problema. Confira os dois antes de concluir que a opção não existe para você.

   Verificado
5. Envie as informações solicitadas

   O Google não publica as perguntas exatas na página de ajuda pública, então trate qualquer lista de "as perguntas que eles fazem" como não verificada. Responda a partir do seu plano de migração real.

   Parcial
6. Trate 1º de novembro de 2026 como o limite final

   A prorrogação move a data, não elimina o requisito. O que você não conseguiu terminar até 31 de agosto tem que estar pronto até 1º de novembro.

   Verificado
7. Continue migrando enquanto o pedido está aberto

   Nada na formulação do Google promete aprovação. Planejar em cima de uma prorrogação que você ainda não recebeu é a suposição mais cara disponível neste ciclo.

   Parcial

Mais uma distinção que vale guardar: o Google prende a nota de rodapé da prorrogação ao requisito da API 36, e o texto dele quase sempre descreve a prorrogação como algo que preserva a distribuição de um app existente. Ele não percorre com a mesma precisão todas as combinações de app novo, atualização e app existente. Antes de supor que uma prorrogação cobre um envio específico que você planejou, leia o que o aviso do seu próprio app diz que ela cobre.

Como migrar um app para a API 36

Quatro passos: instalar o SDK da API 36, subir compileSdk e targetSdk para 36, atualizar as dependências que quebram quando você faz isso e testar as mudanças de comportamento do Android 16. Trocar o número é uma edição de uma linha. Provar que o app continua funcionando é a migração de verdade.

Passo 1: instale o SDK do Android 16

Abra o Android Studio, vá até o SDK Manager e instale a Android SDK Platform para a API de nível 36 junto com as build tools 36.x.x atuais. Sem a plataforma instalada, subir o compileSdk só gera um erro de compilação que parece não ter relação com nada do que você fez.

Passo 2: suba os níveis no seu build

Escolha o seu stack. O caminho do arquivo e as linhas exatas mudam, o destino não: o manifesto dentro do pacote que você enviou precisa declarar destino 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Passo 3: atualize dependências e ferramentas do framework

Subir o nível de compilação é onde as dependências antigas falham. Conte com mexer no Android Gradle Plugin, no próprio Gradle, no Kotlin, nas bibliotecas AndroidX, no Google Play services e em qualquer SDK de anúncios ou analytics que traga código nativo. Este post de propósito não publica "as versões corretas", porque as versões compatíveis mudam toda semana e uma lista fixa aqui estaria enganando em quinze dias. Tire as versões das notas de lançamento atuais do seu próprio framework no dia em que você migrar.

Passo 4: compile, envie e confira o artefato

• Gere um Android App Bundle assinado e incremente o versionCode.
• Teste o artefato de release, não só uma versão de debug. Minificação e redução de recursos quebram coisas que as versões de debug escondem.
• Envie para a faixa pretendida e confirme no Play Console que o artefato informa nível de API de destino 36.
• Depois do processamento, revise todas as faixas ativas e reabra o status da política.

Comportamentos do Android 16 para testar antes de publicar a API 36

Ter a API 36 como destino liga os comportamentos do Android 16 para o seu app em dispositivos com Android 16. Os comportamentos de alta prioridade a testar são layout de ponta a ponta, voltar preditivo, liberdade de orientação em telas grandes, permissões de saúde, agendamento em intervalo fixo e layout de texto. Marque o que se aplica abaixo e você recebe a lista de testes do seu app em vez de uma lista genérica.

Ponta a ponta e voltar preditivo: o maior raio de impacto

O layout de ponta a ponta tem um raio de impacto amplo porque não exige que o seu app use nenhuma API exótica. No Android 16, um app com destino API 36 não pode mais usar o atributo de exclusão anterior, então o conteúdo que contava com as barras do sistema abrindo espaço passa a correr por baixo delas. O sintoma é cosmético até o momento exato em que um botão principal fica embaixo da barra de gestos e deixa de ser tocável.

O voltar preditivo tem um raio de impacto parecido. Se o seu app registra tratamento de voltar no modelo antigo, esse caminho pode simplesmente não disparar como antes assim que o voltar preditivo estiver ligado por padrão no destino 36. Teste o voltar a partir de todas as profundidades de navegação que você tem: modais, WebViews, formulários com alterações não salvas e a última tela antes de sair.

O que não é uma quebra universal do destino 36

E o requisito de páginas de 16 KB?

Requisito diferente, data diferente, mesmos apps. O prazo de API de destino trata do nível que o seu manifesto declara. O requisito de páginas de 16 KB trata de saber se as suas bibliotecas nativas funcionam em dispositivos com páginas de memória de 16 KB. A orientação atual do Google aponta 1º de fevereiro de 2027 como a data em que atualizações de apps afetados sem suporte a 16 KB não poderão mais ser lançadas.

• Quem é afetado: o requisito do Google vale para apps com destino API 35 ou superior em dispositivos de 64 bits do Google Play. Dentro desse grupo, os apps que empacotam bibliotecas nativas .so, direto ou por meio de um SDK, são os que mais provavelmente vão precisar de trabalho explícito de recompilação e alinhamento. Se o seu app é só Kotlin ou Java, ele em geral já é compatível, mas ainda assim vale testar em vez de supor.
• O que ele não é: não faz parte do prazo de API de destino de 31 de agosto de 2026, e passar em um não é passar no outro.
• Por que os dois caem juntos: quem está subindo o nível de destino este mês já vai recompilar de qualquer jeito, e é aí que a checagem de páginas aparece. É essa coincidência de agenda que faz os dois se confundirem.

Se o seu app empacota bibliotecas nativas, trate a checagem de páginas como uma tarefa própria, com um ciclo de testes próprio, em vez de algo que você enfia na versão da API 36 na última hora. As duas mudanças mexem em partes diferentes do build, e depurar as duas ao mesmo tempo é como uma migração de uma semana vira uma de três.

Você enviou a API 36 e o aviso continua ali

Em geral é uma de três coisas: o pacote ainda não terminou de processar e o status da política não atualizou, um artefato mais antigo continua parado em outra faixa ativa, ou o artefato que você enviou não declara 36 de fato, mesmo que o seu projeto declare. Percorra a lista, e não comece a apagar versões.

O título de problema que os desenvolvedores estão relatando agora é Your app must target Android 16 (API level 36) or higher, em inglês, como aparece no Play Console. O Google não publicou uma mensagem de erro canônica e completa para todos os fluxos de envio, então trate as redações exatas que você encontrar por aí, inclusive essa, como observadas e não como oficiais.

Um hábito resolve a maior parte disso de forma permanente: depois de cada envio, leia o nível de API de destino de volta a partir do artefato no Play Console e anote ao lado do versionCode. Leva dez segundos e tira da sua semana a categoria inteira de "tenho certeza de que corrigi isso".

O checklist antes do prazo

Quatorze itens, na ordem em que acontecem de verdade. Os quatro últimos são os que as pessoas pulam, e são justamente os que decidem se o aviso vai sumir.

Onde a PrimeTestLab entra nesse prazo

Para deixar o limite claro: a gente não migra o seu código. Subir o targetSdk, atualizar dependências e corrigir as mudanças de comportamento do Android 16 é trabalho do seu build, e este post é toda a nossa contribuição para isso. O que a gente cobre é a outra metade da colisão: os 12 testadores reais, participando por 14 dias consecutivos, que uma conta pessoal nova precisa antes de conseguir chegar à produção.

O problema é a coincidência de agenda. Quem publica pela primeira vez em agosto de 2026 está sendo cobrado a fazer duas coisas difíceis e sem relação entre si na mesma janela: publicar uma versão com API 36 e segurar um teste fechado que se qualifique por duas semanas seguidas. O build é uma tarefa de engenharia que se resolve. Recrutar doze pessoas de verdade que continuem participando por quatorze dias, em dispositivos reais, é a parte que consome um mês inteiro sem fazer barulho.

Fazer o teste fechado sozinho ou entregar para a gente

A ordem em que fazer as coisas neste mês

Se você está encarando os dois problemas ao mesmo tempo, rode os dois em paralelo em vez de em sequência. Comece o teste fechado agora, porque os 14 dias dele são tempo de calendário que não dá para comprimir, e faça a migração para a API 36 em paralelo. Empurre a versão em conformidade para a mesma faixa fechada quando ela estiver pronta, com um versionCode maior e os mesmos testadores ainda participando. Assim o prazo e a janela de teste param de disputar a mesma quinzena.

Perguntas frequentes

Resumo

Retrato da política conferido em 9 de agosto de 2026. O Google atualiza essas páginas sem avisar, então confira as fontes primárias acima antes de agir com base em qualquer data. Este post está programado para nova conferência logo depois de 31 de agosto e de novo depois de 1º de novembro de 2026.