Guia de Publicação de Aplicações e Jogos de Raiz na Google Play Store: Empacotamento, Formulários, Teste Fechado e Lançamento

Guia de Publicação de Aplicações na Google Play Store (De Raiz ao Lançamento)

Este guia explica passo a passo os processos de criação de uma aplicação Android moderna (especialmente projetos .NET MAUI, MonoGame ou híbridos em C#) de raiz na Google Play Console, empacotamento, assinatura digital, resolução de erros críticos e cumprimento de todas as etapas de submissão na loja (criação da app, política de privacidade, permissões de acesso e início de sessão, anúncios, classificação de conteúdo IARC, segurança dos dados, teste fechado e lançamento público em produção).

---

Índice

1. Introdução e Preparação Arquitetural
2. Criar uma Nova Aplicação / Jogo de Raiz na Play Console (Create App)
   • A. Detalhes da Aplicação (App Details)
   • B. Tipo de Aplicação, Preço e Declarações
3. Criação do Keystore e Automação de Build/Assinatura
4. Primeiro Envio do Bundle na Play Console e Erros Críticos
   • Erro 1: Nível de API de Destino 36 (Android 16) Obrigatório
   • Erro 2: Aviso de Código de Versão Significativamente Superior
5. Preparação da Política de Privacidade
6. Acesso à Aplicação / Detalhes de Início de Sessão
7. Declaração de Anúncios
8. Classificação de Conteúdo (Questionário IARC)
9. Público-Alvo e Seleção da Faixa Etária
10. Painel de Conteúdo da Aplicação (App Content Dashboard)
11. Formulário de Segurança dos Dados (Data Safety)
12. Declarações Legais e Regulamentares (Governo, Serviços Financeiros, Saúde)
13. Definições da Loja e Informações de Contacto
14. Ficha Principal da Loja e Elementos Visuais
15. Configuração e Revisão do Teste Fechado
16. Declaração do ID de Publicidade (Advertising ID)
17. Submissão Final para Revisão (Final Submission)
18. Candidatura ao Acesso de Produção Após o Teste Fechado
19. Vitória Final: Aprovação de Acesso à Produção (Production Access)
20. Lista de Controlo Pré-Lançamento (Concluída)
21. Arar Games e os Nossos Jogos

---

1. Introdução e Preparação Arquitetural

Ao publicar uma nova aplicação na Google Play Store, as diretrizes técnicas e de segurança mais recentes da Google devem ser rigorosamente seguidas:

• Formato do Pacote: Apenas o formato .aab (Android App Bundle) é aceite. Ficheiros APK já não são válidos para publicação oficial na loja (embora possam ser gerados para testes manuais diretos).
• Target SDK Mínimo: A Google Play exige agora que todas as novas aplicações ou atualizações tenham como alvo, no mínimo, o Android API Level 36 (Android 16).
• Assinatura Segura: A aplicação tem de ser assinada com uma chave RSA de 2048 bits compatível com os esquemas v2/v3.

---

2. Criar uma Nova Aplicação / Jogo de Raiz na Play Console (Create App)

Depois de iniciar sessão no painel da Google Play Console (play.google.com/console), o processo de publicação inicia-se clicando no botão azul "Create app" (Criar aplicação) no canto superior direito do ecrã inicial onde constam todas as aplicações. Este formulário define a identidade digital da app na consola, o nome de pacote e a classificação base na loja.

A. Detalhes da Aplicação

1. App Name (Nome da Aplicação):
   • É o nome oficial inicial que será apresentado aos utilizadores na loja.
   • Limitado a um máximo de 30 carateres (Ex: YourAppName).
   • Recomendação: Evite acumulação desnecessária de palavras-chave (keyword stuffing) ou termos promocionais enganosos ("Best", "Free", "#1"); caso contrário, a aplicação poderá ser rejeitada durante a revisão da Google Play.
2. Package Name (Nome do Pacote):
   • Identificador Java/Android exclusivo que distingue a sua aplicação globalmente em todo o ecossistema Android (convenção de domínio invertido, ex: com.suaempresa.nomedaapp).
   • Máximo de 150 carateres.
   • ⚠️ Regra Crítica: Após a criação da app neste ecrã e o envio do primeiro bundle, o nome do pacote nunca mais poderá ser alterado! O ApplicationId (<ApplicationId>com.suaempresa.nomedaapp</ApplicationId>) no ficheiro de projeto deve coincidir exatamente com esta definição.
   • Check availability (Verificar disponibilidade): Ao carregar no botão, o sistema verifica de imediato se o nome de pacote pretendido já se encontra registado por outro programador na Google Play.
3. Default Language (Idioma Predefinido):
   • O idioma principal da ficha da loja (Ex: English (United States) – en-US).
   • A informação da loja será apresentada neste idioma predefinido a utilizadores de todos os países onde não tenha sido configurada uma localização específica.

---

B. Tipo de Aplicação, Preço e Declarações

1. App or Game (Aplicação ou Jogo):
   • Define a natureza principal do produto (App ou Game).
   • Nota Crítica: Esta escolha determina a secção principal na loja (separador Aplicações ou separador Jogos) e não pode ser alterada mais tarde.
2. Free or Paid (Gratuita ou Paga):
   • Selecione se a aplicação estará disponível gratuitamente ou se exigirá pagamento prévio para transferência.
   • ⚠️ Regra Crítica Irreversível: De acordo com as políticas da Google Play, uma aplicação publicada inicialmente como "Gratuita" nunca mais poderá ser convertida em "Paga" no futuro! Caso pretenda comercializar o produto diretamente no ato de instalação, selecione Paid desde o início. Para disponibilizar a aplicação gratuitamente e rentabilizá-la, utilize compras integradas (In-App Purchases) ou anúncios AdMob.
3. Automatic Protection (Proteção Automática):
   • A Google Play adiciona uma verificação automática do instalador (installer check) ao código APK/AAB da sua aplicação. Se utilizadores instalarem a aplicação através de fontes externas não autorizadas, verão um aviso solicitando a transferência da versão legítima na Google Play.
4. Declarations (Declarações Legais e Políticas):
   • Developer Program Policies: Confirmação de que a aplicação respeita escrupulosamente as políticas de conteúdo e termos do programador da Google Play.
   • US Export Laws: Confirmação de conformidade com as leis de exportação dos Estados Unidos e sanções internacionais aplicáveis.
5. Create App (Criar Aplicação):
   • Depois de preencher e rever o formulário, clique no botão azul "Create app" no canto inferior direito. A consola regista a aplicação e encaminha-o para o painel de controlo principal (Dashboard).

---

3. Criação do Keystore e Automação de Build/Assinatura

Para tornar o processo de geração e publicação repetível e imune a erros operacionais, recomenda-se a criação de uma pasta Deploy/ com scripts de automação na raiz do projeto.

A. Geração do Keystore (1_CreateKeystore.bat)

Com recurso ao utilitário keytool do JDK, gera-se uma chave válida durante 25 anos (10.000 dias):

keytool -genkeypair -v ^
    -keystore "%KEYSTORE_PATH%" ^
    -alias %ALIAS% ^
    -keyalg RSA ^
    -keysize 2048 ^
    -validity 10000 ^
    -storepass "%PASS%" ^
    -keypass "%PASS%" ^
    -dname "CN=SirketAdi, OU=Apps, O=SirketAdi, C=TR"

Sugestão: A utilização de blocos if (...) com parêntesis na leitura de palavras-passe com set /p em ficheiros batch (.bat) no Windows pode provocar erros de sintaxe (: was unexpected at this time). Controlar o fluxo através de etiquetas goto e envolver os parâmetros de palavra-passe em aspas "%PASS%" garante total fiabilidade.

B. Controlo de Versões Automático e Build do AAB Assinado (2_BuildAndSign_AAB.bat)

A Google Play exige que o versionCode aumente estritamente a cada nova submissão. Para gerir esta numeração automaticamente, utiliza-se uma regra baseada na data e na hora:

# Último dígito do ano + Mês + Dia + Hora + Minuto (Ex: 2026-10-06 02:42 -> 610060242)
$vc = (Get-Date).ToString('yy').Substring(1) + (Get-Date).ToString('MMddHHmm')

Comandos de compilação e assinatura digital:

dotnet build "Proje.Android.csproj" -c Release -f net9.0-android /p:AndroidPackageFormat=aab /p:ApplicationVersion=%VERSION_CODE% /p:ApplicationDisplayVersion=%VERSION_NAME%

jarsigner -sigalg SHA256withRSA -digestalg SHA-256 ^
    -keystore "%KEYSTORE%" ^
    -storepass "%PASS%" ^
    -keypass "%PASS%" ^
    -signedjar "%SIGNED_FILE%" ^
    "%AAB_INPUT%" ^
    %ALIAS%

Uma vez terminada a operação, a pasta de destino com o ficheiro empacotado é aberta diretamente no Explorador do Windows através do comando start "" "%OUTPUT%".

---

4. Primeiro Envio do Bundle na Play Console e Erros Críticos

Ao enviar o ficheiro .aab devidamente assinado para o canal de Internal testing (Teste interno) ou Production (Produção) na Google Play Console, poderá deparar-se com o seguinte ecrã de aviso:

Erro 1: Nível de API de Destino 36 (Android 16) Obrigatório

Mensagem de Erro: "Your app currently targets API level 35 and must target at least API level 36 to ensure it is built on the latest APIs optimized for security and performance."

Resolução:

Trata-se de um erro impeditivo; a publicação não avançará enquanto a definição não for atualizada.

1. Declare explicitamente o elemento <uses-sdk> no ficheiro Platforms/Android/AndroidManifest.xml:

   <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.yourcompany.appname">
       <uses-sdk android:minSdkVersion="24" android:targetSdkVersion="36" />
       ...
   </manifest>

2. Adicione a propriedade no <PropertyGroup> do ficheiro de projeto .csproj:

   <AndroidTargetSdkVersion>36</AndroidTargetSdkVersion>

Erro 2: Aviso de Código de Versão Significativamente Superior

Mensagem de Aviso:
"This release's version code is significantly higher than your previous version code. Over time, this will result in your app reaching the maximum limit for version codes... Learn more"

Resolução:

• A Google Play emite este alerta quando o código de versão anterior do projeto era um valor reduzido (como 1 ou 8) e se transita para o formato dinâmico baseado em data (na ordem das centenas de milhões).
• Este aviso não bloqueia a submissão. Pode ser ultrapassado clicando na hiperligação azul Proceed anyway (Continuar mesmo assim) imediatamente abaixo do alerta.
• Uma vez que este valor servirá de referência para os envios futuros, o alerta de salto acentuado não voltará a manifestar-se.

---

5. Preparação da Política de Privacidade

De acordo com os regulamentos da Google Play, mesmo que a sua aplicação não recolha dados confidenciais do utilizador, é obrigatório disponibilizar uma ligação para a Política de Privacidade numa página web acessível publicamente (e não num ficheiro PDF), protegida por SSL ativo (HTTPS).

Alojamento Gratuito no GitHub

Um ficheiro markdown (blob/main/...) alojado num repositório público do GitHub é reconhecido diretamente pela Google como uma página web legítima.

Secções Fundamentais que Devem Constar da Política

1. Publicidade (Google AdMob): Banners, anúncios intersticiais e recompensados; tratamento do Identificador de Publicidade da Android (AD_ID), especificações de hardware e localização por IP aproximada.
2. Compras na Aplicação e Subscrições (Google Play Billing): Pagamentos processados na totalidade pela infraestrutura da Google, nunca tendo o programador acesso aos dados de cartões ou faturação.
3. Métricas e Telemetria (Firebase Analytics & Crashlytics): Eventos de utilização anónimos e relatórios de instabilidade/erros.
4. Gestão de Consentimento (Google UMP): Ecrãs de consentimento em conformidade com o RGPD (GDPR) e salvaguarda do direito do utilizador a alterar as suas preferências nas opções.
5. Declarações Legais e Isenções de Responsabilidade (Ex: Jogos de Apostas / Ferramentas Analíticas):
   • A aplicação não constitui uma plataforma de jogos de fortuna e azar nem permite efetuar apostas diretas.
   • Fornece exclusivamente otimização matemática de combinações e assistência estatística.
   • Nos redirecionamentos para operadores licenciados, as credenciais de acesso nunca são interceptadas nem armazenadas, decorrendo as validações de segurança (2FA/SMS) diretamente nas plataformas das entidades oficiais.
6. Nota de Segurança: Hiperligações pessoais (como o perfil particular do programador no GitHub) não devem figurar na política; apresente unicamente o correio eletrónico corporativo e o sítio web institucional.

---

6. Acesso à Aplicação / Detalhes de Início de Sessão

Antes da revisão técnica pelos auditores da Google, deve declarar se a aplicação possui zonas reservadas ou protegidas por autenticação:

• Seleção: No (Nenhuma secção da aplicação possui acesso restrito).
• Explicação: Se a aplicação não solicitar registo, início de sessão com utilizador/palavra-passe ou ecrãs bloqueados, escolha No. Caso assinale 'Yes', a Google exigirá credenciais de teste válidas para efetuar a auditoria.

---

7. Declaração de Anúncios

Etapa destinada a declarar a presença ou ausência de publicidade na aplicação:

• Seleção: Yes, my app contains ads (Sim, a minha aplicação contém anúncios).
• Explicação: Se a aplicação integrar o SDK da AdMob ou se previr a ativação de publicidade futuramente, selecione 'Yes'. Esta indicação ativa a menção "Contém anúncios" na página da Google Play e cumpre as normas de transparência.

---

8. Classificação de Conteúdo (Questionário IARC)

Para definir a faixa etária recomendada para a aplicação, deve responder ao inquérito oficial da IARC (International Age Rating Coalition).

A. Seleção da Categoria e Endereço Eletrónico

• Categoria: All Other App Types (Todas as outras categorias de aplicações: utilitários, ferramentas e calculadoras que não sejam jogos nem plataformas sociais).
• Correio Eletrónico: Indique o e-mail de contacto de suporte e aceite os termos da IARC.

B. Perguntas do Inquérito (Questionnaire)

Secção 1: Violência e Interação entre Utilizadores

• Downloaded App (Violência, nudez, linguagem imprópria): No
• User Content Sharing (Partilha de mensagens, som ou ficheiros multimédia entre utilizadores): No

Secção 2: Conteúdos e Artigos com Restrição de Idade

• Online Content (Transmissão contínua de áudio/vídeo ou catálogo de comércio eletrónico): No
• Promotion of Age-Restricted Products (Tabaco, bebidas alcoólicas, jogos a dinheiro): No (Absolutamente «No», dado que a aplicação não acolhe apostas)
• Miscellaneous (Partilha de coordenadas GPS precisas): No

Secção 3: Bens Digitais e Funcionalidades Adicionais

• Digital Goods (Transações de bens virtuais): No («No» se não existir faturação na loja ativa; caso exista, escolha «Yes» para obter o distintivo de Compras Digitais)
• Cash Rewards (Atribuição de incentivos financeiros ou vales de compras): No
• Web Browser (Navegador web ou motor de busca): No
• News / Educational (Conteúdo noticioso ou produto pedagógico): No

Ao assinalar «No» a todas estas perguntas, a aplicação obtém o escalão etário mais abrangente a nível global (PEGI 3, ESRB Everyone).

---

9. Público-Alvo e Seleção da Faixa Etária

Durante a definição do público-alvo, é crucial estabelecer se a aplicação se destina ou não a crianças, atendendo ao programa Designed for Families (Política de Família) da Google e à regulamentação COPPA.

Decisão Apropriada: apenas 18 and over (18 anos ou superior)

• Razões para fixar 18+:
  1. Enquadramento Legal: Análise matemática desportiva, probabilidades e apoio a boletins de apostas desportivas destinam-se exclusivamente a um público adulto.
  2. Isenção de Exigências da Política de Família: Ao selecionar faixas etárias abaixo dos 13 anos ou entre 13 e 17, a Google obriga ao recurso exclusivo a redes de anúncios aprovadas para menores, proíbe certos dados telemétricos e impõe um escrutínio consideravelmente mais minucioso.
  3. Concordância com a Política de Privacidade: Mantém uma harmonia a 100% com a declaração expressa "A aplicação destina-se a pessoas com idade igual ou superior a 18 anos".
• Segunda Pergunta (A sua aplicação pode atrair crianças involuntariamente?):
  • Responda No. A interface não recorre a ilustrações infantis, mascotes animadas ou grafismos apelativos a menores.

---

10. Painel de Conteúdo da Aplicação (App Content Dashboard)

A Google Play Console apresenta uma lista de controlo progressiva em Policy and programs -> App content no menu à esquerda, acompanhando o estado de conformidade regulamentar da aplicação.

Os vistos a verde (✓) vão sendo atribuídos à medida que a política de privacidade, acessos, anúncios e classificação de conteúdo são finalizados. As secções seguintes (Segurança dos Dados, Organismos Oficiais, Serviços Financeiros, Saúde) têm de ser validadas sequencialmente.

---

11. Formulário de Segurança dos Dados (Data Safety)

Uma das etapas mais escrutinadas na consola. Tem de divulgar que categorias de informação a sua aplicação e as respetivas bibliotecas recolhem ou partilham com entidades externas.

Pergunta: A sua aplicação recolhe ou partilha algum dos tipos de dados de utilizador obrigatórios?

• Seleção no Lançamento Inicial: No (Não).
• Fundamento Técnico: Como no primeiro pacote .aab submetido as bibliotecas do AdMob ou Firebase ainda não recolhem credenciais de utilizador nem identificadores pessoais diretos, assinalar No permite validar a secção de forma limpa.
• Nota para Versões Futuras: Logo que ative em pleno os SDKs analíticos ou de anúncios, deverá revisitar este formulário e selecionar Yes nos parâmetros "Localização aproximada", "Desempenho da aplicação" e "IDs de dispositivo ou outros identificadores (AD_ID)".

Após examinar a pré-visualização da ficha, grave as alterações.

---

12. Declarações Legais e Regulamentares

A. Aplicações Governamentais (Government Apps)

• Seleção: No (A aplicação não representa um organismo estatal ou governamental).

B. Serviços Financeiros (Financial Features)

• Seleção: Selecione a opção inferior: My app doesn't provide any financial features.
• Confirmação: Na janela modal que surge, confirme que não está obrigado a anexar licenças bancárias ou certificados do setor financeiro:

C. Aplicações de Saúde (Health Apps)

• Seleção: Marque a opção inferior: My app does not have any health features.
• Confirmação: No diálogo modal, ateste a desnecessidade de licenças ou registos médicos regionais:

---

13. Definições da Loja e Informações de Contacto

Configuração do setor de atividade da loja e dos pontos de contacto disponibilizados ao utilizador:

• Categoria da Aplicação: Sports ou Utilities / Tools.
• Etiquetas (Tags): Escolha termos descritivos adequados (Ex: Desporto, Utilitários).
• Dados de Contacto da Ficha da Loja:
  • Endereço de Correio Eletrónico: destek@sirketadi.com (O e-mail de apoio corporativo é de preenchimento obrigatório).
  • Sítio Web Oficial: https://company.com
• Marketing Externo: Mantenha a caixa assinalada de modo a facultar à Google a divulgação da sua aplicação fora do ecossistema Google Play:

---

14. Ficha Principal da Loja e Elementos Visuais

A apresentação da montra é o fator mais preponderante na conversão e na adesão dos utilizadores:

A. Elementos Textuais

• Nome da Aplicação: Até 30 carateres (Ex: 15te15 - Spor Toto Assistant).
• Breve Descrição: Até 80 carateres (Ex: Formula optimization, probability calculation and smart Spor Toto coupon assistant.).
• Descrição Completa: Descrição circunstanciada com funcionalidades, vantagens de cálculo e menções de responsabilidade.

B. Especificações Técnicas dos Recursos Visuais

• Ícone da Aplicação (App Icon): Rigorosamente 512 x 512 px, PNG de 32 bits, tamanho máximo de 1 MB.
• Gráfico de Funcionalidades (Feature Graphic): Rigorosamente 1024 x 500 px, JPG ou PNG de 24 bits, tamanho máximo de 15 MB.
• Capturas de Ecrã para Dispositivos Móveis:
  • Mínimo de 2 e máximo de 8 imagens.
  • Dimensão lateral mínima: 1080 px (Ex: 1080 x 2340 px).
  • Proporção recomendada: 16:9 ou 9:16.

C. Declaração Relativa a Conteúdo Gerado por Inteligência Artificial

• Mesmo que tenha empregue ferramentas de IA na conceção das imagens de promoção, opte por Don't label assets, contanto que as ilustrações não simulem rostos reais de personalidades públicas de forma a induzir em erro.

---

15. Configuração e Revisão do Teste Fechado

Nas contas de programador individuais recentemente criadas na Google Play Console, é estritamente obrigatório concluir a fase de Teste Fechado (Closed Testing) antes de ser facultada a colocação em produção.

A. Submissão de Alterações para Análise (Visão Geral da Publicação)

Ao preencher os dados da loja e os inquéritos obrigatórios, o resumo da publicação indicará as alterações pendentes:

Contudo, para desbloquear o botão "Send changes for review" (Enviar alterações para revisão) no canto superior direito, a aplicação terá de possuir pelo menos uma versão ativa numa linha de teste fechado.

B. Etapas da Execução do Teste Fechado

Existem 3 passos mandatórios para validar o circuito de testes:

1. Selecionar países e regiões (Select countries and regions):

• Marque os territórios onde a aplicação estará acessível em teste (o mundo inteiro por defeito ou regiões selecionadas) e clique em Save no canto inferior direito.

2. Selecionar utilizadores de teste (Select testers):

• No separador Testers, indique uma lista de endereços eletrónicos existente ou configure uma nova.
• Para desbloquear a permissão de lançamento em produção em contas particulares, a Google estipula que pelo menos 20 utilizadores testem a versão ativamente durante 14 dias seguidos. Assegure-se de que dispõe de participantes reais em número suficiente.
• Após associar a lista, carregue em Save changes no canto inferior direito.

3. Criar uma nova versão (Create a new release):

• Concluídas as seleções geográficas e de participantes, o painel indicará "2 of 4 complete".
• Prima o botão azul Create new release no canto superior direito para preparar a publicação do pacote.

• Submeta o ficheiro .aab assinado. Terminada a transferência, a Google analisa os parâmetros do pacote:

• Como é percetível na imagem, o Target SDK: 36 é identificado com sucesso, validando-se a Version: 610060410 e as arquiteturas suportadas.
• Ao avançar com Next, surge uma mensagem de advertência motivada pelo incremento do código de versão:

• Resolução: Carregue na hiperligação azul Proceed anyway imediatamente sob a advertência "This release's version code is significantly higher than your previous version code".
• Suprimido o obstáculo, a versão é registada carregando no botão azul Save no canto inferior direito.

Cumpridos estes procedimentos, regresse à secção Publishing overview e inicie o circuito formal de avaliação através de Send changes for review.

C. Cenário Frequente: Aviso "App not available" na Ligação de Teste

A ocorrência mais comum com que os programadores se deparam ao carregar na ligação de adesão ao teste fechado (play.google.com/apps/testing/com...):

"App not available - A testing version of this app hasn't been published yet or isn't available for this account."

Causas e Ações Corretivas:

1. Em Avaliação (In Review): A ligação não ficará operacional até que os revisores da Google aprovem a compilação submetida. Ficará pronta quando o estado mudar para "Available to testers" na consola.
2. Incompatibilidade da Sessão Google: A conta com sessão iniciada no navegador tem de corresponder com rigor ao endereço de e-mail integrado na lista Testers da consola.
3. Propagação nos Servidores: Mesmo depois do parecer favorável da Google, o processo de replicação do endereço pelos servidores globais pode demorar entre 1 e 2 horas.

D. Adesão ao Programa de Teste (Become a Tester - Opt-in)

Validada a versão e ativa a hiperligação, é disponibilizado o ecrã de adesão formal:

• A página exibe o ícone oficial da app, o nome do estúdio e o texto de convite para a versão de teste.
• Clicando no botão azul Become a tester, a conta passa a ter acesso imediato ao programa.
• A aplicação pode ser transferida diretamente no equipamento Android acedendo à ligação "Download it on Google Play".

---

16. Declaração do ID de Publicidade (Advertising ID)

Para qualquer aplicação direcionada ao Android 13 (API 33) ou superior, a Google Play exige uma declaração formal relativa ao uso do Advertising ID (AD_ID).

Pergunta: A sua aplicação utiliza o ID de publicidade?

A diretriz chave da Google nesta secção:

"If you say that your app uses advertising ID, we will block releases that don't include the com.google.android.gms.permission.AD_ID permission in the manifest file when targeting Android 13."

• Opção 1 (Recomendada): No (Não).
• Como no pacote de teste fechado em apreço as rotinas do AdMob ainda não foram compiladas no código final e não consta a permissão AD_ID no AndroidManifest.xml, selecionar No evita incompatibilidades no manifesto.
• Opção 2 (Se assinalar «Yes»):

• Caso marque Yes, deve indicar [x] Advertising or marketing como justificação e marcar imperativamente a opção "Turn off release errors" no final da página (I understand the ramifications of not including the com.google.android.gms.permission.AD_ID permission...), dado que a permissão não se encontra ainda no manifesto.

Em ambos os caminhos, termine clicando em Save no canto inferior direito.

---

17. Submissão Final para Revisão (Final Submission)

Após regularizar a apresentação da loja, política de privacidade, segurança de dados, declarações legais, escalão etário e pacote de teste fechado, regresse ao ecrã Publishing overview:

• Submit 14 changes for review: A Google Play agrupa os formulários respondidos e o pacote submetido num dossier de revisão consolidado (neste caso, 14 alterações pendentes de auditoria).
• O escrutínio técnico da Google começa oficialmente assim que carrega no botão azul Submit 14 changes for review.
• Testes automatizados de qualidade decorrem em plano de fundo, seguindo-se a análise manual da Google Play Review Team. Em contas individuais, a conclusão demora habitualmente entre 24 e 72 horas.

---

18. Candidatura ao Acesso de Produção Após o Teste Fechado

Cumprido o intervalo de teste fechado (pelo menos 14 dias contínuos com 20 participantes empenhados), o botão "Apply for production" torna-se selecionável no painel principal da Play Console. Ao carregar neste botão, a Google apresenta um inquérito em 3 passos para atestar se a aplicação foi devidamente testada na prática e reúne condições para ser comercializada:

Fases do Questionário:

1. Sobre o seu teste fechado (About your closed test): Como recrutou os utilizadores de teste, de que modo obteve o feedback e quais as correções ou aperfeiçoamentos que implementou com base nas opiniões recolhidas.
2. Sobre a sua aplicação (About your app): Definição do público-alvo e os benefícios nucleares que a ferramenta entrega aos utilizadores.
3. O seu nível de prontidão para produção (Your production readiness): De que forma monitorizará falhas e como pretende responder aos comentários dos clientes na loja.

Perguntas Decisivas e Exemplos Práticos de Resposta

1. "How did you recruit users for your closed testing? For example, did you ask friends and family, or use a paid testing provider?"

Como recrutou os utilizadores para o teste fechado? (Ex: amigos e familiares ou serviço de testes remunerado?)

Norma Crucial: A Google reprova categoricamente a utilização de bots ou redes pagas de testes artificiais. Recomenda-se evidenciar que os participantes constituíram utilizadores reais, conhecidos diretos e entusiastas de comunidades temáticas.

I recruited testers organically through friends, family, and colleagues interested in sports analysis. Additionally, I invited active football prediction fans from targeted social media groups (Reddit & sports communities). No paid services were used; all were real, active users.

2. "How easy was it to recruit testers for your app?"

Qual o grau de facilidade no recrutamento de participantes para a sua aplicação?

• Opção Sugerida: Neither difficult or easy ou Easy. Atesta que a campanha de angariação correu de forma plausível e sem recurso a expedientes automatizados.

3. "Describe the engagement you received from testers during your closed test"

Descreva o nível de envolvimento registado pelos testadores ao longo do teste fechado:
(Recomendação da Google: indique se os participantes experimentaram as diversas funcionalidades e se os padrões observados refletiram o comportamento autêntico de um utilizador real)

Testers actively used all core features: match fixtures, filters, and coupon generation. Their engagement matched real user behavior, logging in regularly around weekly match days to create coupons and review predictions. All tester activity closely mirrored real-world football fan usage.

4. "Provide a summary of the feedback that you received from testers. Include how you collected the feedback."

Apresente uma síntese do feedback comunicado pelos participantes e os métodos empregues na sua recolha:

Feedback was collected via Google Play internal feedback, emails, and tester messaging groups. Testers appreciated the fast coupon generator but suggested improving font readability on small screens, adding clearer filter descriptions, and optimizing fixture loading on slow mobile networks.

---

Passo 2: Sobre a sua aplicação (About your app)

Nesta etapa, esclarece-se o público a que a aplicação se destina, o valor acrescentado e a estimativa de instalações ao longo do primeiro ano:

1. "Who is the intended audience of your app?"

A que público-alvo se dirige a aplicação?

The intended audience includes adult football fans, sports enthusiasts, and Toto players seeking analytical tools to plan predictions. It is designed for users aged 18+ who want structured match fixture insights, mathematical coupon filtering, and systematic statistical analysis.

2. "Describe how your app provides value to users"

Explique a mais-valia que a sua aplicação proporciona aos utilizadores:

The app provides value by automating complex coupon filtering and Toto calculations, saving users substantial time. It offers clean weekly fixture overviews, probability statistics, and intuitive mathematical tools that help sports fans make well-structured, data-informed prediction plans.

3. "How many installs do you expect your app to have in your first year?"

Quantas instalações estima atingir no decorrer do primeiro ano?

• Opção Sugerida: 0 - 10K (Um valor verosímil e sustentado para uma produção indie independente).

---

Passo 3: O seu nível de prontidão para produção (Your production readiness)

A secção de encerramento da candidatura interroga sobre as otimizações introduzidas na sequência dos testes e a fundamentação para a abertura comercial:

1. "What changes did you make to your app based on what you learned during your closed test?"

Que alterações efetuou na aplicação em função dos dados obtidos no teste fechado?

Sugestão: A resposta deve articular-se estritamente com os contributos enunciados nas fases anteriores (adaptação a ecrãs compactos, legibilidade tipográfica, notas de filtro e retenção de dados em memória intermédia).

Based on tester feedback, we adjusted font scaling and spacing for smaller screens, added descriptive labels to filter options, and optimized fixture caching for slower network connections. We also streamlined the coupon generation interface to make navigation smoother and more intuitive.

2. "How did you decide that your app is ready for production?"

De que modo determinou que a sua aplicação estava apta para publicação em produção?

Sugestão: Evidencie as métricas de estabilidade do Android Vitals (ausência de falhas críticas, inexistência de bloqueios ANR), os 14 dias regulares de utilização e a interoperabilidade verificada em diversos dispositivos Android.

We confirmed production readiness through 14 days of closed testing with zero crashes and zero ANRs in Android Vitals. All core workflows (fixture browsing, filtering, and coupon generation) executed smoothly across diverse devices, and testers confirmed high stability and complete features.

Preenchidas todas as declarações, conclua o processo de submissão clicando no botão azul Apply no canto inferior direito.

Confirmação de Submissão (Procedimento de Auditoria)

Ao acionar «Apply», regressa ao painel principal da Play Console, sendo apresentado o estado do pedido no separador Production:

"We have your application for production access"
"We're reviewing your application form. We'll email the account owner with an update. This usually takes 7 days or less, but may occasionally take longer."

Informações a Reter:

1. Prazo de Avaliação: Conquanto a Google mencione formalmente "7 days or less", para candidaturas coerentes e com relatórios técnicos irrepreensíveis, a resposta surge comumente entre 24 e 72 horas.
2. Aviso de Desfecho: Uma vez encerrada a análise, uma comunicação oficial de aceitação é expedida para o titular da conta (consulte a Secção 19).
3. Procedimento Durante a Espera: Não é requerida qualquer ação complementar; a faixa de teste fechado pode permanecer ativa enquanto se aguarda o parecer da Google Play Review Team.

---

19. Vitória Final: Aprovação de Acesso à Produção (Production Access)

Cumprida com sucesso a fase de Teste Fechado (14 dias contínuos com um mínimo de 20 participantes) — o requisito mais exigente para novas contas particulares na Google Play Console — e validado o requerimento de produção, é recebido o e-mail formal de deferimento:

"Congratulations! Your app has been granted Google Play production access"
"You applied for Google Play production access for your app, and this has now been granted. Production is where you make your app available to billions of users on Google Play."

O Que Significa Esta Validação?

1. Publicação Universal: A aplicação adquire elegibilidade para ser instalada por milhares de milhões de utilizadores do Android a nível mundial, transcendendo o grupo restrito de participantes de teste.
2. Superação do Limiar de Auditoria: O critério dos 20 utilizadores durante 14 dias foi integralmente verificado pela Google, elevando a conta à categoria de entidade fidedigna.
3. Publicação com Um Clique: Na secção Production da consola, o pacote devidamente validado na fase de testes fechados pode transitar imediatamente para a montra aberta da loja.

---

20. Lista de Controlo Pré-Lançamento (Concluída)

Relação integral das verificações concluídas:

• O identificador da aplicação e o nome único de pacote foram definidos na Play Console?
• O pacote .aab assinado foi compilado com targetSdkVersion 36?
• O código de versão (versionCode) é superior ao das edições prévias? (Foi assinalado Proceed anyway na notificação?)
• O endereço da Política de Privacidade está operacional e responde em HTTPS?
• O Acesso à Aplicação foi configurado com No?
• A declaração relativa a publicidade foi assinalada como Yes?
• O inquérito de Classificação de Conteúdo IARC foi concluído com certificado emitido?
• O Público-Alvo foi definido com a opção 18 and over?
• O formulário de Segurança dos Dados (Data Safety) foi integralmente preenchido?
• As declarações para Organismos Governamentais, Funções Financeiras e Saúde foram assinaladas com No?
• Os materiais visuais da loja (Ícone 512x512, Imagem em Destaque 1024x500 e Capturas de Ecrã) foram carregados?
• Teste Fechado: a lista de países e regiões foi configurada e gravada?
• Teste Fechado: a lista de participantes de teste foi associada e gravada?
• Teste Fechado: o pacote .aab assinado foi submetido com versão criada?
• ID de Publicidade (Advertising ID): guardado com a opção No para a distribuição inicial?
• Resumo da Publicação: as alterações foram submetidas para aprovação da Google?
• Teste Fechado concluído e Acesso de Produção oficialmente concedido?

---

21. Arar Games e os Nossos Jogos

Pode visitar as páginas dos nossos jogos na loja para conhecer ao vivo as mecânicas, novidades e atualizações desenvolvidas pelo nosso estúdio independente:

🎮 Os Nossos Jogos:

• 🛡️ Blocked: Pixel Panzer:
  Ação retro de tanques em pixel art, projéteis elementais ColorWheel, meteorologia dinâmica, combates contra bosses, tabelas de classificação mundiais e proezas da Google Play!
  👉 Descarregar na Google Play (Android e PC) | Microsoft Store (Windows PC)
• 🎨 Paint Trek:
  Experiência arcade focada em reflexos com píxeis coloridos e atmosfera espacial.
  👉 Google Play | Microsoft Store (PC & Xbox)
• 🚀 Space Dodger:
  Desvio dinâmico de obstáculos retro-arcade nas profundezas do espaço.
  👉 Descarregar na Google Play

📢 Redes Sociais e Comunicação:

Para acompanhar os nossos novos tutoriais técnicos, diários de desenvolvimento e novidades dos jogos:

• 🎵 TikTok: @arargamesstudio
• 📸 Instagram: @arargamesstudio
• 🐦 X (Twitter): @arargamesstudio
• 📺 YouTube: @koreaaria
• 🧵 Threads: @arargamesstudio
• 📘 Facebook: arargamesstudio

---

Elaborado por: Arquivo de Documentação para Programadores da Arar Games