Bateria de Celular em Proxy Móvel 24/7: Guia do Operador

Pontos-chave: A bateria de um celular de proxy móvel 24/7 morre por envelhecimento calendárico em estado de carga alto, não pela contagem de ciclos. Limite o carregamento em 80% usando um botão nativo do fabricante ou um smart plug com script ADB , marque o iProxy e o OpenVPN como Sem restrição , desative o Modo de economia de bateria do Android e a Bateria adaptável e mantenha a temperatura ambiente abaixo de 25°C. Aplicadas em conjunto, essas medidas tiram um celular Android típico de proxy de perder 30 a 40% da capacidade em 12 meses para reter 90% ou mais em 12 meses: uma extensão de 2 a 3 vezes na vida útil do hardware da frota.

Por que a saúde da bateria é o fator limitante em celulares de proxy 24/7

A longevidade da bateria em celulares de proxy móvel é o maior custo previsível em qualquer operação de proxy Android 24/7. Proxies móveis rodam em celulares Android reais, plugados na tomada o tempo todo, e o celular é hardware consumível. Em um horizonte de um ou dois anos de uso 24/7, a bateria é o componente que se degrada primeiro. Uma célula típica de lítio-íon perde de 25 a 40% da capacidade inicial em 12 a 18 meses de carregamento descontrolado. O celular continua ligando, mas esquenta sob carga, derruba conexões de proxy com mais frequência e, eventualmente, incha o suficiente para deformar a carcaça ou separar a tela.

A base laboratorial já explica o porquê. A tabela de armazenamento BU-808 da Battery University estima que células de lítio-íon à base de cobalto, armazenadas a 25°C, retêm cerca de 80% da capacidade após um ano com 100% de carga, contra 96% com 40% de carga; a 40°C, o caso de 100% cai para 65% após um ano.

Para uma frota de qualquer tamanho, essa rotatividade é o maior custo previsível em operações de proxy móvel. Os mecanismos de envelhecimento por trás disso são bem compreendidos e respondem a variáveis controláveis pelo operador: o limite superior de tensão no qual a célula fica, o tempo passado nessa tensão e a temperatura de operação.

Este artigo cobre a eletroquímica de como as células de lítio-íon envelhecem, as implicações para operação 24/7, os trade-offs de configuração no Android (muitos recursos de “economia de bateria” reduzem ativamente o uptime do proxy) e as ferramentas de hardware disponíveis para gerenciar o carregamento em uma fazenda de proxy baseada em celulares.

Como uma célula de lítio-íon realmente funciona

Uma célula de lítio-íon tem três partes funcionais: um ânodo de grafite, um cátodo de óxido de lítio-cobalto ou composto relacionado, e uma solução eletrolítica que permite que os íons de lítio transitem entre eles. Existe também um separador que impede que os eletrodos entrem em curto-circuito, e um coletor de corrente em cada lado: cobre no ânodo, alumínio no cátodo.

Quando a célula carrega, a força elétrica empurra os íons de lítio para fora da estrutura do cátodo e para dentro do ânodo de grafite. Os íons se encaixam entre as camadas de carbono em um processo chamado intercalação. Quando a célula descarrega, os íons migram de volta, e a energia liberada na volta ao cátodo flui para fora pelo circuito externo como corrente elétrica.

O estado de carga (SoC) da célula, ou seja, o quão cheia ela está, corresponde à quantidade de lítio que está atualmente no ânodo em relação ao cátodo. A 100% de SoC, o ânodo está quase saturado. A 0% de SoC, o cátodo está quase saturado.

A tensão da célula é o que o celular mede e reporta como porcentagem. Mas a tensão não é linear em relação ao SoC. A relação se aproxima de uma curva em S esticada, e essa não-linearidade é o fato mais importante deste artigo.

A curva de tensão e o joelho dos 80%

Plotando a tensão contra o SoC para uma célula típica de lítio-íon, aparecem três regiões:

• Abaixo de ~20% de SoC: a tensão cai abruptamente de cerca de 3,4V em direção ao corte de 3,0V. Abaixo de 3,0V, a célula se desliga para se proteger.
• Entre ~20% e ~80% de SoC: a tensão sobe suavemente de cerca de 3,6V para cerca de 4,05V. Esta é a parte gentil e funcional da curva.
• Acima de ~80% de SoC: a tensão sobe acentuadamente de 4,05V até o teto rígido de 4,20V (algumas químicas chegam a 4,35V, mas o princípio é o mesmo).

A transição acima de 80% é frequentemente chamada de “joelho” da curva. Não é uma linha de marketing, é onde a eletroquímica passa de confortável para estressada. Duas coisas acontecem quando a célula ultrapassa o joelho:

1. O ânodo de grafite fica quase totalmente preenchido com lítio. A estrutura está mecanicamente expandida, como uma esponja prestes a estourar. Cada íon adicional intercalando custa mais deformação e cria mais risco de defeitos estruturais.
2. A tensão se aproxima da janela de estabilidade eletroquímica do eletrólito. A 4,20V, o eletrólito está no limite do que suas moléculas suportam sem se decompor. Acima disso, reações paralelas aceleram exponencialmente.

Por que a curva importa mais que a porcentagem Quando o celular mostra “100%”, a célula está em cerca de 4,20V. Quando mostra “80%”, a célula está em cerca de 4,05V. Isso são 0,15V de diferença para o que aparece na tela como um intervalo de 20%, e 0,15V se traduzem em uma diferença de cerca de 2 a 3 vezes na taxa de envelhecimento; a BU-808 resume a mesma relação como vida em ciclos praticamente dobrada para cada redução de 0,10V na tensão de pico abaixo de 4,20V por célula.

Por que o estado de carga alto acelera o envelhecimento

O mecanismo de envelhecimento dominante em SoC alto é o crescimento da interface eletrolítica sólida (SEI). A SEI é uma película fina que se forma no ânodo na primeira vez que a célula é carregada. É, na verdade, uma camada útil: protege o ânodo da reação contínua com o eletrólito. Mas não é estável. Em tensão alta, o eletrólito se decompõe lentamente na superfície da SEI, engrossando-a e consumindo uma pequena quantidade de lítio ciclável a cada vez. Esse lítio fica preso, e a capacidade utilizável da célula cai.

O crescimento da SEI segue uma relação aproximadamente do tipo Arrhenius com tensão e temperatura. Como regra prática, cada redução de 0,1V na tensão máxima de carga praticamente dobra a vida em ciclos da célula; a mesma sensibilidade à tensão também reduz o estresse do envelhecimento calendárico. A temperatura segue a mesma direção: cada 10°C de redução na temperatura de operação é uma extensão significativa de vida útil, não uma mudança cosmética.

Existe um segundo mecanismo do lado do cátodo. Em tensão alta, metais de transição como cobalto, manganês e níquel podem se dissolver da estrutura do cátodo para o eletrólito, migrar para o ânodo e se depositar em sua superfície. Isso envenena a SEI e acelera ainda mais a degradação. Por isso células habitualmente carregadas a 100% podem perder capacidade mais rápido do que a contagem de ciclos sozinha preveria.

O envelhecimento calendárico, ou seja, a degradação em função do tempo, tensão e temperatura, independentemente de a célula estar sendo ciclada, é a variável mais importante para um celular que vive plugado. A tabela de armazenamento da BU-808 dá o número que interessa ao operador: uma célula de lítio-íon armazenada a 100% de SoC e 25°C retém cerca de 80% após um ano, enquanto a mesma tabela reporta cerca de 96% restantes a 40% de SoC. Um estudo revisado por pares sobre envelhecimento calendárico de células de lítio-íon chega à mesma conclusão direcional: 100% de SoC de armazenamento tem grande impacto, enquanto a influência é pequena abaixo de 80%.

Para um celular de proxy 24/7, a implicação é direta: deixe-o plugado a 100% e o envelhecimento calendárico vai dominar. O celular mal cicla, já que está sempre cheio, então não há quilometragem em ciclos sendo aproveitada em troca.

Por que a descarga profunda também é prejudicial

O problema espelhado em SoC baixo é menos comentado, mas é real.

Abaixo de ~20% de SoC, o cátodo está quase totalmente preenchido com lítio e sua estrutura cristalina fica instável. Em cátodos ricos em cobalto, átomos de oxigênio podem começar a se desprender da estrutura. Abaixo de 2,5V, bem abaixo do corte de “0%” do celular, o coletor de corrente de cobre do lado do ânodo começa a se dissolver no eletrólito. Quando a célula cai a esse ponto, depósitos dendríticos podem se formar em recargas posteriores, aumentando a resistência interna e criando risco de curto-circuito.

O firmware do celular desliga a célula bem antes que isso aconteça, normalmente em 3,0V por célula, o que corresponde ao “0%” exibido. Mas a ciclagem repetida perto do corte ainda aplica estresse, e uma célula que chega a 5% rotineiramente vai envelhecer mais rápido do que uma que se estabiliza em 30%.

A janela entre 20% e 80% de SoC é o regime estrutural e eletroquimicamente menos estressante para ambos os eletrodos. Esse é o motivo inteiro por trás da “regra dos 20-80” repetida na pesquisa de baterias.

O paradoxo 79→80% versus 99→100%

Um ponto comum de confusão: se o celular está configurado para carregar só até 80%, ele não fica ciclando constantemente entre 79% e 80%? Por que isso é melhor do que ciclar entre 99% e 100%?

A resposta é que a variação percentual não importa. O que importa é a tensão em que a variação acontece.

Um ciclo 79→80% move a célula entre cerca de 4,00V e 4,05V. O crescimento da SEI nessa tensão é lento. A decomposição do eletrólito é lenta. A estrutura do grafite tem espaço para se acomodar. A célula vivencia isso como um microciclo gentil.

Um ciclo 99→100% move a célula entre cerca de 4,17V e 4,20V. O crescimento da SEI aqui é várias vezes mais rápido. A taxa de oxidação do eletrólito é exponencialmente maior. A estrutura do grafite está sob estresse máximo. Mesmo um top-up de 1% nesse nível aplica dano desproporcional.

Na prática, um celular limitado a 80%, que passa a maior parte da vida microciclando em torno de 4,00V, pode durar de 2 a 5 vezes mais do que um celular sem limite. A tabela de tensão de carga da BU-808 estima 300 a 500 ciclos a 4,20V por célula, 600 a 1.000 a 4,06V por célula e 1.200 a 2.000 a 3,92V por célula, justamente a faixa que importa quando um celular de proxy para de flutuar em 100%.

O que mata baterias em operação 24/7 de proxy, por ordem

Para um celular que vive plugado como nó de proxy, os mecanismos dominantes de envelhecimento, em ordem aproximada de impacto, são:

1. Envelhecimento calendárico em SoC alto. Ficar em 100% por horas ou dias é o pior padrão. A tensão de flutuação a 4,20V impulsiona o crescimento contínuo da SEI.
2. Calor. A tabela de armazenamento da BU-808 estima cerca de 80% restantes após um ano a 25°C com 100% de carga, mas apenas 65% restantes a 40°C com 100% de carga. Um celular em uma pilha, perto de uma parede, no verão, sem ventilação, está operando na parte cara dessa curva.
3. Carga com taxa C alta. O carregamento rápido aquece a célula e estressa os eletrodos. Para operação 24/7, o carregamento lento entre 0,3 e 0,5C é muito melhor que o carregamento rápido.
4. Descargas profundas. Menos crítico para celulares plugados, mas se o celular cai para 5% durante quedas ocasionais de energia, esses eventos acumulam dano mais rápido do que o mesmo celular chegando a 30% como piso.
5. Contagem de ciclos. Isso é o que as especificações de vida em ciclos medem, mas para um celular sempre plugado é quase irrelevante. O celular mal cicla, e os efeitos calendáricos dominam.

Um modelo mental útil: pense em cada minuto que o celular passa acima de 4,10V por célula como caro, cada minuto entre 3,7V e 4,05V como barato, e cada minuto abaixo de 3,4V como caro novamente.

Recursos de bateria do Android e o efeito no uptime do proxy

Dois modelos mentais ajudam aqui.

O primeiro é o sistema App Standby Bucket, introduzido no Android 9 e apertado em cada versão desde então. Cada app fica em um de cinco buckets (active, working_set, frequent, rare ou restricted) com base em quanto o usuário interage com ele. Apps nos buckets inferiores recebem progressivamente menos jobs, alarmes e (em rare e restricted) acesso à rede. O recurso Bateria adaptável, também do Android 9, sobrepõe um modelo de aprendizado de máquina à atribuição de buckets. O Modo Doze (Android 6) está por baixo de tudo isso e adia rede e CPU em segundo plano quando o celular está ocioso e parado.

O segundo é o contrato de serviço em primeiro plano. Um app que mantém um serviço em primeiro plano com uma notificação persistente visível é tratado pelo sistema como trabalho perceptível ao usuário, e a maioria das restrições baseadas em bucket fica suspensa enquanto o serviço roda. O iProxy, como todo app de rede de longa duração, depende de um serviço em primeiro plano para continuar acessível.

Uma ressalva útil da documentação oficial do Android sobre Standby Buckets: “Essas restrições se aplicam apenas enquanto o aparelho está em bateria. Enquanto o aparelho está carregando, o sistema não impõe essas restrições.” Essa exceção é o motivo de um celular que passa cada minuto plugado na tomada geralmente rodar o proxy bem mesmo quando, em outras condições, estaria no bucket rare ou frequent. É também por isso que um celular em carregamento ciclado por smart plug, que alterna entre carregando e não carregando, pode bater nas restrições de bucket durante as janelas sem carga. E é por isso que duas mudanças específicas se aplicam independentemente do estado de carga: o bucket restricted do Android 12 e o limite de serviço em primeiro plano do Android 15.

O que segue é um resumo, versão por versão, das mudanças que importam para um app de proxy 24/7, focado no que o operador precisa fazer.

Quer o passo a passo clicável? As subseções versão por versão abaixo explicam o que mudou em cada release e por quê. Para os toques exatos necessários para configurar tanto o app iProxy quanto o app de túnel OpenVPN for Android como “Sem restrição” em cada versão do Android, com capturas de tela, veja como desativar a otimização de bateria do Android para iProxy e OpenVPN . Para as chaves do sistema (Economia de bateria, Bateria adaptável, limite de carga de 80%), veja o guia complementar sobre desativar a Economia de bateria do Android e o limite de carga de 80% em celulares de proxy .

Android 9 (API 28): App Standby Buckets, Bateria adaptável, FOREGROUND_SERVICE

• App Standby Buckets e Bateria adaptável são introduzidos. Apps em buckets inferiores têm jobs e alarmes progressivamente limitados.
• Apps que miram Android 9 precisam solicitar a permissão FOREGROUND_SERVICE. Sem ela, iniciar um serviço em primeiro plano lança SecurityException.
• Notificações de apps suspensos ficam ocultas até que o app retome, em vez de serem canceladas.

Para um celular plugado de proxy rodando Android 9, nada disso é fatal desde que o app mantenha um serviço em primeiro plano.

Android 10 (API 29): Restrições de início de atividade em segundo plano

• Apps em segundo plano não conseguem mais iniciar atividades, com uma pequena lista de exceções (notification trampolines, acessibilidade etc.).
• A localização em segundo plano agora exige uma permissão de runtime separada (ACCESS_BACKGROUND_LOCATION), distinta da localização em primeiro plano.

Um app de proxy normalmente não inicia atividades a partir do segundo plano, então o impacto é pequeno. A mudança só importa se o app trouxer sua interface de volta a partir de um comando remoto.

Android 11 (API 30): Auto-reset de permissões, WorkManager obrigatório

• Permissões de runtime são resetadas automaticamente em apps com os quais o usuário não interage há “alguns meses”. Antecessor da hibernação completa de apps do Android 12.
• Firebase JobDispatcher e GcmNetworkManager são desativados para apps que miram API 30+. WorkManager é o único agendador suportado.
• A localização em segundo plano não pode mais ser solicitada via diálogo de runtime. O usuário precisa conceder explicitamente em Configurações.

Para um app de proxy que o usuário instala uma vez e nunca reabre visivelmente, o auto-reset é um risco real. Ou o usuário precisa interagir visivelmente a cada poucos meses, ou a hibernação precisa ser desativada por app (a chave chega no Android 12).

Android 12 (API 31): Hibernação de apps, bucket restricted, proibição de FGS a partir do segundo plano

Esta é a primeira versão em que múltiplas mudanças podem quebrar um proxy 24/7 em um celular que, no resto, fica plugado continuamente.

• Hibernação de apps. Construída sobre o auto-reset do Android 11. Apps não usados por vários meses têm permissões revogadas e são colocados em estado de hibernação, no qual não rodam em segundo plano até serem reabertos. Botão por app: Configurações → Apps → iProxy → desativar “Pausar atividade do app se não usado” (ou o rótulo equivalente do fabricante).
• Bucket standby restricted. Um novo quinto bucket abaixo de rare. As restrições se aplicam mesmo durante o carregamento: no máximo um job por dia em sessão batched de 10 minutos, um alarme por dia (exato ou inexato) e throttling severo de rede. Gatilho: o usuário não interage com o app por 45 dias, ou o app é sinalizado por broadcasts ou bindings excessivos.
• Serviços em primeiro plano não podem ser iniciados a partir do segundo plano. Apps que miram Android 12+ não conseguem mais iniciar um serviço em primeiro plano enquanto o próprio app está em segundo plano, exceto por uma pequena lista isenta (alarmes, push messages, serviços de acessibilidade, toques em notificação). O serviço em primeiro plano do proxy precisa ser iniciado a partir de um contexto que o sistema considera primeiro plano (boot completo, alarme exato, interação do usuário).
• Limite de processos fantasmas. 32 processos filhos por app. Afeta apps que criam muitos subprocessos; um app de proxy de processo único raramente atinge.

Ações do operador no Android 12+: desativar hibernação explicitamente para o app de proxy, garantir que o FGS é iniciado a partir de um contexto permitido e reabrir o app visivelmente pelo menos a cada dois meses para mantê-lo fora do bucket rare e longe do gatilho de 45 dias do bucket restricted.

Android 13 (API 33): Permissão de runtime POST_NOTIFICATIONS, bucket restricted mais apertado

• POST_NOTIFICATIONS como permissão de runtime. Apps que miram API 33+ precisam solicitá-la antes de mostrar notificações comuns. Os docs de permissão de notificação do Android fazem uma distinção importante para serviços em primeiro plano: se o usuário negar a permissão, os avisos do serviço em primeiro plano ainda aparecem no Gerenciador de tarefas, mas não na gaveta de notificações. Ou seja, o serviço não vira um serviço de segundo plano comum apenas porque a permissão de notificação foi negada, mas o operador perde o sinal persistente da gaveta usado para perceber quedas e reinícios.
• Gatilho do bucket restricted reduzido de 45 dias para 8 dias em apps que miram Android 13+. Um app de proxy que o usuário não abre visivelmente por uma semana de tempo de calendário normal pode cair em restricted.
• BOOT_COMPLETED suprimido no estado de bateria “restricted” definido pelo usuário. A documentação do Android observa: “Se o usuário colocar seu app no estado restricted para uso de bateria em segundo plano enquanto seu app mira Android 13, o sistema não entrega o broadcast BOOT_COMPLETED nem o LOCKED_BOOT_COMPLETED até que o app seja iniciado por outros motivos.” A inicialização automática no boot não é garantida nesse estado.
• A interface do Gerenciador de tarefas permite que os usuários vejam e parem serviços em primeiro plano a partir da sombra de notificações, independentemente da concessão da permissão de notificação.

Ações do operador no Android 13+: conceder POST_NOTIFICATIONS na primeira instalação para visibilidade e diagnóstico, definir o app de proxy como “Sem restrição” nas configurações de bateria por app e aceitar que a janela de 8 dias significa que o app precisa estar visivelmente ativo periodicamente, seja por uso normal, seja por um watchdog externo (script ADB + cron) que reabre o app em horário fixo.

Android 14 (API 34): Tipos obrigatórios de serviço em primeiro plano, ANRs do JobScheduler

• Declaração obrigatória do tipo de serviço em primeiro plano. Todo serviço em primeiro plano de longa duração precisa declarar seu tipo no manifesto: dataSync, mediaPlayback, connectedDevice, specialUse, shortService, health, remoteMessaging etc. Apps que não declaram um tipo são mortos; apps com tipo declarado incorretamente podem ser sinalizados pela política da Google Play.
• ANR no JobScheduler. Se onStartJob ou onStopJob rodam tempo demais na thread principal, o sistema gera um ANR (“No response to onStartJob”). Antes, essas falhas eram silenciosas.
• ACCESS_NETWORK_STATE obrigatório para chamadas do JobScheduler que usam setRequiredNetworkType() ou setRequiredNetwork(). A ausência lança SecurityException.

A grande mudança para apps de proxy é a declaração do tipo do serviço em primeiro plano. Escolher o tipo errado agora afeta quais restrições se aplicam, incluindo o limite de 6 horas do Android 15 coberto a seguir.

Android 15 (API 35): O limite de 6 horas para serviço em primeiro plano

• Para apps que miram Android 15, os tipos de serviço em primeiro plano dataSync e o novo mediaProcessing ficam sujeitos a um limite cumulativo de 6 horas por janela de 24 horas, conforme os docs de timeout de FGS do Android . Após 6 horas de tempo de execução de FGS, o sistema invoca Service.onTimeout(), e se o serviço não chamar stopSelf() em segundos, lança RemoteServiceException (“A foreground service of type dataSync did not stop within its timeout”).
• Depois que a cota é esgotada, tentar iniciar outro FGS dataSync (ou mediaProcessing) lança ForegroundServiceStartNotAllowedException com a mensagem “Time limit already exhausted for foreground service type dataSync”.
• O orçamento de 6 horas é resetado quando o usuário traz o app para primeiro plano. Para um nó de proxy 24/7, isso não acontece sozinho.
• Tipos de serviço em primeiro plano não sujeitos ao limite de 6 horas incluem specialUse, connectedDevice, mediaPlayback, camera, phoneCall, microphone e location (sujeitos à política atual da Google Play sobre uso apropriado de cada tipo).

Para um app de proxy, esta é a mudança mais provável de quebrar uma configuração 24/7. A mitigação é declarar um tipo de FGS não limitado, apropriado ao propósito do app. O papel do iProxy de encaminhamento de tráfego encaixa em specialUse ou connectedDevice com mais clareza do que em dataSync, que o Google pretende para sincronização periódica de dados do usuário, não para encaminhamento de tráfego sempre ligado.

Android 16 (API 36): Aperto das cotas do JobScheduler

• Cotas de runtime de jobs baseadas em standby bucket agora são impostas também para o bucket active, não só para os buckets inferiores, conforme os docs de mudanças de comportamento do Android 16 .
• Cotas de jobs em top-state e concorrentes com FGS. Jobs que iniciam enquanto o app está visível e continuam depois que ele fica invisível, mais jobs rodando concorrentes com um serviço em primeiro plano, agora aderem a cotas de runtime que antes ignoravam.
• JobInfo.setImportantWhileForeground está totalmente descontinuado e ignorado.
• scheduleAtFixedRate só recupera uma execução perdida depois que o app retorna a um ciclo de vida válido. Antes, todas as execuções perdidas rodavam imediatamente.
• Um novo STOP_REASON_TIMEOUT_ABANDONED distingue jobs que não foram limpos adequadamente de timeouts comuns.

Para um app de proxy que usa jobs ao lado do FGS principal, o efeito prático é que jobs não podem mais contar com execução concorrente com FGS para runtime ilimitado. Trabalho longo pertence dentro do próprio FGS, ou dentro de um job de transferência de dados iniciado pelo usuário.

Android 17 (API 37): Início de atividade em segundo plano ainda mais restrito

• Background Activity Launch (BAL) apertado. Apps que antes usavam MODE_BACKGROUND_ACTIVITY_START_ALLOWED precisam migrar para MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, ou aceitar que inicializações de atividade em segundo plano serão bloqueadas.
• Endurecimento de áudio em segundo plano. APIs de reprodução de áudio, foco de áudio e volume agora exigem um FGS com capability while-in-use ou permissão de alarme exato com streams de áudio USAGE_ALARM. Relevante principalmente para apps de mídia.

Para um app de proxy típico, o Android 17 é, em sua maior parte, invisível: confirme que targetSdkVersion está atual e que o app não depende de iniciar atividades a partir do segundo plano.

Matadores específicos de fabricantes (ortogonais à versão do Android)

Independentemente do Android puro, as skins de fabricantes embarcam gerenciamento agressivo de bateria que vai de tolerável (Pixel puro) a abertamente hostil (Huawei). Os padrões e correções por fabricante:

Algumas notas sobre os piores casos. Xiaomi MIUI e HyperOS vêm com autoinicialização negada para tudo fora dos apps de sistema, então sem um botão explícito de autoinicialização o app de proxy simplesmente não inicia depois de um reboot. A Samsung One UI mantém uma lista oculta de apps em suspensão que cresce automaticamente: um app de proxy que o operador não abriu manualmente pode parar lá semanas depois, mesmo que a configuração inicial pareça correta. A Huawei EMUI e HarmonyOS historicamente exigiam marcar um app como “protegido” através de uma tela separada do Gerenciador de bateria; sem isso, o limpador de sistema mata o app em minutos depois que ele vai para segundo plano.

O projeto comunitário dontkillmyapp.com acompanha os piores ofensores e mitigações por fabricante, pontuados em escala de 1 a 5, e vale guardar nos favoritos de qualquer operador rodando frotas mistas. Para o complemento dessa tabela do lado da versão do Android (Economia de bateria, Bateria adaptável, o limite de 80% no Pixel e Samsung), veja o guia de economia de energia do lado do sistema .

Política de sleep do Wi-Fi

Alguns celulares desconectam o Wi-Fi quando a tela está apagada para economizar bateria. Para um proxy isso é fatal: o celular passa a usar só dados móveis ou derruba a conexão de proxy inteira. Trave o Wi-Fi em “sempre ligado” ou “nunca desconectar quando plugado”, normalmente em Configurar → Wi-Fi → Avançado → Manter Wi-Fi ativo durante a suspensão.

O que fazer, em ordem de importância

1. Desativar a Economia de bateria por completo. Não deixe ela auto-acionar. Veja o passo a passo por versão .
2. Definir o app iProxy e qualquer app de túnel VPN do qual ele depende como “Sem restrição” (ou “Não otimizar”) nas configurações de bateria por app. O caminho varia por versão do Android; para o fluxo clicável em cada versão de 9 até 16, veja o passo a passo para Sem restrição por app .
3. Conceder POST_NOTIFICATIONS na primeira instalação (Android 13+).
4. Desativar a hibernação de apps e “pausar quando não usado” para o app de proxy (Android 12+).
5. Liberar o app de proxy dos matadores específicos do fabricante conforme a tabela acima. Xiaomi: autoinicialização ligada, travar nos recentes. Samsung: suspensão profunda desligada, app nunca dorme ligado. Realme/Oppo: manter ativo ligado. Huawei: app protegido ligado.
6. Nunca forçar parada do app de proxy pela tela de info do app. No Android 15+, o estado parado persiste até ação direta ou indireta do usuário e cancela intents pendentes; abra o app de novo se isso acontecer.
7. Confirmar que o tipo de serviço em primeiro plano do app de proxy não está sujeito ao limite de 6 horas (Android 15+, apps com target SDK 35+).
8. Travar o Wi-Fi como sempre ligado quando plugado.
9. Desativar a Bateria adaptável, ou aceitar que ela pode despriorizar o app de proxy e auditar periodicamente.
10. Desativar a Economia de dados e qualquer chave de “restringir dados em segundo plano”.
11. Reabrir visivelmente o app de proxy a cada poucas semanas para mantê-lo fora dos buckets rare e restricted (especialmente Android 13+, que dispara em 8 dias sem uso).

A regra geral Se uma configuração promete economizar bateria limitando atividade em segundo plano, ela vai prejudicar o uptime do proxy. Proxies são atividade em segundo plano. Desative tudo nessa categoria e dependa de medidas do lado do carregamento (cobertas a seguir) para estender a vida da bateria.

Solução de hardware: smart plugs e carregamento programado

A forma mais confiável de manter um celular 24/7 na faixa doce de 20 a 80% é controlar a entrada de energia em vez de depender do software. Alguns celulares têm um limite de carga embutido (o Pixel 6a+ do Google oferece “Limitar a 80%”, a Samsung One UI 6.1+ tem “Proteção da bateria”, a Sony tem “Battery Care”, a Xiaomi expõe um limite oculto de 80% no HyperOS em modelos selecionados), mas a maioria não tem, e mesmo onde existe, a implementação pode ser inconsistente.

Um smart plug, ou seja, uma tomada elétrica controlada por Wi-Fi, resolve isso de forma genérica. A tomada liga e desliga o carregador conforme uma programação. O celular reporta seu estado de carga pela rede (ou aparece em qualquer painel de gerenciamento de frota), e um loop simples carrega até ~80%, fica ocioso e retoma quando o SoC cai para ~30%.

Configurações práticas:

• Smart plugs de prateleira. TP-Link Tapo, Sonoff e plugues Wi-Fi similares custam de R$ 50 a R$ 150 cada e se integram à maioria das plataformas de automação residencial. A abordagem mais crua é uma programação fixa (carrega por 4 horas, desliga por 8 horas), o que serve como primeira passada, mas não acompanha o SoC real.
• Firmware Tasmota ou ESPHome. Reflashar um smart plug com firmware aberto permite controle via MQTT ou uma API HTTP local, o que significa que um script pode consultar o nível real da bateria do celular e alternar a tomada.
• Home Assistant. Se o Home Assistant já está rodando, a integração é direta: um sensor de bateria (via script ADB ou um app dedicado de broadcast de bateria) lê o SoC, e uma automação alterna a tomada nos limiares definidos.
• Cortes DIY na linha USB. Um relé na linha de energia USB, controlado por um ESP32 ou Raspberry Pi, pode fazer o mesmo mais perto do aparelho. É o mais barato em escala, mas o mais frágil.

Para a receita universal (um smart plug mais um pequeno script ADB que lê o SoC do celular e alterna a tomada em 30% e 80%), que funciona em qualquer modelo Android independentemente de o fabricante fornecer ou não um limite nativo, veja a seção sobre smart plug + script ADB no guia de economia de energia do lado do sistema .

Ressalva: mantenha o celular rodando Alguns celulares entram em sono profundo ou hibernam quando o carregador é desconectado, mesmo com a tela ligada. Teste o modelo específico: confirme que o celular continua servindo tráfego de proxy enquanto o smart plug está na parte “desligada” do ciclo. Se não estiver, talvez um app de wakelock seja necessário, ou os intervalos desligados precisem ser mais curtos.

Uma programação-alvo razoável para a maioria dos celulares: carregar até 80% (geralmente 1 a 2 horas a partir de 30%), ficar ocioso até o SoC cair para 30% (geralmente 8 a 12 horas de tráfego normal de proxy) e então carregar de novo. Isso produz de 2 a 3 ciclos parciais por dia na faixa de tensão gentil, em vez de flutuação constante a 4,20V.

Um checklist prático de longevidade para operadores de proxy

Configure cada celular uma vez, idealmente antes de entrar em produção:

1. Limitar o carregamento em 80%, por qualquer meio disponível: botão nativo do fabricante (Pixel 6a+, Samsung One UI 6.1+) ou programação de smart plug. A receita ADB universal funciona em qualquer modelo.
2. Evitar deixar o SoC cair abaixo de 20%. Se a carga de tráfego drena o celular mais rápido do que o carregador consegue repor, é um problema de fiação ou de potência do carregador que vale resolver antes que a célula comece a sofrer dano.
3. Desativar a Economia de bateria e a Bateria adaptável no nível do sistema. Veja o guia de bateria do lado do sistema .
4. Definir o app iProxy e o OpenVPN como “Sem restrição” nas configurações de bateria por app, mais autoinicialização, mais trava em segundo plano. Passo a passo por versão: desativar a otimização de bateria do Android para iProxy e OpenVPN .
5. Liberar o app de proxy dos matadores específicos do fabricante conforme a tabela acima. Xiaomi: autoinicialização ligada, travar nos recentes. Samsung: suspensão profunda desligada, app nunca dorme ligado. Realme/Oppo: manter ativo ligado. Huawei: app protegido ligado.
6. Travar o Wi-Fi como sempre ligado quando plugado, nunca dormir.
7. Escolher aparelhos com limite de 80% nativo quando possível. A página de aparelhos Android recomendados para o iProxy marca Pixel 8/9 e Galaxy recentes especificamente por esse recurso.
8. Carregar devagar. Use um adaptador de parede de 1A ou 1,5A, não um carregador rápido de 3A, para operação plugada. Corrente menor significa temperaturas mais baixas e menos estresse na célula.
9. Gerenciar a temperatura. Não empilhe celulares de forma apertada. Não coloque em cima de roteadores, modems ou sob sol direto. Mire ar ambiente em torno dos celulares, idealmente abaixo de 25°C. Ventilação importa; veja a seção de higiene de frota no guia de configuração de rede de proxy 4G .
10. Auditar trimestralmente. Atualizações do sistema operacional do celular podem reativar recursos desativados. Cheque a cada 90 dias. O checklist de configurações de conexão cobre a higiene mais ampla do operador que combina com essa auditoria.

Quando aposentar um celular

Mesmo com o melhor cuidado, bateria é consumível. O limiar prático de aposentadoria para um celular de proxy é quando a capacidade cai abaixo de cerca de 70% do valor novo. Abaixo disso, três coisas tendem a acontecer:

• A tensão cai mais sob carga, causando quedas intermitentes especialmente em picos de tráfego.
• A célula esquenta mais rápido, acelerando o próprio declínio.
• O inchaço físico se torna provável. Uma célula inchada pode estourar a tela, a tampa traseira ou, em casos raros, perfurar e pegar fogo.

A maioria dos celulares Android reporta a saúde da bateria nas configurações ou via ADB (dumpsys battery). Um operador de proxy rodando uma frota deveria acompanhar a saúde mensalmente e rotacionar celulares para fora antes de o inchaço começar. Um celular aposentado em 70% e revendido ou reaproveitado é um custo planejado; um celular que estoura a tela em 50% é um custo planejado mais um aparelho destruído. Escolher o hardware certo desde o começo paga aqui: a lista de aparelhos recomendados do iProxy acompanha modelos com suporte longo de sistema, menus de bateria previsíveis e o limite nativo de 80% que torna tudo neste artigo mais simples.

Números de referência

As recomendações deste artigo (limitar em 80%, evitar flutuação em 100%, carregar devagar, gerenciar temperatura, configurar o Android para que ele não interrompa o proxy) não são boas práticas arbitrárias. Cada uma corresponde a um mecanismo específico de degradação que escala exponencialmente com tensão ou temperatura: crescimento da SEI, dissolução de metais de transição do cátodo, oxidação do eletrólito, escalonamento Arrhenius com temperatura. As células são genuinamente sensíveis à tensão e à temperatura, de formas que o indicador de porcentagem na tela não expõe.

Dois pontos de referência para ancorar o custo-benefício. Trate como estimativas de planejamento de frota, não garantia para toda química de célula: a base vem das tabelas de armazenamento e tensão de carga da BU-808, enquanto o cenário de proxy 24/7 acrescenta variáveis reais de calor, carregador rápido e Android desassistido.

• Um celular de proxy 24/7 com configurações padrão do Android, plugado em carregador rápido, sentado em 100% o tempo todo, em uma pilha quente: tipicamente perde 30 a 40% da capacidade inicial dentro de 12 meses.
• O mesmo celular, limitado em 80%, carregado devagar em um smart plug, com economizadores de bateria do sistema desativados e matadores do fabricante liberados, em uma sala a 22°C com ventilação: tipicamente retém 90% ou mais da capacidade inicial em 12 meses, e provavelmente ainda fica acima do limiar de aposentadoria de 70% em 36 meses.

O custo de configuração é pequeno: um smart plug por aparelho, uma auditoria única de configurações por modelo de celular, mais as chaves por app e do sistema cobertas no guia de Sem restrição por app e no guia de economia de bateria do lado do sistema . A diferença de custo de capital entre trocar um celular a cada 12 meses e trocá-lo a cada 30 a 36 meses escala linearmente com a frota, e em qualquer frota acima de cinco aparelhos, paga o tempo de configuração já no primeiro trimestre.