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

O que muda em 1º de novembro de 2026

Em 1º de novembro de 2026 termina o período de prorrogação publicado pelo Google para o nível de API de destino. Essa data não encerra a sua possibilidade de enviar uma atualização em conformidade e não muda o que um app publicado sem alterações precisa. Duas situações são confundidas o tempo todo:

Ajuda do Google Play Console sobre os requisitos de nível de API de destino e o guia de target SDK do developer.android.com, ambos lidos em 15 de outubro 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: 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 reconferidos em 15 de outubro 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

Desde 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 a regra de API de destino é problema seu agora 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, a migração, ou o fim de uma prorrogação, pode cair no meio da sua janela. O movimento seguro é colocar agora a versão com API 36 na mesma faixa fechada, 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 agora uma versão em conformidade na faixa. 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. Trate a migração para a API 36 como uma tarefa própria, com um ciclo de testes próprio

   Rode as verificações do Android 16 antes do envio, não depois de uma rejeição. Descobrir uma quebra de layout de ponta a ponta no dia em que você precisa publicar é um dia muito diferente de descobrir a mesma coisa uma semana antes.

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

   O período de prorrogação publicado pelo Google termina em 1º de novembro de 2026, e a prorrogação foi solicitada por app afetado, a partir do aviso do próprio app. Depois dessa data, o único caminho é uma versão em conformidade, então isso 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 uma prorrogação concedida cobriu tem que estar concluído até 1º de novembro de 2026; depois disso, um artefato com API 36 em conformidade é a única forma de enviar uma atualização comum para dispositivos móveis.

   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.

E a API 37 em 2027?

O Google anunciou que apps novos e atualizações vão precisar ter como destino a API de nível 37 a partir de agosto de 2027. A tabela de requisitos atual ainda não traz um dia exato nem a matriz de exceções por tipo de dispositivo de 2027, então este post não inventa uma. O calendário de lançamento do próprio Android 17 (estabilidade da plataforma prevista para março de 2026, uma versão principal no 2º trimestre e uma versão secundária do SDK no 4º trimestre) é uma linha do tempo diferente do calendário de destino do Play; mantenha as duas separadas. Parcial: mês anunciado, dia não publicado

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.

Minha atualização foi rejeitada pelo nível de API de destino. O que eu corrijo?

Comece pelo nível de API de destino da versão enviada que o problema cita e depois altere o build que a gerou. Os passos genéricos de migração abaixo são os mesmos; esta é a ordem para executá-los quando o Play Console já disse não.

1. Leia o problema. Abra o problema de API de destino do app em Policy status e anote o version code que ele cita, o destino que ele informa e o piso que ele exige. Guarde uma captura de tela do texto exato.

2. Inspecione esse artefato. Em Test and release, Latest releases and bundles, abra essa versão e leia o nível de API de destino dela. Compare com o branch, o flavour ou a exportação que a gerou. A prova é o artefato, não a configuração do editor.

3. Corrija a origem. Se o artefato estiver abaixo de 36, instale a plataforma da API 36 e suba o compileSdk e o targetSdk, ou siga abaixo o caminho do framework ou do exportador da sua stack. Não mexa no minSdk, a menos que as ferramentas ou as dependências obriguem a uma mudança separada.

4. Teste e depois envie com um version code maior. Rode o build de release assinado no Android 16 e na versão mais antiga que você suporta, principalmente depois de uma mudança no mínimo exigido pelo framework.

5. Confira o novo artefato. Confirme o destino dele no Play Console, confirme o estado da versão e reabra o problema de política depois do processamento. Se o aviso ainda citar uma versão mais antiga, veja em qual faixa essa versão continua ativa; não apague um teste fechado em andamento para limpar o aviso.

6. Continua bloqueado com o artefato certo? Use o caminho de Ajuda do app com o texto do problema, os version codes, a faixa e os detalhes do artefato. Não presuma que um pedido de prorrogação foi concedido; o alcance vem do aviso do próprio app.

Ajuda do Google Play Console sobre como ver versões enviadas e sobre os requisitos de API de destino, o guia de configuração do SDK do Android e relatos de desenvolvedores sobre avisos persistentes, tudo lido em 15 de outubro de 2026. A sequência é uma triagem prática, não uma classificação medida de causas.

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: subir um nível de destino geralmente significa recompilar, e é numa recompilação que aparece um problema independente de tamanho de página em bibliotecas nativas. É essa coincidência de momento 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 está sendo cobrado a fazer duas coisas difíceis e sem relação entre si ao mesmo tempo: 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

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 e reconferido em 15 de outubro de 2026 nas páginas atuais do Google sobre API de destino, tamanho de página e teste fechado. O Google atualiza essas páginas sem avisar, então confira as fontes primárias acima antes de agir com base em qualquer data. Próxima reconferência editorial: depois que o período de prorrogação terminar, em 1º de novembro de 2026.