Tecnisol Ponto — conta de desenvolvedor e publicação no Google Play

Requisitos consultados nas fontes oficiais em 26/10/2026. Este é o procedimento de preparação; nenhuma conta foi criada, taxa paga ou versão enviada ao Google nesta entrega.

Escolha da titularidade

A recomendação para o produto comercial é uma conta de organização vinculada à empresa que será titular do Tecnisol Ponto. Antes do cadastro, os sócios devem definir com o contador se a sociedade usará o CNPJ atual ou outro. Nome comercial, titularidade da conta e direitos sobre o produto precisam representar o acordo real; este guia não determina a estrutura societária.

Como domínio e e-mail ainda serão providenciados, a proposta é usar esse intervalo para decidir a titularidade. Não usar o CNPJ de um dos sócios apenas como atalho para iniciar o cadastro.

Se for necessário começar antes da definição da empresa, a conta pessoal do responsável é uma alternativa a avaliar, usando dados verdadeiros. O Google oferece conversão de pessoal para organização, com site verificado, perfil para pagamentos empresarial, D-U-N-S e verificações adicionais. Não há conversão direta de organização para pessoal. Outra possibilidade é transferir o app entre contas, conforme os requisitos do Google. Conversão de conta, transferência de apps.

O tipo de conta não é escolhido apenas pelo nome que aparecerá na loja. Contas organizacionais exigem dados da entidade; contas pessoais vinculam a identidade do titular. Informações de identificação e contatos são exibidas conforme o tipo de conta e as regras aplicáveis. Dados exigidos pelo Google.

Etapa 1 — preparar a Conta Google e os contatos

1. Escolher a Conta Google que será proprietária do Play Console. Ela pode usar um e-mail corporativo; Google Workspace não é um pré-requisito de publicação. Conta Google com e-mail existente.
2. Ativar a verificação em duas etapas, configurar recuperação e guardar os códigos de recuperação em local seguro.
3. Definir quem administra a conta. Outras pessoas devem receber convites com permissões próprias, em vez de usar a senha do proprietário.
4. Preparar e-mails e telefones reais que possam receber as verificações do Google.

Depois da compra do domínio, a proposta é criar endereços para administração, suporte e comercial, conforme o provedor. Não cadastrar [EMAIL_SUPORTE] ou outros campos genéricos no Console. Um endereço que só será criado no futuro não serve para receber códigos ou atender usuários.

Etapa 2 — preparar a organização, se esse for o caminho escolhido

Separar razão social, endereço e documentos oficiais da entidade e do responsável autorizado. Conferir os dados antes de preencher o perfil para pagamentos.

O D-U-N-S é um identificador empresarial de nove dígitos, distinto do CNPJ. Consultar se a entidade já possui um; se não, solicitar pelo canal indicado pela Dun & Bradstreet. O pedido é gratuito e o Google informa que pode levar até 30 dias. Nome e endereço precisam corresponder aos registros usados na verificação. Requisitos e D-U-N-S.

Preparar um site institucional no domínio da empresa, identificando o negócio e seus contatos. Verificar sua propriedade no Search Console e concluir a associação solicitada pelo Play Console. Usar a identidade institucional definida; o domínio do blog usado temporariamente pela API não representa, por si só, o site da empresa titular. Verificar propriedade no Search Console, verificação do site no fluxo do Play Console.

Etapa 3 — cadastrar e verificar a conta do Play Console

1. Acessar Google Play Console com a conta proprietária.
2. Escolher pessoal ou organização conforme a decisão de titularidade.
3. Preencher identidade, país, contatos e perfil para pagamentos com dados verdadeiros.
4. Revisar e aceitar o contrato de distribuição.
5. Pagar a taxa única de US$ 25 com um meio aceito. O valor final em reais depende da conversão e das condições do cartão; não há valor fixo em reais neste guia.
6. Guardar o recibo e o identificador da transação.
7. Concluir os códigos enviados por e-mail/telefone e os documentos solicitados no Console.
8. Acompanhar a aprovação da verificação antes de tentar a publicação.

O proprietário precisa ter pelo menos 18 anos. O Google aceita determinadas modalidades de cartão de crédito/débito, variáveis por local, e não aceita pré-pagos. A taxa de registro é diferente de cobrança de assinaturas ou vendas do produto. Cadastro e taxa.

Para este objetivo, usar Play Console. O produto separado Android Developer Console atende especialmente à distribuição fora da Play Store; não é preciso abrir duas contas pagas para cumprir o mesmo objetivo. Conferir também as tarefas de identidade/registro do pacote apresentadas no Play Console para a verificação de desenvolvedor Android. Orientação oficial sobre os consoles.

Etapa 4 — cumprir a verificação específica de conta pessoal

Se a conta for pessoal e nova, o Google exige verificar acesso a um aparelho Android real pelo aplicativo Play Console, usando a conta proprietária. O aparelho deve ter Android 10 ou superior e não pode ter root. No Console web, abrir a tarefa de verificação do dispositivo, seguir o QR para o aplicativo Play Console, entrar como proprietário e concluir “Verificar”. Verificação de dispositivo.

Para contas pessoais criadas após 13/11/2023, o acesso à produção exige teste fechado com no mínimo 12 testadores inscritos continuamente por 14 dias consecutivos e solicitação posterior de acesso à produção. É necessário testar de verdade e relatar o processo; o fim do prazo não libera a produção automaticamente. Os dois tablets da operação não substituem esse grupo. Essa regra específica não se aplica às contas de organização. Requisitos de teste.

O teste interno é outra faixa e não conta como substituto desse teste fechado. Ele permite iniciar validações com um grupo menor enquanto se prepara a publicação. Faixas de teste.

Etapa 5 — preparar domínio e migração dos dois tablets

Decisão do responsável em 26/10/2026: aguardar o domínio Tecnisol e os e-mails corporativos; depois reunir os dois tablets, fazer o backup final do ambiente anterior e migrar para operar apenas neste servidor. A instalação do APK de entrega dupla não faz parte desse plano atual.

Antes do corte, a equipe técnica precisa:

• Configurar os endereços definitivos, HTTPS público, painel e API.
• Fazer cópias consistentes e conferir as marcações posteriores ao snapshot já restaurado, incluindo pendências nos dois aparelhos.
• Preparar uma transição explícita de origem para aparelhos já vinculados, preservando identidade, autorização, sequência e fila. Alterar somente a URL padrão da compilação não troca a origem persistida nos tablets.
• Gerar a versão adequada ao destino definitivo, sem ativar o envio adicional temporário ao domínio do blog.
• Atualizar por cima, sem desinstalar, limpar dados ou restaurar o aparelho às configurações de fábrica.
• Confirmar marcações reais previstas, relatórios e pendências nos dois tablets antes de encerrar a operação anterior.

Não executar substituição de banco, reautorização de aparelhos ou corte do servidor anterior apenas para cumprir um item da loja. O procedimento técnico será preparado e validado antes dessa operação. A publicação no Google Play e a migração de servidor são trabalhos distintos.

Etapa 6 — criar o cadastro do app

No Play Console, selecionar Criar app, idioma português do Brasil, tipo aplicativo e nome Tecnisol Ponto. Informar suporte e as declarações solicitadas. A proposta comercial é distribuir o aplicativo sem cobrança pelo download, sujeito à autorização da empresa; confirmar essa escolha antes de salvar a configuração de preço. Download sem custo não significa serviço de RH gratuito.

Manter o pacote br.com.tecnisol.ponto. Não criar outro nome de pacote para contornar pendências da conta. O nome de pacote identifica permanentemente o aplicativo. Criar e configurar o app.

Etapa 7 — preparar o arquivo e preservar a assinatura

Enviar um Android App Bundle, arquivo AAB, de release. O APK serve à instalação direta; não substitui o AAB do cadastro novo. A fonte atual tem versão 0.8.0-piloto, código 13. A próxima versão deve usar um código superior ao maior já distribuído/enviado, após conferir os artefatos existentes.

No Play App Signing, escolher o fluxo para fornecer a chave de assinatura existente, usando PEPK quando solicitado. Preservar o certificado que permite atualizar as instalações dos tablets:

58e757feb837bf5eb4707f715558e7433224d005b9d58ee8e6a8a8716402fc24

Não aceitar uma nova chave independente como substituta sem uma análise específica da continuidade. A chave de upload pode ser separada da chave que assina os aplicativos instalados. Conferir o certificado do APK gerado pelo Google antes da atualização nos aparelhos reais. Chaves e senhas ficam fora do material comercial e do Git. Assinatura de aplicativos.

Usar a faixa Teste interno, não o recurso chamado Compartilhamento interno de apps: esse último reassina os arquivos com um certificado próprio de testes e não atende à continuidade pretendida. Diferença do compartilhamento interno.

Etapa 8 — conferir os requisitos técnicos vigentes

• O projeto define targetSdk = 36 e minSdk = 26 (Android 8.0). Conferir o AAB produzido, além da configuração da fonte.
• Desde 31/08/2026, a regra geral para novos apps e atualizações de celular/tablet exige Android 16/API 36 ou superior. As exceções para outras categorias não são o enquadramento deste app. API exigida.
• Verificar bibliotecas nativas e compatibilidade com páginas de memória de 16 KB; não concluir a compatibilidade só por o código principal ser Kotlin. A página oficial consultada indica bloqueio de atualizações incompatíveis a partir de 01/02/2027. Compatibilidade de 16 KB.
• Executar os testes Android, lint e ensaios físicos de atualização, captura offline, reconexão, pausa, reinício e modo quiosque.
• Testar permissões opcionais e recusa de câmera. A câmera é usada para leitura de QR de ativação, não para ponto facial.

Etapa 9 — preparar página da loja e suporte

Providenciar nome, descrição curta, descrição completa, categoria/tags adequadas, e-mail de suporte, site, ícone de 512×512, imagem de destaque de 1024×500 e capturas exigidas para os dispositivos atendidos. Usar demonstração com dados fictícios, mostrando o comportamento real e as restrições de autorização. Recursos gráficos da loja.

Não declarar que o app é de livre uso individual: o fluxo atual depende de configuração e autorização pela empresa. Não colocar selo “Disponível no Google Play” nas campanhas antes de existir uma publicação acessível ao público pretendido.

Etapa 10 — privacidade e Segurança dos dados

Publicar política específica em [DOMINIO_TECNISOL]/privacidade/app-ponto/, com titular, contatos, finalidades, retenção, atendimento a solicitações e tratamento dos dados. Disponibilizar acesso à política também dentro do app; não foi identificado esse link na interface atual, portanto é uma pendência técnica antes da submissão. Preparar conteúdo para análise.

Preparar o inventário que orientará o formulário Segurança dos dados:

A equipe deve verificar finalidades, obrigatoriedade, destinatários, processamento e exclusão em cada fluxo, incluindo SDKs e registros do servidor. Classificar os tipos usando o formulário vigente. Não marcar “nenhum dado coletado” porque o app é B2B ou não contém anúncios. Criptografia no transporte não equivale a criptografia ponta a ponta de todos os registros. Segurança dos dados.

O app atual é ativado pela empresa e não apresenta criação de conta pessoal dentro dele. Conferir o enquadramento das perguntas de exclusão de conta; se for acrescentada criação de conta no app, a exigência de exclusão correspondente precisa ser atendida. Não prometer apagar silenciosamente históricos de ponto como resposta automática a uma solicitação. Exclusão de conta.

Etapa 11 — disponibilizar acesso para os revisores

Informar em Conteúdo do app → Acesso ao app que há funções restritas. Criar um ambiente separado de demonstração, com pessoas fictícias e instruções reproduzíveis. Explicar servidor, ativação, credencial de teste, marcações, sincronização e saída do quiosque.

O código temporário de ativação atual não é suficiente se expirar durante a revisão. Preparar um meio seguro e repetível de acesso, compatível com as instruções aceitas pelo Google, sem exigir contato com o desenvolvedor para cada tentativa. Não usar um tablet/empresa real do cliente, nem desabilitar a autenticação ou o MFA da produção. Essa preparação ainda precisa ser implementada e testada. Acesso e preparação para revisão.

Etapa 12 — concluir declarações e revisão

Preencher todas as tarefas do painel: classificação indicativa, público-alvo, anúncios, privacidade, Segurança dos dados, acesso restrito e outras declarações que o Console solicitar conforme as funções do app. O código atual não inclui SDK publicitário; confirmar o artefato enviado antes de responder sobre anúncios. Não escolher uma classificação indicativa apenas por este ser um produto empresarial: responder ao questionário.

Revisar separadamente a forma de contratação do serviço e as regras de pagamentos aplicáveis antes de acrescentar compra, assinatura ou direcionamento de pagamento no app. Esta entrega não configura checkout ou faturamento Google Play.

Enviar primeiro à faixa apropriada de teste, corrigir falhas e atender ao teste fechado se a conta for pessoal. Depois solicitar produção, escolher os países atendidos e enviar para revisão. Publicar somente após a análise, sem prometer data de aprovação. Verificar a instalação/atualização pelo link autorizado e acompanhar estabilidade e suporte.

Lista de acompanhamento

As verificações da loja podem mudar. Reabrir as fontes oficiais e as tarefas do Console quando a conta for criada e a versão for enviada.