Diário de desenvolvimento

Em 2026, ainda é surpreendentemente difícil manter um app de sono tocando a noite toda

Por Colin Hanson · 13 de outubro de 2026 · 7 min de leitura

Eu queria que meu celular fizesse barulho de ventilador até de manhã. Em 2026, parecia um problema razoavelmente resolvido. Mas consumiu uma quantidade surpreendente do meu tempo como desenvolvedor.

Usei White Noise Lite durante anos. Tinha anúncios e uma interface que parecia antiga, mas geralmente funcionava, que era o importante. Então começou a parar com frequência. Eu chamava isso de travamento, sem ter os logs para saber a causa. Também queria uma interface moderna e som gerado no aparelho em vez de uma gravação, com controles precisos. Acabei criando o Veil e entendendo muito melhor o problema da confiabilidade.

No iOS, a reprodução em segundo plano foi relativamente simples e, pela minha experiência, o Veil é muito estável desde o início. No Android, o trabalho foi maior: aparelhos variados, modelos antigos com pouca memória, gestão de bateria dos fabricantes e atualizações no meio da reprodução. Meu próprio código também tinha problemas. Para quem acorda às três da manhã, a diferença importa pouco.

Comecei pelos relatórios de falhas, mas precisava de contexto. Um processo encerrado pode não relatar exceções; um processo vivo pode ter um fluxo de áudio silencioso. Nem um serviço em primeiro plano com notificação prova que sai som do alto-falante. Acrescentei um registro nativo de reprodução, dados de encerramento, medidas de memória, estados do serviço, eventos de áudio e registros de paradas intencionais. As evidências relevantes sobrevivem ao processo e são coletadas numa abertura posterior.

A ideia era reconstruir a noite para distinguir causas possíveis. Ainda era para tocar? O temporizador terminou? A memória crescia? O celular estava carregando? O Android substituiu o pacote? Mais sinais ajudavam, desde que eu entendesse o que cada um podia mostrar.

Primeiro precisei corrigir a medição. Remover o Veil dos apps recentes podia parar o áudio sem fechar corretamente a sessão registrada. Horas depois, o Android recuperava o processo em cache, e meu relatório contava isso como falha de reprodução. Uma parada voluntária pela manhã virava um “encerramento noturno”. Já atualizações que interrompiam áudio real eram excluídas como saídas normais do sistema.

Corrigir as definições mudou o panorama antes de outras correções no áudio. Agora separo melhorias na reprodução de melhorias na medição. Analiso os dados regularmente por versão, família de aparelhos, duração e motivo de saída, excluindo testes e duplicatas. Relatos atrasados também importam: poucas sessões curtas não provam que uma versão aguente uma noite.

Esses padrões orientam os testes. Faço testes longos e noturnos em celulares reais e sessões no laboratório remoto da Samsung, com logcat contínuo, amostragem de memória e pressão de memória, e capturas do estado de áudio e serviços nas falhas. A coleta acontece sem eu precisar presenciar o problema.

O próprio teste pode interferir. USB alimenta o aparelho, então não equivale a um teste só na bateria. Executar dumpsys meminfo repetidamente podia causar falhas audíveis. Uma noite limpa só mostra que não reproduzi o problema naquelas condições, não que todos os aparelhos e estados estejam livres dele.

Uma descoberta estranha foi o Android Auto Backup. No meu Pixel, os logs mostraram o BackupManager encerrando o Veil durante um backup enquanto o som tocava. Nos dados das instalações, achei 190 SIGKILLs de processos protegidos em 93 instalações, entre 14 de agosto e 11 de setembro de 2026, com recorrências próximas de três dias. O padrão apoiava a hipótese de backup, sem provar cada caso.

Desativei o Auto Backup aceitando a perda correspondente na restauração pela nuvem. A documentação diz que o backup encerra o app, normalmente excluindo apps em primeiro plano. O registro no aparelho tornou esse caso concreto e acionável. Documentação de backup do Android

Outros problemas eram meus. A recuperação podia criar um contexto de áudio antes do anterior terminar de fechar, sobrepondo recursos quando o app já estava em dificuldade. Passei a aguardar o encerramento com limite de tempo e serializar recuperação e operações de reprodução. A intenção mais recente prevalece: apertar parar enquanto uma correção espera não pode resultar em som voltando depois.

Uma tentativa de correção criou outro problema. Uma verificação de 150 ms conferia se o relógio do contexto avançava, detectando contextos travados que se declaravam ativos. Ela aguardava um temporizador JavaScript, que em segundo plano podia ficar suspenso até o app voltar à tela. Agora a verificação roda só em primeiro plano. Mais um motivo para testar recuperação com a tela apagada.

Algumas mudanças importantes foram decisões de produto. Medições mostraram cerca de 90 MB adicionais de memória residente associados ao processo WebView dos anúncios. Investigações anteriores já tinham encontrado falhas graves de memória ligadas ao SDK. Primeiro tentei conter o custo; depois removi anúncios e SDK. Para um app que precisa durar a noite toda, confiabilidade valia mais.

Faltava saber se a pessoa esperava a parada. Após uma interrupção relevante, o Veil pode mostrar um cartão com o horário e perguntar “Você esperava isso?”. A escolha é intencional: “Você parou o som?” ignora um parceiro que o tenha parado ou uma interrupção prevista sem ação da pessoa.

Se era esperado, não há investigação da bateria. Caso contrário, o app reconhece a interrupção e oferece orientações conforme as evidências. A resposta informa sobre a experiência, sem fingir identificar a causa técnica. Também evita receber todo novo usuário Android com permissões assustadoras e uma caça às configurações de bateria.

Essas configurações são difíceis para os dois lados. Posso abri-las ou pedir uma exceção quando adequado, mas a decisão é do usuário. A exceção do Android não controla toda limpeza de processos dos fabricantes. Um passo específico depois de um problema ajuda mais que configurações desconhecidas antes do primeiro som. Orientações de energia do Android

Atualizações frustram especialmente. Posso indicar a opção de atualização automática por app no Play, mas o Veil não a controla. Atualizar manualmente dá trabalho, e o Google prevê exceções para atualizações críticas de segurança. Uma atualização para melhorar a confiabilidade noturna pode interromper a própria noite. Configurações de atualização do Google Play

A restauração automática após atualizações ainda está incompleta. Reconstruir o grafo de áudio é só uma parte: temporizador e intenção precisam ser preservados corretamente. Alguns padrões por fabricante ainda precisam de reprodução melhor antes de uma explicação segura. Quero recuperar falhas, não lutar contra quem parou o app de propósito.

O maior progresso veio de combinar análise recorrente, testes longos, correções específicas e relatos diretos. Cada um encontra o que os outros deixam passar. Importa menos o app dizer que está tocando e mais a evidência disso. Quem aperta play antes de dormir deveria poder confiar, mesmo que chegar lá tenha dado muito mais trabalho do que eu esperava.