Como preparar uma conta Google Play Console para publicar um app Android no Brasil

Publicar um app Android no Google Play costuma parecer uma tarefa de build: gerar um AAB, preencher uma descrição, subir screenshots e enviar para revisão. Na prática, a parte mais frágil costuma vir antes disso.

Se a conta de desenvolvedor não estiver verificada, se o perfil de pagamentos tiver dados inconsistentes ou se a assinatura do app for registrada com a chave errada, o lançamento pode travar por dias.

Este checklist resume a ordem que usamos na Sunstone Apps para preparar uma conta de organização brasileira antes de enviar um app.

1. Comece pela identidade da conta

Para conta de organização, trate o Play Console como um cadastro jurídico, não como um perfil de marketing.

Confira:

• Nome legal da organização.
• Endereço legal.
• CNPJ.
• E-mail e telefone de contato.
• Conta Google proprietária.
• Documentos oficiais da empresa.

No Brasil, documentos como extrato do CNPJ, contrato social ou certificado de MEI podem entrar no fluxo de verificação. O ponto importante é a correspondência: o nome e o endereço precisam bater com o perfil de pagamentos e com os documentos enviados.

Se houver divergência de endereço entre CNPJ, contrato social e perfil de pagamentos, resolva antes de reenviar documentos.

2. Configure o perfil público do desenvolvedor

O perfil público aparece para usuários e também ajuda a deixar a conta coerente.

Antes de criar o app, deixe pronto:

• Ícone do desenvolvedor em 512x512.
• Imagem de cabeçalho em 4096x2304.
• Site oficial.
• Texto promocional curto.
• E-mail e telefone de desenvolvedor.

Esse perfil deve representar a marca do estúdio, não um app específico. No nosso caso, Sunstone Apps é a marca pública; a razão social continua registrada onde o Google precisa dela.

3. Crie o perfil para pagamentos cedo

Se o app terá compras no app, assinaturas ou qualquer receita via Google Play Billing, não deixe pagamentos para o fim.

O perfil para pagamentos pede informações públicas de comerciante. Alguns campos parecem confusos, como o nome que aparece na fatura do cartão de crédito. Esse nome não é o cartão da empresa; é o texto que o comprador verá na fatura dele depois de uma compra.

Um bom descritor é curto e reconhecível:

Google* SUNSTONE APPS

Depois disso, normalmente ainda existe a validação bancária por microdepósito. Esse passo pode levar alguns dias, então comece antes de depender dele.

4. Entre no programa de taxa de serviço de 15%

Para desenvolvedores pequenos, vale verificar a inscrição na taxa de serviço de 15%.

O programa aplica uma taxa de serviço de 15% ao primeiro US$ 1 milhão de receita anual elegível do grupo de contas. Para entrar, o Google pede que você crie um grupo de contas e declare se existem outras contas de desenvolvedor associadas à mesma pessoa jurídica ou marca.

Se há apenas uma conta Play Developer da empresa, declare isso corretamente. Não crie contas extras para separar apps ou tentar manipular elegibilidade.

5. Não registre a chave errada do app

A verificação de desenvolvedor Android pode pedir a impressão digital SHA-256 do certificado do package name.

Esse valor precisa ser da chave final de assinatura ou da chave de upload que será usada no fluxo real do app. Não use uma fingerprint de debug, nem a fingerprint de um build local temporário.

Antes de registrar a chave, responda:

• O app usará Play App Signing?
• A chave de upload já é estável?
• O build local está assinado com chave real ou debug?
• O package name já é definitivo?

Package name é uma decisão de longo prazo. Depois de publicado, trocar significa outro app.

6. Só então crie o app

Com conta, perfil público, pagamentos e assinatura entendidos, a criação do app fica mais simples.

Para um jogo gratuito com anúncios e compras no app, você ainda vai preencher:

• Categoria e tipo de app.
• Declaração de anúncios.
• Data Safety.
• Classificação etária.
• Ficha da loja.
• Screenshots e feature graphic.
• Produtos Play Billing.
• Faixa de teste interno ou fechado.

O primeiro envio não precisa ter tudo que o roadmap sonha. Ele precisa ser coerente com o que o app realmente faz. Se a Data Safety indicar que o usuário pode pedir exclusão de dados, prefira uma página pública dedicada para esse fluxo, além da política de privacidade.

Checklist final

Antes de subir o AAB, valide:

• Conta de desenvolvedor sem alerta de política.
• Organização verificada.
• Perfil de pagamentos criado.
• Conta bancária verificada ou em validação, conforme necessidade de receita.
• Perfil público do desenvolvedor configurado.
• Grupo de contas criado.
• Taxa de 15% inscrita, se aplicável.
• Package name definitivo.
• SHA-256 registrado apenas com a chave final correta.
• Páginas legais públicas funcionando.
• URL pública de exclusão de dados funcionando, quando declarada na Data Safety.
• E-mail de suporte funcionando.

Esse trabalho não é glamouroso, mas reduz a chance de o lançamento parar por um detalhe administrativo quando o app já estiver pronto.

O que preparar antes de abrir o Play Console

Um primeiro envio mais tranquilo começa antes do primeiro campo no Play Console. Deixe identidade da loja, package name, plano de assinatura, respostas de privacidade e rota de teste em uma nota pequena de release. A intenção não é criar burocracia; é evitar decisões enquanto o console já está pedindo valores difíceis ou lentos de mudar.

Para um app Android indie, o checklist mínimo costuma bastar:

• confirmar o package name Android final antes de subir qualquer build;
• decidir se o Play App Signing vai gerenciar a chave de assinatura;
• deixar e-mail de suporte, nome do desenvolvedor, política de privacidade e termos prontos;
• preparar screenshots e descrição curta antes de subir o binário;
• saber quais países e grupos de teste devem ver o primeiro release.

O maior erro é tratar o Play Console como o lugar onde o release será desenhado. Ele funciona melhor como o lugar onde um release que já existe é registrado.

As partes lentas são revisão e confiança

Quem publica pela primeira vez costuma subestimar o tempo não técnico. O Google pode revisar a conta de desenvolvedor, o conteúdo do app, declarações, respostas de segurança de dados e a própria faixa de teste. Nada disso é difícil isoladamente, mas cada item pode travar o progresso se depender de página legal ausente, política de dados confusa ou build que não foi gerada como release real.

Por isso preferimos uma faixa interna antes de qualquer coisa pública. O teste interno prova que o pacote instala, a página da loja abre, a conta Play está elegível e o binário se comporta como o release que pretendemos enviar. Ele também encontra problemas que uma build debug local esconde, como billing indisponível, diferenças de assinatura e configuração de produção.

Um ritmo prático para o primeiro release

O ritmo mais seguro é entediante: criar o registro do app, subir uma build de release, convidar uma lista mínima de testers, validar instalação e abertura, só então expandir o checklist. Depois disso vale polir a listagem e preparar rollout maior.

Essa sequência mantém o ciclo de feedback pequeno. Se instalação falha, depure instalação. Se billing falha, depure billing. Se a listagem está incompleta, depure conteúdo. Misturar tudo no primeiro envio público faz qualquer falha parecer maior do que é.

A ordem de configuração importa

Algumas tarefas do Play Console parecem independentes, mas ficam mais fáceis em uma ordem específica. Comece por identidade e páginas legais, porque vários formulários posteriores apontam para elas. Depois crie o registro do app e a faixa de teste. Só então vale polir assets da listagem.

Essa ordem evita retrabalho. Uma URL de política de privacidade que muda tarde pode forçar edições na listagem, nas respostas de segurança de dados e na comunicação com testers. Um erro de package name depois de um upload pode ser pior: o registro do app fica preso a ele, e começar de novo pode ser mais barato que tentar contornar um identificador ruim.

Para um primeiro app, a postura mais segura é tratar todo identificador público como permanente até prova em contrário.

Conclusão

Abrir o Play Console não é a parte difícil. Difícil é chegar com identificadores estáveis, páginas legais, pagamentos e um caminho de release que aguente revisão. Trate o primeiro release interno como exercício operacional controlado, não como corrida para preencher formulário.