Por que os apps beta exigem localização em segundo plano mesmo sem mapa aberto?

Abri o TestFlight na semana passada para atualizar um cliente de e-commerce que estou acompanhando, e a primeira coisa que o sistema pediu, antes mesmo do login, foi permissão para usar minha localização "sempre", ou seja, mesmo com o aplicativo fechado. O app é uma loja de sapatos. Não há mapa na interface, não há entrega feita pela própria loja e nem módulo de "lojas próximas" visível no menu principal. Para o usuário comum, isso é um sinal vermelho gigantesco; para quem trabalha com QA e desenvolvimento, é um erro de compilação chato, mas explicável.

A desconfiança é válida. Em 2026, a privacidade de dados não é apenas um diferencial, é uma exigência. Quando um beta solicita um recurso sensível desse tipo sem uma justificativa visual clara, o usuário imediatamente imagina coleta de dados para venda a terceiros ou rastreamento invasivo. A realidade técnica, na maioria dos casos em builds de desenvolvimento, é menos maligna e mais desorganizada: é o peso de SDKs de anúncios e logs de depuração mal configurados que forçam o GPS a ficar ligado.

A Inflação dos Logs de Depuração e SDKs de Anúncios

O motivo mais comum para essa solicitação agressiva em versões beta é a presença de ambientes de "staging" ou desenvolvimento de redes de anúncios como Google AdMob, AppLovin ou Unity Ads. Em versões de produção (as que você baixa na Play Store), esses SDKs são otimizados para consumir o mínimo de bateria e só pedir o necessário. Já nas builds internas ou betas fechados, o modo de depuração (debug mode) é ativado por padrão para que os engenheiros possam rastrear cada evento de conversão.

Isso significa que o SDK de publicidade está tentando validar se a impressão de um banner "aconteceu" no local correto. Para validar eventos de "store visit" (visita à loja), que são altamente valorizados no mercado publicitário brasileiro, a rede de anúncios exige o acesso contínuo ao GPS. O problema é que, muitas vezes, o desenvolvedor esquece de desativar essas flags específicas de teste ao subir o build para o canal beta público. O resultado é que você, que só quer testar o novo fluxo de pagamento PIX, está alimentando um log de latência e coordenadas geográficas que só serve para o time de ads calibrar o CTR (taxa de cliques).

Além disso, o logging de erros em segundo plano muitas vezes atrela o "crash report" à localização do usuário para verificar se o problema é regional. Se um app de banco beta está travando apenas em dispositivos na região Nordeste, por exemplo, o log com GPS é vital. Contudo, isso deveria ser transparente. Quando não é, gera a sensação de invasão.

O "Fantasma" do Geofencing em Testes A/B

Outro cenário técnico frequente envolve testes de recursos que ainda não foram expostos na interface do usuário, mas que já rodam no back-end da aplicação. Imagine que o iFood ou o Rappi estejam testando silenciosamente um novo sistema de entregas rápidas baseado em proximidade geográfica. O código de geofencing (cercas virtuais) já foi injetado no aplicativo beta para garantir que, quando o botão for ativado visualmente, a lógica por trás já esteja funcionando em tempo real.

O geofencing exige que o sistema operacional acorde o aplicário em intervalos curtos para verificar se o usuário cruzou uma fronteira virtual. Em um iPhone com iOS 19 ou um Android atual, isso acorda processadores e modems de dados que drenam bateria e aparecem na tela de uso de bateria como "Localização em segundo plano". O usuário vê a solicitação, olha para o app e não vê nada relacionado a mapas. A conclusão lógica é de spyware.

O erro aqui é de arquitetura de produto: liberar o código da cerca virtual antes de liberar a UI que explica o porquê daquela solicitação. É uma falha de comunicação entre o time de backend, que já precisa medir a latência da geolocalização em massa, e o time de frontend, que só vai mostrar o recurso no mês que vem. Eu já vi casos em canais experimentais do Telegram onde funcionalidades de proximidade ficaram semanas ativas invisivelmente, confundindo os testers mais atentos.

Configurações de Manifesto "Engessadas"

No Android, especificamente, existe um arquivo chamado AndroidManifest.xml que define todas as permissões do aplicativo. Muitas equipes de desenvolvimento utilizam o conceito de "Single Binary", ou seja, um único pacote de instalação serve tanto para o ambiente de teste quanto para a produção, alterando apenas o endpoint da API para onde os dados são enviados.

O problema dessa abordagem é que, se o manifesto incluir a permissão ACCESS_BACKGROUND_LOCATION para o ambiente de teste de uma funcionalidade específica (como rastreamento de corrêida para um app de esportes), o usuário do beta final recebe o mesmo pedido de permissão, mesmo que essa função esteja desativada para o público geral. Retirar essa permissão gera um novo binário, o que requer um ciclo completo de testes de regressão. Preguiça técnica ou pressão por prazos faz com que os times mantenham a permissão "mortá" no código, mas ativa na instalação.

Isso viola o princípio de menor privilégio. Se o beta não precisa da localização agora, ele não deveria pedir. Contudo, a realidade dos pipelines de CI/CD (Integração Contínua) em 2026 muitas vezes prioriza a velocidade de lançamento de novas features em detrimento da higiene de permissões.

O Risco Real: Falhas no Tratamento de Negação

O que poucos usuários percebem é que o maior perigo não é apenas dar a permissão, mas negá-la em um ambiente instável. Em apps betas, o tratamento de erro (error handling) para permissões negadas raramente é robusto. Em um app maduro, se você negar a localização, o app continua funcionando, mas sem mostrar a loja mais próxima.

Em um beta de desenvolvimento, negar essa permissão pode causar um NullPointerException ou uma exceção não tratada, fazendo o aplicativo fechar inesperadamente (crash) assim que você tentar acessar um módulo que depende de um contexto de localização, mesmo que indiretamente. Eu já perdi dados de formulário em testes do One UI 6 porque o sistema de serviçosesperava uma resposta de GPS que bloqueava a thread principal da interface.

Portanto, a decisão é entre dois riscos: entregar seus dados de movimento (que são anônimos na maioria das grandes plataformas) ou correr o risco de instabilidade no app. Se você optar por negar, esteja preparado para limpar o cache ou reinstalar o build se a aplicação entrar em loop de travamentos.

Veredito: Beta Público vs. Perfil de Desenvolvedor

Essa confusão destaca a diferença fundamental entre participar de um Beta Público e usar um perfil de desenvolvedor. No Beta Público (como o do WhatsApp ou Instagram oficial), as builds passam por um controle de qualidade mais rígido, e permissões sensíveis geralmente são justificadas antes de chegar ao usuário. Já em betas semi-abertos, como distribuição via TestFlight direto ou APKs no Telegram, o ambiente é muito mais "selvagem".

A recomendação técnica é tratar qualquer beta que peça localização em segundo plano sem explicação imediata na tela de "O que há de novo" como um potencial risco de bateria e aquecimento. Se você não tem um motivo claro para ceder — como participar ativamente de um teste de entrega ou realidade aumentada — negue a permissão. Se o app quebrar, reporte o bug. É a única forma de fazer com que os engenheiros parem de deixar permissões órfãs no manifesto e limpem o lixo de código que os SDKs de anúncios deixam para trás.

Lembre-se: builds de teste não são otimizados para consumo de energia. Deixar o GPS rodando inutilmente pode transformar a carga da sua bateria que duraria o dia todo em algo que chega aos 30% até o almoço. A privacidade é uma preocupação legítima, mas o dano imediato mais tangível para o usuário de beta é o desgaste do hardware e a frustração com a estabilidade. Use sempre um dispositivo secundário para esses testes, evitando comprometer seu aparelho principal.