{"url":"https://www.spartanti.com.br/blog/como-publicar-aplicativo-na-google-play","titulo":"Como publicar um aplicativo na Google Play: guia completo","resumo":"Conta de desenvolvedor, chave de upload, ficha da loja, Segurança dos Dados, testes e revisão: o roteiro completo de quem já publicou aplicativos na Google Play.","categoria":"Aplicativos","publicado_em":"2026-10-26","atualizado_em":"2026-10-26","autor":"Spartan TI","markdown":"Publicar um aplicativo na Google Play parece uma etapa administrativa, daquelas que se resolvem numa tarde depois que o aplicativo está pronto. Não é. É um processo com decisões irreversíveis, formulários que travam o lançamento quando respondidos de qualquer jeito e uma revisão humana que pode devolver o seu envio por um detalhe de texto. Quem já passou por isso sabe: o aplicativo fica pronto numa semana e leva três para entrar na loja.\n\nEste é o roteiro de quem já publicou. Ele segue a ordem em que as coisas realmente precisam acontecer — e avisa, em cada etapa, onde está o erro que custa caro. A boa notícia é que nenhuma dessas etapas é difícil. Elas só não perdoam improviso.\n\n## Antes de tudo: a conta de desenvolvedor\n\nNada acontece sem uma conta no Google Play Console, o painel de onde você envia, acompanha e atualiza o aplicativo. Criar a conta envolve três coisas: escolher o tipo de conta, pagar uma taxa única de cadastro e passar por uma verificação de identidade.\n\n### Pessoa física ou organização\n\nEssa é a primeira decisão e a mais mal compreendida. Uma conta **pessoal** é registrada no nome de uma pessoa, e é o nome dela — ou o nome que ela escolher como desenvolvedor — que aparece na ficha da loja. Uma conta de **organização** é registrada no nome de uma empresa, com CNPJ, e exige comprovação de que a empresa existe e de que você pode agir por ela.\n\nO que muda na prática:\n\n  - **Credibilidade na ficha.** Para um aplicativo que pede dados de clientes, ver o nome da empresa no lugar do nome de uma pessoa muda a percepção de quem instala;\n\n  - **Exigências para contas novas.** Contas pessoais criadas recentemente passam por requisitos adicionais antes de poder publicar em produção, incluindo um período de teste fechado com um grupo mínimo de testadores reais. Contas de organização verificadas não entram nessa régua;\n\n  - **Documentação.** A conta de organização pode exigir um identificador de empresa reconhecido internacionalmente, além dos documentos do CNPJ. Separe isso antes, porque é a parte mais lenta;\n\n  - **Continuidade.** Conta no nome de um sócio ou de um funcionário vira problema no dia em que essa pessoa sai. Transferir aplicativo entre contas é possível, mas é burocrático.\n\nSe o aplicativo é de uma empresa, abra a conta como organização desde o começo. O retrabalho de migrar depois é muito maior que a papelada inicial.\n\n### A taxa de cadastro e a verificação\n\nO Google cobra uma **taxa única de cadastro** para abrir a conta de desenvolvedor — paga uma vez, não é anual. O valor é divulgado na própria página de inscrição do Google Play Console e pode mudar; confira lá o número atual em vez de confiar em qualquer artigo, inclusive este. O que não muda é a natureza da cobrança: é um cadastro, não uma assinatura.\n\nDepois do pagamento vem a **verificação de identidade**: documento com foto, endereço e, no caso de organização, os documentos da empresa. Reserve alguns dias. Já vi lançamento atrasar duas semanas porque o comprovante de endereço estava com o nome antigo da rua.\n\nAbra e verifique a conta de desenvolvedor no *começo* do projeto, não no fim. A verificação roda em paralelo com o desenvolvimento e, quando o aplicativo ficar pronto, você não perde dias esperando um e-mail do Google.\n\n## Criar o aplicativo na Console\n\nCom a conta aprovada, criar o aplicativo é rápido: nome, idioma padrão, se é aplicativo ou jogo, se é gratuito ou pago. Dois detalhes merecem atenção.\n\nO primeiro: **gratuito não vira pago depois**. Um aplicativo publicado como gratuito pode receber compras internas e assinaturas, mas não pode passar a ter preço de instalação. Se há dúvida sobre o modelo de receita, vale decidir isso antes — e o assunto tem sutilezas que valem um texto próprio, que você encontra em [como monetizar um aplicativo](https://www.spartanti.com.br/blog/como-monetizar-um-aplicativo).\n\nO segundo: a escolha entre aplicativo e jogo muda as categorias disponíveis, o formato da ficha e até os formulários que você vai responder depois.\n\n### O nome do pacote — o erro clássico\n\nO pacote (ou `applicationId`) é o identificador único do aplicativo no Android, no formato de domínio invertido: algo como `br.com.suaempresa.seuapp`. Ele aparece no endereço da ficha na loja e é por ele que o Android distingue o seu aplicativo de todos os outros.\n\n**Esse identificador é imutável.** Depois que você envia o primeiro arquivo para a Console com um determinado pacote, ele está casado com aquela ficha para sempre. Não existe renomear. Se você errou, o caminho é criar outro aplicativo, do zero, com outra ficha, outras avaliações e outra contagem de instalações — perdendo tudo o que já tinha.\n\nOs erros que mais vejo:\n\n  - Pacote com `com.example` ou `com.teste` herdado do projeto modelo. Esse, aliás, o Google recusa;\n\n  - Nome do produto escrito errado ou com a grafia antiga da marca;\n\n  - Pacote com o nome de um cliente, numa agência, quando o aplicativo depois vira produto próprio;\n\n  - Confundir o pacote com o *namespace* do código. São campos diferentes na configuração do projeto e podem divergir, o que já derrubou mais de um envio.\n\nDecida o pacote com a calma de quem está escolhendo o domínio da empresa, porque o peso é o mesmo.\n\n*Imagem: Sequência de sete etapas: criar e verificar a conta de desenvolvedor, criar o app na Console, definir o nome do pacote, configurar a assinatura e a chave de upload, montar a ficha da loja, responder classificação e Segurança dos Dados, rodar os testes e enviar para revisão — A ordem importa: pacote e assinatura são decisões praticamente definitivas e vêm antes da ficha da loja.*\n\n## Assinatura do aplicativo e a chave de upload\n\nTodo aplicativo Android é assinado digitalmente. A assinatura é o que prova que a atualização que chega ao celular do usuário veio de quem publicou a versão anterior. Se a chave não bate, o Android simplesmente não instala a atualização.\n\nHoje o normal é usar a **assinatura de aplicativo pela Play**: você guarda uma *chave de upload*, usada só para enviar arquivos à Console, e o Google guarda a chave de assinatura final com que distribui o aplicativo. É um arranjo bom, porque a chave que de fato chega aos celulares fica num cofre do Google, e a sua chave de upload pode ser substituída com a ajuda do suporte se for perdida.\n\nMesmo assim, trate a chave de upload como um documento de valor:\n\n  - Guarde o arquivo da chave **e a senha** em dois lugares diferentes, sendo um deles fora do seu computador;\n\n  - Teste o backup. Chave que ninguém nunca tentou usar não é backup, é esperança;\n\n  - Se o aplicativo foi feito por terceiros, exija a chave na entrega. Aplicativo cuja chave ficou com o fornecedor antigo é aplicativo que você não consegue mais atualizar sem negociar;\n\n  - Nunca mande a chave por aplicativo de mensagem ou e-mail sem proteção.\n\nPerder a chave não é um contratempo: em aplicativos antigos, que assinam direto sem a assinatura pela Play, é o fim da linha daquela ficha. Você publica outra, com outro pacote, e pede a todos os usuários que instalem de novo.\n\n## A ficha da loja: o que o cliente vê\n\nA ficha é a sua página de vendas dentro da Play. Ela decide se quem chegou instala. E, diferente do que muita gente imagina, ela também pesa na descoberta — o buscador da loja lê o título e as descrições.\n\n| Elemento | Limite | O que funciona |\n| --- | --- | --- |\n| Título | 30 caracteres | Nome + o que resolve, sem encher de palavra-chave |\n| Descrição curta | 80 caracteres | A frase que aparece primeiro: benefício direto |\n| Descrição completa | 4.000 caracteres | Para quem é, o que faz, o que precisa de conta ou internet |\n| Ícone | 512 x 512 | Legível em miniatura; sem texto pequeno |\n| Capturas de tela | mínimo 2 por formato | Telas reais com uma legenda curta em cada |\n| Gráfico de destaque | 1.024 x 500 | Obrigatório; é a arte usada nas vitrines da loja |\n\nAlgumas regras que evitam recusa: nada de \"melhor aplicativo do Brasil\" ou \"número 1\" sem prova; nada de emoji nem de \"GRÁTIS\" no título; nada de capturas que mostram telas que o aplicativo não tem. E o ícone não pode imitar o de outra marca, nem usar o símbolo de outra empresa.\n\nSe você já cuidou de um site, o raciocínio é o mesmo de uma boa página de conversão — e vale reler o que falamos em [site que converte em clientes](https://www.spartanti.com.br/blog/site-que-converte-em-clientes). A diferença é que, na loja, você tem 80 caracteres para convencer.\n\n### Capturas que vendem\n\nCapturas de tela cruas, direto do emulador, convertem pouco. O que funciona é montar cada captura como um cartaz: a tela real do aplicativo, com um título curto em cima dizendo o que aquela tela resolve. Quatro ou cinco capturas, na ordem em que o usuário viveria o aplicativo, contam uma história. Vinte capturas de menus não contam nada.\n\n## Os formulários obrigatórios\n\nEsta é a parte que mais atrasa lançamento, porque é a parte que ninguém planeja.\n\n### Classificação indicativa\n\nVocê responde a um questionário sobre violência, conteúdo sexual, linguagem, jogos de azar e consumo de substâncias, e a classificação sai automaticamente. Responda com honestidade literal: se o aplicativo tem um bate-papo entre usuários, isso é conteúdo gerado por usuário e muda a classificação. Classificação declarada abaixo da realidade é motivo de remoção depois, não só de recusa.\n\n### Política de privacidade — obrigatória\n\nTodo aplicativo precisa de um endereço público com a política de privacidade, mesmo que ele não colete nada. A política precisa estar no ar, acessível sem login, e dizer o que o aplicativo coleta, para quê, com quem compartilha e como o usuário pede exclusão. No Brasil, ela também precisa conversar com a LGPD — tema que destrinchamos em [LGPD para pequenas empresas](https://www.spartanti.com.br/blog/lgpd-para-pequenas-empresas).\n\nPolítica copiada de outro aplicativo é um problema duplo: ela descreve coletas que você não faz e omite as que faz. O Google compara o que a política diz com o que o aplicativo pede.\n\n### Formulário de Segurança dos Dados\n\nAqui você declara, item por item, quais dados o aplicativo coleta, se são enviados para fora do aparelho, se são criptografados em trânsito, se o usuário pode pedir exclusão e se há compartilhamento com terceiros. O resultado vira aquele quadro de segurança que aparece na ficha da loja.\n\nO ponto que pega as pessoas: **bibliotecas de terceiros contam**. Se você usa uma plataforma de anúncios, de análise de uso ou de notificações, os dados que ela coleta são dados que o seu aplicativo coleta, e precisam estar declarados. Levante isso com quem desenvolveu antes de responder. Declaração inconsistente é uma das causas mais comuns de suspensão de aplicativo já publicado.\n\nOs três formulários — classificação, privacidade e Segurança dos Dados — dependem de informação técnica que só quem escreveu o código tem. Peça essa lista junto com a entrega do aplicativo, por escrito. É o item que mais trava publicação de aplicativo feito por fornecedor.\n\n## Testes antes da produção\n\nA Console oferece trilhas de distribuição em camadas, e usá-las não é frescura:\n\n  - **Teste interno:** até cem pessoas da sua lista, liberação em minutos. É aqui que você descobre que o aplicativo instalado pela loja se comporta diferente do que rodava no cabo USB;\n\n  - **Teste fechado:** grupos convidados por e-mail ou por link. Para contas pessoais novas, essa etapa é requisito para liberar produção, com um número mínimo de testadores participando por um período contínuo;\n\n  - **Teste aberto:** qualquer pessoa entra pela própria loja. Bom para medir instalação e desinstalação com público real;\n\n  - **Produção:** todo mundo. Pode ser liberado em etapas, para uma fração dos usuários primeiro.\n\nRodar teste interno antes de produção pega três classes de defeito que não aparecem em desenvolvimento: permissão que o aplicativo pede e trava quando negada, código compactado para publicação que quebra uma tela, e integração que só funcionava com o servidor de testes. Em jogos, dá para ver também se os anúncios aparecem no lugar certo.\n\nSim, dá trabalho. Mas liberar atualização direto em produção para uma base instalada é jogar com a nota da loja — e nota caída não se recupera rápido.\n\n## Revisão, prazos e o que esperar\n\nTodo envio passa por revisão, automática e humana. O tempo varia muito: pode ser algumas horas e pode ser vários dias, mais ainda no primeiro envio de uma conta nova, em aplicativos que lidam com dinheiro, saúde ou dados sensíveis, e em períodos de pico.\n\nPlaneje com folga. Lançamento amarrado a uma data de campanha precisa de margem de ao menos duas semanas entre o aplicativo pronto e o aplicativo no ar. Essa disciplina de prazo é a mesma que recomendamos em [quanto custa desenvolver um aplicativo](https://www.spartanti.com.br/blog/quanto-custa-desenvolver-um-aplicativo): a publicação é parte do projeto, não um apêndice.\n\n### Motivos comuns de recusa\n\n  - **Política de privacidade ausente, fora do ar ou que não corresponde ao aplicativo;**\n\n  - **Segurança dos Dados incompleta**, normalmente por causa de biblioteca de terceiros não declarada;\n\n  - **Permissão sensível sem justificativa**: localização em segundo plano, envio de SMS, acesso a todos os arquivos ou à lista de aplicativos instalados exigem explicação de uso e, em alguns casos, formulário próprio;\n\n  - **Ficha enganosa**: capturas que não são do aplicativo, funcionalidade prometida que não existe, texto com promessa exagerada;\n\n  - **Marca de terceiros** no nome, no ícone ou nas capturas sem autorização;\n\n  - **Aplicativo que é só um site embrulhado**, sem nada além do que o site já faz — se esse é o caso, talvez o caminho certo seja outro, e vale comparar as opções em [app nativo, PWA ou site responsivo](https://www.spartanti.com.br/blog/app-nativo-pwa-ou-site-responsivo);\n\n  - **Conteúdo de usuário sem moderação nem canal de denúncia;**\n\n  - **Versão alvo do Android antiga demais.** O Google sobe esse piso todo ano e aplicativos que não acompanham param de aceitar atualização e deixam de aparecer para aparelhos novos.\n\nRecusa quase sempre vem com o motivo e com o trecho da política violada. Corrigir e reenviar é normal; o que não é normal é reenviar sem entender o motivo, porque reincidência pesa na conta, não só no envio.\n\n## Depois da publicação\n\nNo ar, o trabalho muda de natureza. Três rotinas que valem a pena:\n\n  - **Olhar os relatórios de travamento** toda semana. A Console mostra em qual aparelho e em qual tela o aplicativo quebrou;\n\n  - **Responder avaliações**, principalmente as ruins. Resposta pública muda a leitura de quem está decidindo instalar;\n\n  - **Atualizar com previsibilidade.** Aplicativo sem atualização há dois anos parece abandonado — e, com a elevação anual da versão mínima do Android, um dia para de ser aceito. É a mesma lógica de [manutenção de site](https://www.spartanti.com.br/blog/manutencao-de-site-importancia): o que não é cuidado degrada sozinho.\n\nNa Spartan TI temos aplicativos e jogos publicados na Google Play — ZeroSpam, Life Guard, Eletropostos Brasil, Grid Rush e Anubis Temple Tracker — e cada um deles passou exatamente por essas etapas, com pelo menos um reenvio pelo caminho. Vale lembrar, por fim, que nem todo problema de empresa se resolve com aplicativo na loja: às vezes o que falta é um sistema para a operação, e a comparação está em [sistema sob medida ou software pronto](https://www.spartanti.com.br/blog/sistema-sob-medida-ou-pronto). Se quiser ver o que já construímos, há exemplos no [portfólio](https://www.spartanti.com.br/portfolio); se preferir discutir o seu caso, [fale com a gente](https://www.spartanti.com.br/#contact).\n\n## Perguntas frequentes\n\n### Quanto custa publicar um aplicativo na Google Play?\n\nExiste uma taxa única de cadastro da conta de desenvolvedor, paga uma só vez, e não há mensalidade pela conta nem cobrança por aplicativo publicado. O valor atual está na página de inscrição do Google Play Console, e é lá que você deve conferir. O que costuma pesar no orçamento não é essa taxa: é o desenvolvimento, a arte da ficha e a manutenção das atualizações.\n\n### Preciso de CNPJ para publicar um aplicativo?\n\nNão. É possível publicar com uma conta pessoal, no nome de uma pessoa física. Mas contas pessoais novas passam por exigências adicionais antes de liberar produção, incluindo um teste fechado com um número mínimo de testadores, e é o nome da pessoa que aparece como desenvolvedor na loja. Para aplicativo de empresa, a conta de organização é mais segura e mais estável no longo prazo.\n\n### Quanto tempo o Google leva para aprovar?\n\nVaria de algumas horas a vários dias. O primeiro envio de uma conta nova demora mais, e aplicativos que lidam com dados sensíveis, saúde ou pagamentos tendem a passar por análise mais longa. Trabalhe sempre com uma margem de duas semanas entre o aplicativo pronto e a data em que ele precisa estar no ar.\n\n### O que acontece se eu perder a chave de assinatura?\n\nSe o aplicativo usa a assinatura de aplicativo pela Play, você perdeu apenas a chave de upload e é possível pedir a substituição dela ao suporte do Google, sem afetar os usuários. Se o aplicativo é antigo e assina direto com a sua própria chave, não há como publicar atualização: a saída é criar outra ficha, com outro pacote, e pedir aos usuários que instalem o novo aplicativo.\n\n### Posso mudar o nome do pacote depois de publicar?\n\nNão. O nome do pacote é definitivo a partir do primeiro arquivo enviado para aquela ficha. O nome visível na loja você pode trocar quando quiser, mas o identificador técnico não. Por isso ele precisa ser decidido com calma, antes do primeiro envio, e nunca ficar com um valor de exemplo herdado do projeto modelo.\n\n### Meu aplicativo foi recusado. E agora?\n\nLeia a notificação até o fim: ela aponta a política violada e normalmente o trecho exato do problema. Corrija a causa, não o sintoma, e reenvie — reenvio é parte normal do processo. Se a recusa parecer equivocada, há um canal de contestação na própria Console, mas reenviar várias vezes sem corrigir nada piora a situação da conta."}