Publicar Jogo Unity na Play Store: AAB, Keystore e Console

Para publicar jogo Unity na Play Store você precisa de quatro coisas: uma conta no Google Play Console, uma keystore criada e guardada em lugar seguro, um AAB gerado com IL2CPP, ARM64 e target API 36, e uma ficha de loja completa. Se a sua conta é pessoal e nova, ainda tem uma quinta: um teste fechado com 12 testadores durante 14 dias antes de liberar a produção.

Este guia segue a ordem em que as coisas travam de verdade. No fim você tem o jogo no Play Console, assinado com uma chave que você não vai perder, e sabe o que o Google costuma recusar antes de você clicar em enviar.

O que precisa antes de começar

Confira esta lista antes de abrir o Play Console. Cada item que falta vira uma tarde perdida depois.

• Unity 6.3 LTS com o módulo Android Build Support instalado pelo Unity Hub (inclui OpenJDK, Android SDK e NDK). Instale tudo pelo Hub: misturar SDK baixado por fora é a causa número um de build quebrada.
• Um celular Android real para testar. O emulador ajuda, mas toque, desempenho e tela recortada só aparecem no aparelho.
• Package name definitivo, no formato com.seuestudio.nomedojogo. Depois que o app sobe para o Console, esse nome nunca mais muda.
• Ícone 512 x 512 px, imagem de destaque 1024 x 500 px e pelo menos duas capturas de tela do jogo.
• Uma URL de política de privacidade. Mesmo um jogo sem login precisa dela, especialmente se tiver anúncio ou analytics.

Se você ainda não gerou nem um APK para rodar no celular, comece por aí: gerar APK na Unity cobre a parte de instalar o módulo e testar no aparelho. Este post assume que o jogo já roda no seu Android.

Conta de desenvolvedor Google Play

Acesse play.google.com/console e crie a conta. Você escolhe entre pessoal e organização. A organização pede número D-U-N-S da empresa; a pessoal pede documento com foto e verificação de identidade. A taxa de registro é de US$ 25, paga uma vez, no cartão de crédito ou débito em seu nome (cartão pré-pago não passa), conforme a central de ajuda do Play Console consultada em outubro de 2026.

A escolha entre pessoal e organização muda uma coisa importante, que aparece mais à frente: o teste fechado obrigatório. Se você já tem CNPJ e pretende lançar mais de um jogo, vale olhar a opção organização com calma antes de decidir.

Keystore: criar e não perder

Todo app Android é assinado com uma chave. Na Unity, a chave vive num arquivo .keystore com uma senha do arquivo e uma senha da chave (alias). Perder esse arquivo ou a senha é o erro mais caro desta lista, então faça direito na primeira vez.

1. Abra Edit > Project Settings > Player, aba Android.
2. Expanda Publishing Settings e clique em Keystore Manager.
3. No menu Keystore, escolha criar uma nova keystore e salve o arquivo fora da pasta Assets (ex.: C:\keys\meujogo.keystore). Dentro do projeto ele acaba indo para o Git.
4. Defina a senha (só caracteres ASCII) e confirme.
5. Em New Key Values: Alias (ex.: upload), senha da chave, Validity (years) (o padrão é 50, deixe), e nome, organização e país (BR).
6. Clique em Add Key e confirme para usar essa keystore no projeto.

Depois disso, faça duas cópias do arquivo (um drive na nuvem e um pendrive, por exemplo) e guarde as duas senhas num gerenciador de senhas. A Unity não guarda a senha entre sessões: toda vez que você reabre o projeto e vai gerar o build de release, precisa digitar de novo em Publishing Settings. Isso é proposital.

Play App Signing: o que essa keystore realmente é

Apps novos na Google Play usam Play App Signing. Funciona assim: o Google guarda a chave que assina o app (app signing key) e você assina cada envio com a sua chave de upload (a keystore que acabou de criar). O Google confere a chave de upload, remove o que você assinou e assina de novo com a chave dele antes de entregar ao jogador.

A consequência prática: se você perder a keystore, dá para pedir a redefinição da chave de upload no Play Console (em Configuração > Integridade do app) e continuar atualizando o mesmo jogo. Não é instantâneo, então trate a keystore como se a redefinição não existisse.

Gerar AAB com target API certo

A Google Play recebe AAB (Android App Bundle) para apps novos. O APK serve para você testar; o AAB é o que vai para a loja, e o Google monta a partir dele o APK enxuto de cada aparelho.

Player Settings que a loja cobra

Em Project Settings > Player > Android > Other Settings:

• Scripting Backend: IL2CPP. A Google Play exige 64 bits, e o backend Mono não gera ARM64.
• Target Architectures: ARM64 marcado. ARMv7 só se você quiser atender aparelhos 32 bits muito antigos, e isso aumenta o build.
• Minimum API Level: a Unity 6.3 suporta a partir do Android 7.1 (API 25), segundo o manual de requisitos da Unity. Subir o mínimo reduz a quantidade de aparelhos compatíveis, então só suba se algum plugin exigir.
• Target API Level: API level 36. A página oficial de requisitos de target do Android Developers, atualizada em outubro de 2026, diz que desde 31/08/2026 apps novos e atualizações precisam mirar o Android 16 (API 36) ou superior. Quem precisar de mais prazo pode pedir extensão até 01/11/2026. Selecione o número explícito em vez de "Automatic (highest installed)" para saber exatamente o que está mandando.
• Version (ex.: 1.0.0) e Bundle Version Code (inteiro). O Version Code precisa subir a cada envio, mesmo que seja só um teste.

A Unity 6.3 também gera bibliotecas nativas compatíveis com aparelhos de página de memória de 16 KB, introduzida no Android 15. Se você usa plugin com arquivo .so próprio (SDK de anúncio, analytics), o Editor avisa no build quando a biblioteca está alinhada em 4 KB. Atualize o plugin antes de enviar.

Build Profile de Android

Abra File > Build Profiles, selecione Android e clique em Switch Platform se ainda não estiver ativo. Depois:

1. Marque Build App Bundle (Google Play).
2. Desmarque Development Build (build de desenvolvimento não deve ir para produção).
3. Em Debug Symbols, escolha Public e, em Symbols output options, a opção que gera o .zip. Esse arquivo de símbolos você envia ao Play Console para os relatórios de crash mostrarem nomes de função em vez de endereço.
4. Clique em Build e salve o .aab.

Se você prefere configurar pelo código (útil em CI), o ajuste de target fica assim. Arquivo Assets/Editor/AndroidReleaseSettings.cs:

using UnityEditor;
using UnityEditor.Build;

public static class AndroidReleaseSettings
{
    [MenuItem("Tools/Android/Aplicar configuração de release")]
    public static void Apply()
    {
        PlayerSettings.SetScriptingBackend(NamedBuildTarget.Android, ScriptingImplementation.IL2CPP);
        PlayerSettings.Android.targetArchitectures = AndroidArchitecture.ARM64;
        PlayerSettings.Android.minSdkVersion = AndroidSdkVersions.AndroidApiLevel25;
        PlayerSettings.Android.targetSdkVersion = AndroidSdkVersions.AndroidApiLevel36;
        EditorUserBuildSettings.buildAppBundle = true;
        PlayerSettings.Android.bundleVersionCode += 1;
    }
}

O script fica numa pasta Editor porque usa UnityEditor. Ele aparece em Tools > Android e incrementa o Version Code a cada clique, o que evita o erro clássico de "Version code já usado".

Publicar jogo Unity na Play Store: Play Console passo a passo

Com o AAB na mão:

1. No Play Console, clique em Criar app. Preencha nome, idioma padrão (Português, Brasil), marque Jogo e Gratuito ou Pago. Atenção: um app publicado como gratuito não pode virar pago depois.
2. Aceite as declarações de política e de leis de exportação.
3. O painel mostra a lista Configure seu app. Ela inclui acesso ao app, anúncios, classificação de conteúdo, público-alvo, segurança dos dados e política de privacidade. Preencha tudo; a liberação da faixa de produção depende disso.
4. Vá em Testar e lançar > Teste > Teste interno, crie uma versão e envie o .aab. O teste interno sai em minutos e é o melhor lugar para descobrir que o build tem problema.
5. Envie também o .zip de símbolos nativos na mesma versão (opção de enviar arquivo de depuração).
6. Adicione seu e-mail na lista de testadores, abra o link de participação no celular e instale pela loja.

Instalar pela loja, e não pelo cabo, testa o fluxo real: o APK que o Google gerou a partir do AAB, assinado pela chave dele.

O jogo rodando no teste interno é o ponto em que muita gente percebe o tamanho do que falta. Não é a loja: é o jogo inteiro estar redondo, com menu, salvamento, áudio, controles de toque e desempenho estável em celular simples. Juntar tudo isso num projeto só, sem alguém para revisar, é onde o desenvolvedor sozinho costuma parar.

Teste fechado e requisitos de conta nova

Aqui está a regra que mais pega gente de surpresa. Segundo a central de ajuda do Play Console, contas de desenvolvedor pessoais criadas recentemente precisam rodar um teste fechado com no mínimo 12 testadores inscritos continuamente por pelo menos 14 dias antes de pedir acesso à produção. Testador que sai antes dos 14 dias, ou que sai e volta, não conta para o período contínuo.

Como fazer isso sem sofrer:

• Crie a faixa em Teste > Teste fechado e uma lista de e-mails com 15 ou mais pessoas. Doze é o mínimo; uma margem cobre quem desiste.
• Mande o link de participação com instrução curta: aceitar o convite, instalar pela Play Store e não sair do teste.
• Atualize o build durante esses 14 dias. O Google pergunta, ao pedir produção, o que você aprendeu com o teste e o que mudou. Responder com mudanças reais ajuda.
• Depois dos 14 dias, o botão Solicitar acesso à produção fica disponível no painel.

Contas de organização não têm essa exigência, mas o teste fechado continua sendo boa prática.

Ficha da loja e classificação

Em Expandir > Página principal da loja (ou Presença na loja, conforme o idioma do painel):

• Nome do app: até 30 caracteres.
• Descrição curta: até 80 caracteres, a frase que aparece na busca.
• Descrição completa: até 4.000 caracteres.
• Ícone 512 x 512 px PNG, imagem de destaque 1024 x 500 px e capturas de tela (jogos precisam de pelo menos algumas em paisagem ou retrato conforme a orientação do jogo).

A classificação de conteúdo é um questionário IARC: violência, linguagem, compras, interação entre usuários. Responda com honestidade; a classificação sai na hora e aparece na loja. Se o jogo mira crianças, a seção Público-alvo ativa regras extras para anúncios e coleta de dados.

Ficha de loja boa é trabalho de ASO, e não cabe aqui inteiro. O post sobre ASO para Play Store e App Store mostra como escolher palavras-chave e montar as capturas.

Erros comuns de rejeição

• "Your app currently targets API level X": o Target API Level está abaixo do exigido. Ajuste para API 36 em Player Settings e gere de novo.
• "Version code X has already been used": suba o Bundle Version Code. Vale até para build que nunca saiu do teste interno.
• "The Android App Bundle was not signed" ou assinado com chave de debug: você gerou sem preencher a keystore em Publishing Settings. Reabra o projeto, digite as senhas, gere de novo.
• "You uploaded an APK or Android App Bundle that was signed in debug mode": mesmo problema, desmarque Development Build.
• Requisito de 64 bits: Scripting Backend ainda em Mono ou ARM64 desmarcado.
• Política de privacidade ausente ou quebrada: a URL precisa abrir e falar do seu app, não ser um modelo genérico.
• Declaração de segurança dos dados incompatível com o SDK: se você usa SDK de anúncio ou analytics, ele coleta identificador do aparelho. Declare. O Google compara a declaração com o que os SDKs fazem.
• Permissões que o jogo não usa: plugins às vezes adicionam permissões ao manifesto. Abra o AAB no Play Console (Explorador de pacotes de apps) e confira.

Próximo passo

Publique primeiro no teste interno mesmo que o jogo não esteja pronto. Ter o caminho completo funcionando (keystore, AAB, ficha, instalação pela loja) tira o medo do lançamento e revela problema de configuração cedo. Depois rode o teste fechado com gente de verdade e use esses 14 dias para polir.

Para entender o que muda quando o mesmo jogo vai para iPhone e como planejar monetização e soft launch, leia o guia de publicar jogos mobile no Google Play e na App Store.