Como criar um aplicativo Android: o caminho real

Criar um aplicativo Android tem duas partes de dificuldade muito diferente. Fazer o aplicativo funcionar é a parte previsível. Fazer ele funcionar em milhares de aparelhos distintos e passar pelas regras da loja é onde o projeto atrasa, e é a parte que nenhum tutorial de primeira tela conta.

Este texto trata dessas duas: o que a variedade de aparelhos exige de quem constrói, e a fila de requisitos entre o aplicativo pronto e a Play Store aberta ao público.

Android não é um aparelho, são milhares

A diferença central em relação ao iPhone é que o Android roda em hardware de muitos fabricantes, em versões diferentes do sistema, com camadas próprias por cima. Isso cria quatro frentes de trabalho que precisam estar no orçamento:

• Versões do sistema. A base instalada é distribuída entre várias versões, e a decisão de qual versão mínima suportar define quanto do público é alcançado e quanto de código antigo precisa ser mantido.
• Tamanhos e formatos de tela. De celular pequeno a tablet e dobrável, com densidades diferentes. Layout que só foi testado em um aparelho quebra em outro, e isso aparece em avaliação da loja.
• Camadas de fabricante. Cada marca ajusta o sistema, e o ajuste mais problemático é a gestão de bateria: fabricante que encerra processos em segundo plano agressivamente quebra notificação, sincronização e rastreamento, e o comportamento varia por marca.
• Permissões e privacidade. O sistema pede consentimento a cada versão nova para mais coisas, e o aplicativo tem que continuar utilizável quando o usuário nega. Fluxo desenhado assumindo permissão concedida trava.

A consequência prática é uma matriz de teste, não um aparelho de teste. Uma matriz enxuta e honesta cobre: dois ou três aparelhos populares na faixa de preço do público, um aparelho antigo com a versão mínima suportada, um tablet se o produto justificar, e teste em nuvem para o resto.

O que se usa hoje, e o que isso muda para quem contrata

Kotlin é a linguagem padrão do Android há anos, e a interface moderna é construída de forma declarativa, descrevendo o estado da tela em vez de manipular componentes um a um. Para quem contrata, três consequências:

• Projeto antigo em Java com interface em arquivos de layout não está errado, mas contratar evolução para ele é mais caro e encontra menos gente disponível.
• Tela declarativa reduz o custo de mudança visual, o que importa em produto que ainda vai mudar muito.
• Nativo não é a única opção. Multiplataforma entrega Android e iOS com uma base de código, e a escolha depende do tipo de produto, como está no comparativo de plataformas de desenvolvimento.

A fila da Play Store

Entre o aplicativo pronto e o público existe uma sequência de requisitos, e é ela que mais surpreende quem está no primeiro projeto:

1. Conta de desenvolvedor. Tem taxa única de inscrição, e o tipo escolhido importa: conta de organização exige um registro comercial, enquanto conta pessoal tem exigências extras de lançamento.
2. Teste fechado antes da produção. Conta pessoal criada nos últimos anos precisa rodar um teste fechado com pelo menos doze testadores ativos por catorze dias seguidos antes de pedir acesso à produção. Não é opcional, e é o item que mais atrasa cronograma feito sem saber disso.
3. Formato de publicação. Aplicativo novo sobe como pacote de aplicativo, não como arquivo instalável avulso, e a assinatura fica sob guarda da própria loja.
4. Declarações de privacidade. Formulário de segurança de dados, dizendo o que o app coleta e compartilha, mais política de privacidade publicada em endereço acessível. Divergência entre o que o app faz e o que foi declarado gera recusa.
5. Nível de API alvo. A loja exige que o aplicativo tenha como alvo uma versão recente do sistema, e essa exigência sobe todo ano. Aplicativo que para de ser atualizado deixa de aceitar atualização e, depois, de ser encontrado por novos usuários.
6. Revisão. Cada envio passa por análise, com prazo que varia. Motivo de recusa mais comum em produto de empresa é declaração de dados inconsistente e permissão pedida sem justificativa.

Vale entender também a escada de faixas de lançamento, porque ela é a ferramenta que evita estrago em público: teste interno, para o time, com liberação quase imediata; teste fechado, para um grupo convidado, que é onde a exigência dos catorze dias se cumpre; teste aberto, para quem quiser entrar; e produção, com liberação gradual por percentual de usuários. Subir direto para produção com cem por cento é possível e é onde nasce a avaliação de uma estrela: o mesmo defeito, descoberto em teste fechado, custa um dia de correção.

Some a isso um detalhe de calendário: contas e políticas mudam, então vale conferir os requisitos vigentes no início do projeto, não no fim.

Publicar não é o fim: o app precisa de manutenção

Aplicativo não é site: ele fica instalado em aparelho que muda de sistema debaixo dele. Três coisas continuam custando depois do lançamento:

• Atualização de nível de API, pelo menos uma vez por ano, para continuar na loja.
• Correção do que a versão nova do Android quebra, que costuma aparecer em permissão, notificação e segundo plano.
• Monitoramento de falhas, com relatório de erro por aparelho e versão. Sem isso, o time descobre o problema na avaliação de uma estrela.

Quem trata aplicativo como projeto que termina descobre em um ano que ele saiu da loja. Manutenção mínima anual é parte do custo, não imprevisto.

Android primeiro ou iOS primeiro

A resposta depende de quem paga a conta do produto, e existem dois padrões que se repetem. Produto de consumo com público amplo no Brasil costuma começar por Android, que tem a maior base instalada. Produto que depende de gasto dentro do app, ou que atende público corporativo em aparelho fornecido pela empresa, muitas vezes começa por iOS, onde a receita por usuário tende a ser maior.

Se o produto precisa dos dois desde o começo, a conversa não é mais sobre Android, é sobre multiplataforma, e aí vale ver o guia de como criar um aplicativo antes de decidir a tecnologia.

O que pesa no custo

Em aplicativo Android, quatro linhas explicam a maior parte da variação de orçamento:

• Quantidade de telas com regra própria, que é o que de fato mede tamanho de projeto.
• Integrações, com pagamento, mapa, notificação e sistemas internos da empresa.
• Matriz de teste, proporcional à variedade de aparelhos que o público usa.
• Backend, que normalmente é a maior parte do trabalho e a menos visível para quem contrata.

A faixa e o que muda o preço estão detalhados em quanto custa criar um app. Vale um alerta: orçamento de aplicativo sem backend descrito é orçamento incompleto, e a diferença aparece na segunda proposta.

Quando nativo Android faz sentido

Nativo é a escolha certa quando o aplicativo depende do aparelho de forma intensa: câmera com processamento, sensores, bluetooth com equipamento, mapa em uso contínuo, funcionamento offline de verdade ou desempenho gráfico. Também quando o público está concentrado em Android e não existe plano de iOS no horizonte próximo.

Não faz sentido quando o produto é essencialmente um cadastro com relatório, que roda melhor como aplicação web responsiva, sem loja, sem atualização obrigatória e sem matriz de aparelhos. Muita empresa pede aplicativo quando precisa de sistema acessível pelo navegador, e descobre isso depois de pagar duas lojas.

Antes de escolher o caminho, o recorte pesa mais que a tecnologia: como definir o escopo do primeiro produto digital e, se o app nasce de uma necessidade interna que virou oportunidade, como uma ferramenta interna virou receita.

Perguntas frequentes