Duración de la batería en celulares de proxy móvil 24/7

Idea clave: la batería de un celular con proxy móvil 24/7 muere por envejecimiento por calendario con estado de carga alto, no por cantidad de ciclos. Limita la carga al 80% con el interruptor nativo del OEM o con un enchufe inteligente + script ADB , marca iProxy y OpenVPN como Sin restricciones , desactiva el Ahorro de batería y la Batería adaptable de Android y mantén la temperatura ambiente por debajo de 25°C. Hechas en conjunto, estas medidas llevan a un celular Android típico de perder 30–40% de capacidad en 12 meses a conservar 90%+ a los 12 meses: una extensión de 2 a 3 veces la vida del hardware de la flota.

Por qué la salud de la batería es el factor limitante de un celular proxy 24/7

La duración de la batería en celulares de proxy móvil es el mayor costo predecible en cualquier operación de proxy Android 24/7. Los proxies móviles corren en celulares Android reales, enchufados a la corriente las 24 horas, y el celular es hardware consumible. En el plazo de uno o dos años de uso continuo, la batería es el componente que se degrada primero. Una celda de litio típica pierde entre 25% y 40% de su capacidad inicial en 12 a 18 meses de carga sin gestionar. El celular sigue encendiendo, pero se calienta bajo carga, pierde conexiones de proxy con más frecuencia y termina hinchándose lo suficiente como para que el chasis o la pantalla se separen.

La referencia de laboratorio ya explica el porqué. La tabla de almacenamiento BU-808 de Battery University estima que una celda de litio basada en cobalto almacenada a 25°C retiene cerca del 80% de su capacidad tras un año al 100% de carga, contra 96% al 40%; a 40°C, el caso del 100% cae al 65% después de un año.

Para una flota de cualquier tamaño, esa rotación es el mayor costo predecible de una operación de proxies móviles. Los mecanismos de envejecimiento detrás de eso son bien conocidos y responden a variables que el operador puede controlar: el voltaje máximo al que se queda la celda, el tiempo que pasa ahí y la temperatura de operación.

Este artículo cubre la electroquímica del envejecimiento de las celdas de litio, las implicancias para una operación 24/7, los compromisos de configuración del lado Android (muchas funciones de “ahorro de batería” reducen activamente el uptime del proxy) y las herramientas de hardware disponibles para gestionar la carga en una granja de proxies armada con celulares.

Cómo funciona realmente una celda de litio

Una celda de litio tiene tres partes funcionales: un ánodo de grafito, un cátodo de óxido de cobalto y litio (o un compuesto similar) y una solución electrolítica que permite a los iones de litio moverse entre ellos. También hay un separador que evita que los electrodos se cortocircuiten, y un colector de corriente a cada lado: cobre del lado del ánodo, aluminio del lado del cátodo.

Cuando la celda carga, una fuerza eléctrica empuja los iones de litio fuera de la red del cátodo hacia el ánodo de grafito. Los iones se acomodan entre las capas de carbono en un proceso llamado intercalación. Cuando la celda descarga, los iones migran de vuelta, y la energía liberada al regresar al cátodo fluye al circuito externo como corriente eléctrica.

El estado de carga (SoC) de la celda, o sea qué tan llena está, equivale a cuánto litio queda en el ánodo versus en el cátodo. Al 100% de SoC, el ánodo está casi saturado. Al 0% de SoC, el cátodo está casi saturado.

El voltaje de la celda es lo que el celular mide e informa como porcentaje. Pero el voltaje no es lineal con respecto al SoC. La relación se parece más a una curva en S estirada, y esa no linealidad es el dato más importante de este artículo.

La curva de voltaje y la rodilla del 80%

Si graficas el voltaje contra el SoC de una celda de litio típica, aparecen tres regiones:

• Debajo de ~20% SoC: el voltaje cae bruscamente desde unos 3,4V hacia el corte en 3,0V. Por debajo de 3,0V, la celda se apaga para protegerse.
• Entre ~20% y ~80% SoC: el voltaje sube suavemente de unos 3,6V a unos 4,05V. Esta es la parte tranquila y de trabajo de la curva.
• Por encima de ~80% SoC: el voltaje sube de golpe de 4,05V al techo duro de 4,20V (algunas químicas llegan a 4,35V, pero el principio es el mismo).

La transición arriba del 80% suele llamarse la “rodilla” de la curva. No es una línea de marketing; es donde la electroquímica pasa de cómoda a estresada. Dos cosas pasan al empujar la celda más allá de la rodilla:

1. El ánodo de grafito queda casi totalmente lleno de litio. La red está mecánicamente hinchada, como una esponja al borde de reventar. Cada ion adicional que se intercala cuesta más tensión y crea más riesgo de defectos estructurales.
2. El voltaje se acerca a la ventana de estabilidad electroquímica del electrolito. A 4,20V, el electrolito está al límite de lo que sus moléculas pueden soportar sin descomponerse. Por encima de eso, las reacciones secundarias se aceleran de forma exponencial.

Por qué la curva importa más que el porcentaje Cuando el celular muestra “100%”, la celda está cerca de 4,20V. Cuando muestra “80%”, la celda está cerca de 4,05V. Eso son 0,15V de diferencia para lo que en pantalla parece una brecha del 20%, y esos 0,15V se traducen en una diferencia aproximada de 2 a 3 veces en la tasa de envejecimiento; BU-808 resume la misma relación como una vida en ciclos que se duplica aproximadamente por cada 0,10V que bajes del pico de carga por debajo de 4,20V por celda.

Por qué un estado de carga alto acelera el envejecimiento

El mecanismo dominante de envejecimiento con SoC alto es el crecimiento de la SEI (interfase de electrolito sólido). La SEI es una película delgada que se forma sobre el ánodo la primera vez que se carga la celda. Es una capa útil: protege al ánodo de reaccionar continuamente con el electrolito. Pero no es estable. A voltaje alto, el electrolito se descompone lentamente sobre la superficie de la SEI, la engrosa y consume una pequeña cantidad de litio ciclable cada vez. Ese litio queda atrapado, y la capacidad útil de la celda cae.

El crecimiento de la SEI sigue una relación tipo Arrhenius con el voltaje y la temperatura. Como regla práctica, cada reducción de 0,1V en el voltaje máximo de carga duplica más o menos la vida en ciclos de la celda; la misma sensibilidad al voltaje también reduce el estrés por envejecimiento de calendario. La temperatura va en la misma dirección: cada 10°C menos en la temperatura de operación alarga la vida útil de forma significativa, no es un cambio cosmético.

Hay un segundo mecanismo del lado del cátodo. A voltaje alto, metales de transición como el cobalto, el manganeso y el níquel pueden disolverse de la red del cátodo hacia el electrolito, migrar al ánodo y depositarse en su superficie. Eso envenena la SEI y acelera más la degradación. Por eso las celdas cargadas siempre al 100% pierden capacidad más rápido de lo que la mera cuenta de ciclos predeciría.

El envejecimiento por calendario, o sea la degradación en función del tiempo, el voltaje y la temperatura sin importar si la celda se está ciclando, es la variable más importante para un celular que vive enchufado. La tabla de almacenamiento de BU-808 da el número que más le importa al operador: una celda de litio almacenada al 100% de SoC a 25°C retiene cerca del 80% al año, mientras que la misma tabla reporta cerca del 96% restante al 40% de SoC. Un estudio revisado por pares sobre envejecimiento por calendario de celdas de litio llega a la misma conclusión direccional: el SoC de almacenamiento al 100% tiene un impacto enorme, mientras que la influencia es baja por debajo del 80%.

Para un celular con proxy 24/7, la consecuencia es directa: déjalo enchufado al 100% y el envejecimiento por calendario va a dominar. El celular apenas cicla, porque siempre está lleno, así que no gana kilometraje en cuenta de ciclos a cambio del desgaste.

Por qué la descarga profunda también daña

El problema espejo en SoC bajo se menciona menos, pero es real.

Debajo de ~20% SoC, el cátodo queda casi lleno de litio y su estructura cristalina se vuelve inestable. En cátodos ricos en cobalto, átomos de oxígeno pueden empezar a liberarse de la red. Por debajo de 2,5V, muy por debajo del “0%” del celular, el colector de corriente de cobre del lado del ánodo empieza a disolverse en el electrolito. Una vez que la celda baja tanto, en las recargas siguientes pueden formarse depósitos dendríticos que aumentan la resistencia interna y crean riesgo de cortocircuito.

El firmware del celular apaga la celda mucho antes de eso, típicamente a 3,0V de voltaje de celda, lo que corresponde al “0%” que ves en pantalla. Pero el ciclado repetido cerca del corte igual aplica estrés, y una celda que llega al 5% rutinariamente va a envejecer más rápido que otra que toca fondo en 30%.

La ventana entre 20% y 80% de SoC es el régimen menos estresante, estructural y electroquímicamente, para ambos electrodos. Esa es toda la razón detrás de la “regla del 20-80” que se repite en la investigación de baterías.

La paradoja del 79→80% vs 99→100%

Una confusión común: si el celular está configurado para cargar solo al 80%, ¿no está ciclando todo el tiempo entre 79% y 80%? ¿Por qué eso es mejor que ciclar entre 99% y 100%?

La respuesta es que la oscilación porcentual no importa. Lo que importa es el voltaje al que ocurre la oscilación.

Un ciclo 79→80% mueve la celda entre 4,00V y 4,05V aproximadamente. El crecimiento de la SEI a ese voltaje es lento. La descomposición del electrolito es lenta. La red de grafito tiene espacio para flexionarse. La celda lo experimenta como un microciclo suave.

Un ciclo 99→100% mueve la celda entre 4,17V y 4,20V aproximadamente. El crecimiento de la SEI ahí es varias veces más rápido. La tasa de oxidación del electrolito es exponencialmente mayor. La red de grafito está al máximo estrés. Incluso un top-up del 1% a ese nivel aplica un daño desproporcionado.

En la práctica, un celular limitado al 80%, que pasa la mayor parte de su vida microciclando alrededor de la marca de 4,00V, puede durar de 2 a 5 veces más que un celular sin restricciones. La tabla de voltaje de carga BU-808 estima 300–500 ciclos a 4,20V por celda, 600–1.000 a 4,06V por celda y 1.200–2.000 a 3,92V por celda, que es justo el rango que importa cuando un celular proxy deja de flotar en 100%.

Qué mata las baterías en operación de proxy 24/7, en orden

Para un celular que vive enchufado como nodo de proxy, los mecanismos de envejecimiento dominantes en orden aproximado de impacto son:

1. Envejecimiento por calendario con SoC alto. Estar al 100% durante horas o días es el peor patrón. Voltaje de flotación a 4,20V genera crecimiento sostenido de la SEI.
2. Calor. La tabla de almacenamiento BU-808 estima cerca del 80% restante después de un año a 25°C y 100% de carga, pero solo 65% restante a 40°C y 100% de carga. Un celular apilado, contra una pared, en verano, sin ventilación, está operando en la parte cara de esa curva.
3. Carga a alto C-rate. La carga rápida calienta la celda y estresa los electrodos. Para operación 24/7, la carga lenta a 0,3–0,5C es muy superior a la carga rápida.
4. Descargas profundas. Menos crítico para celulares enchufados, pero si el celular cae al 5% en cortes esporádicos de energía, esos eventos acumulan daño más rápido que un celular que toca fondo en 30%.
5. Cuenta de ciclos. Es lo que miden las especificaciones de vida en ciclos, pero para un celular siempre enchufado es casi irrelevante. El celular apenas cicla, y los efectos de calendario dominan.

Un modelo mental útil: piensa cada minuto que el celular pasa arriba de 4,10V de voltaje de celda como caro, cada minuto entre 3,7V y 4,05V como barato, y cada minuto por debajo de 3,4V como caro otra vez.

Funciones de batería de Android y su efecto sobre el uptime del proxy

Dos modelos mentales ayudan acá.

El primero es el sistema de App Standby Buckets, introducido en Android 9 y endurecido en cada release desde entonces. Cada app se ubica en uno de cinco buckets (active, working_set, frequent, rare o restricted) según con qué frecuencia el usuario la usa. Las apps en los buckets más bajos reciben menos jobs, alarmas y, en rare y restricted, acceso a red. La función Adaptive Battery (Batería adaptable), también desde Android 9, agrega un modelo de machine learning encima de la asignación de bucket. El Modo Doze (Android 6) está debajo de todo eso y posterga red y CPU en segundo plano cuando el celular está inactivo y quieto.

El segundo es el contrato del foreground service (servicio en primer plano). Una app que mantiene un foreground service con una notificación persistente visible es tratada por el sistema operativo como trabajo perceptible por el usuario, y la mayoría de las restricciones por bucket se suspenden mientras corre el servicio. iProxy, como cualquier app de red de larga duración, depende de un foreground service para seguir alcanzable.

Una aclaración útil de la documentación oficial de App Standby Buckets de Android: “Estas restricciones aplican solo mientras el dispositivo funciona con batería. Mientras el dispositivo está cargando, el sistema no impone estas restricciones.” Esa excepción explica por qué un celular que pasa cada minuto enchufado a un toma corriente generalmente corre el proxy bien aunque cayera en el bucket rare o frequent. Y también por qué un celular con carga ciclada por enchufe inteligente, que alterna entre cargando y no, puede chocarse con restricciones de bucket durante las ventanas sin carga. Y es por eso que dos cambios específicos aplican sin importar el estado de carga: el bucket restricted de Android 12 y el cap de foreground service de Android 15.

Lo que sigue es un resumen versión por versión de los cambios que importan para una app de proxy 24/7, enfocado en qué necesita hacer el operador.

¿Buscas los pasos toque por toque? Las subsecciones siguientes por versión explican qué cambió en cada release y por qué. Para los toques concretos que necesitas para poner tanto la app iProxy como la app de túnel OpenVPN para Android en “Sin restricciones” en cada versión de Android, con capturas, mira cómo desactivar la optimización de batería de Android para iProxy y OpenVPN . Para los interruptores del sistema (Ahorro de batería, Batería adaptable, tope de carga al 80%), mira la guía complementaria sobre desactivar el Ahorro de batería de Android y poner el tope de carga al 80% en celulares proxy .

Android 9 (API 28): App Standby Buckets, Adaptive Battery, FOREGROUND_SERVICE

• Aparecen los App Standby Buckets y Adaptive Battery. Las apps en buckets más bajos sufren throttling progresivo en jobs y alarmas.
• Las apps que apuntan a Android 9 deben pedir el permiso FOREGROUND_SERVICE. Sin él, iniciar un foreground service arroja SecurityException.
• Las notificaciones de apps suspendidas se ocultan hasta que la app vuelve, en vez de cancelarse del todo.

Para un celular proxy enchufado con Android 9, nada de esto es fatal mientras la app mantenga un foreground service.

Android 10 (API 29): restricciones para iniciar actividades en segundo plano

• Las apps en segundo plano ya no pueden lanzar actividades, salvo una pequeña lista de excepciones (notification trampolines, accesibilidad, etc.).
• La ubicación en segundo plano ahora requiere un permiso de runtime aparte (ACCESS_BACKGROUND_LOCATION), distinto del de ubicación en primer plano.

Una app de proxy normalmente no lanza actividades desde segundo plano, así que el impacto es menor. El cambio solo pesa si la app vuelve a abrir su UI por un comando remoto.

Android 11 (API 30): auto-reset de permisos, WorkManager obligatorio

• Los permisos de runtime se auto-resetean para apps con las que el usuario no interactuó por “varios meses”. Antecesor de la hibernación completa de apps de Android 12.
• Firebase JobDispatcher y GcmNetworkManager quedan deshabilitados para apps que apuntan a API 30+. WorkManager es el único scheduler soportado.
• Ya no se puede pedir ubicación en segundo plano con un diálogo de runtime. El usuario tiene que otorgarla desde Configuración explícitamente.

Para una app de proxy que el usuario instala una vez y nunca vuelve a abrir visiblemente, el auto-reset es un riesgo real. O el usuario interactúa visiblemente cada pocos meses, o se desactiva la hibernación app por app (el interruptor llega en Android 12).

Android 12 (API 31): hibernación de apps, bucket restricted, prohibición de FGS desde background

Esta es la primera versión donde varios cambios pueden romper un proxy 24/7 en un celular que está enchufado todo el tiempo.

• Hibernación de apps. Se basa en el auto-reset de Android 11. Las apps sin uso durante varios meses pierden permisos y entran en un estado de hibernación donde no pueden correr en segundo plano hasta que se reabran. Interruptor por app: Configuración → Aplicaciones → iProxy → desactivar “Pausar actividad de la app si no se usa” (o la etiqueta equivalente del OEM).
• Standby bucket restricted. Un quinto bucket nuevo debajo de rare. Las restricciones aplican incluso cargando: como máximo un job por día en una sesión batched de 10 minutos, una alarma por día (exacta o inexacta) y throttling de red severo. Disparador: el usuario no interactúa con la app por 45 días, o la app queda marcada por broadcasts o bindings excesivos.
• Los foreground services no pueden iniciarse desde background. Las apps que apuntan a Android 12+ ya no pueden iniciar un foreground service mientras la app misma está en segundo plano, salvo una pequeña lista exenta (alarmas, push messages, servicios de accesibilidad, toques en notificaciones). El foreground service del proxy tiene que arrancar desde un contexto que el sistema considere foreground (boot completion, alarma exacta, interacción del usuario).
• Límite de procesos fantasma. 32 procesos hijos por app. Afecta a apps que generan muchos subprocesos; una app de proxy de un solo proceso rara vez lo toca.

Acciones del operador en Android 12+: desactivar la hibernación explícitamente para la app de proxy, asegurarse de que el FGS arranque desde un contexto permitido y reabrir visiblemente la app al menos cada un par de meses para mantenerla fuera del bucket rare y lejos del disparador de 45 días del bucket restricted.

Android 13 (API 33): POST_NOTIFICATIONS como permiso de runtime, bucket restricted más estricto

• POST_NOTIFICATIONS como permiso de runtime. Las apps que apuntan a API 33+ deben pedirlo antes de mostrar notificaciones normales. La documentación de permisos de notificación de Android hace una distinción importante para los foreground services: si el usuario niega el permiso, los avisos del foreground service siguen apareciendo en el Administrador de tareas, pero no en la bandeja de notificaciones. Eso significa que el servicio no se vuelve un servicio común en segundo plano solo porque se negó el permiso de notificaciones, pero el operador pierde la señal persistente del shade que usa para detectar caídas y reinicios.
• Disparador del bucket restricted reducido de 45 días a 8 días para apps que apuntan a Android 13+. Una app de proxy que el usuario no abre visiblemente por una semana de calendario normal puede caer en restricted.
• BOOT_COMPLETED suprimido en el estado “restringido” de batería fijado por el usuario. Los docs de Android notan: “Si el usuario pone tu app en estado restringido para uso de batería en segundo plano mientras tu app apunta a Android 13, el sistema no entrega el broadcast BOOT_COMPLETED ni el LOCKED_BOOT_COMPLETED hasta que la app arranque por otras razones.” El autostart al boot no está garantizado en ese estado.
• UI de Administrador de tareas permite al usuario ver y detener foreground services desde el shade de notificaciones, sin importar si concedió el permiso de notificación.

Acciones del operador en Android 13+: conceder POST_NOTIFICATIONS en la primera instalación para tener visibilidad y diagnóstico, poner la app de proxy en “Sin restricciones” en los ajustes de batería por app, y asumir que la ventana de 8 días obliga a que la app esté visiblemente activa de forma periódica, ya sea por uso normal o por un watchdog externo (script ADB + cron) que reabra la app en un horario fijo.

Android 14 (API 34): tipo de foreground service obligatorio, ANRs del JobScheduler

• Declaración obligatoria del tipo de foreground service. Todo foreground service de larga duración debe declarar su tipo en el manifest: dataSync, mediaPlayback, connectedDevice, specialUse, shortService, health, remoteMessaging, etc. Las apps que no declaran tipo son matadas; las que declaran mal el tipo pueden ser marcadas por la política de Google Play.
• Enforcement de ANR del JobScheduler. Si onStartJob u onStopJob corre demasiado tiempo en el hilo principal, el sistema lanza un ANR (“No response to onStartJob”). Antes esto fallaba en silencio.
• ACCESS_NETWORK_STATE requerido para llamadas a JobScheduler que usen setRequiredNetworkType() o setRequiredNetwork(). Si falta, se lanza SecurityException.

El gran cambio para las apps de proxy es la declaración del tipo de foreground service. Elegir el tipo equivocado ahora afecta qué restricciones aplican, incluido el cap de 6 horas de Android 15 que viene a continuación.

Android 15 (API 35): el cap de 6 horas en foreground services

• Para apps que apuntan a Android 15, los tipos de foreground service dataSync y el nuevo mediaProcessing están sujetos a un límite acumulado de 6 horas por ventana de 24 horas, según la documentación de timeouts de foreground services de Android . Tras 6 horas de runtime del FGS, el sistema invoca Service.onTimeout(), y si el servicio no llama a stopSelf() en pocos segundos, se lanza RemoteServiceException (“A foreground service of type dataSync did not stop within its timeout”).
• Una vez agotado el cupo, intentar iniciar otro FGS dataSync (o mediaProcessing) arroja ForegroundServiceStartNotAllowedException con el mensaje “Time limit already exhausted for foreground service type dataSync”.
• El presupuesto de 6 horas se resetea cuando el usuario trae la app a primer plano. En un nodo proxy 24/7, eso no pasa solo.
• Los tipos de foreground service no sujetos al cap de 6 horas incluyen specialUse, connectedDevice, mediaPlayback, camera, phoneCall, microphone y location (sujetos a la política vigente de Google Play sobre uso apropiado de cada tipo).

Para una app de proxy, este es el cambio que más probablemente rompe un setup 24/7. La mitigación es declarar un tipo de FGS sin cap que sea apropiado para el propósito de la app. El rol de iProxy como reenviador de tráfico encaja mejor en specialUse o connectedDevice que en dataSync, que Google pensó para sincronización periódica de datos del usuario y no para reenvío de tráfico permanente.

Android 16 (API 36): cuotas más estrictas del JobScheduler

• Las cuotas de runtime de jobs basadas en standby bucket ahora se aplican también al bucket active, no solo a los inferiores, según los docs de cambios de comportamiento de Android 16 .
• Cuotas para jobs en top-state y concurrentes con FGS. Los jobs que arrancan mientras la app es visible y siguen luego de que deja de serlo, más los jobs que corren en paralelo con un foreground service, ahora respetan cuotas de runtime que antes esquivaban.
• JobInfo.setImportantWhileForeground queda totalmente deprecado e ignorado.
• scheduleAtFixedRate solo recupera una ejecución perdida cuando la app vuelve a un ciclo de vida válido. Antes, todas las ejecuciones perdidas corrían de inmediato.
• Un nuevo STOP_REASON_TIMEOUT_ABANDONED distingue jobs que no fueron limpiados como corresponde de los timeouts comunes.

Para una app de proxy que use jobs junto al FGS principal, el efecto práctico es que los jobs no pueden depender de la ejecución concurrente con el FGS para tiempo de runtime ilimitado. El trabajo largo va dentro del propio FGS, o dentro de un job de transferencia de datos iniciado por el usuario.

Android 17 (API 37): lanzamientos de actividades en segundo plano aún más restringidos

• Background Activity Launch (BAL) más estricto. Las apps que antes usaban MODE_BACKGROUND_ACTIVITY_START_ALLOWED necesitan migrar a MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, o asumir que los lanzamientos desde background van a ser bloqueados.
• Endurecimiento de audio en segundo plano. La reproducción de audio, el audio focus y las APIs de volumen ahora requieren un FGS con capacidad while-in-use, o permiso de alarma exacta con streams de audio USAGE_ALARM. Relevante sobre todo para apps de medios.

Para una app de proxy típica, Android 17 es mayormente invisible: confirma que targetSdkVersion esté al día y que la app no dependa de lanzar actividades desde segundo plano.

Asesinos específicos del OEM (ortogonales a la versión de Android)

Aparte del Android stock, los skins de OEM traen gestión agresiva de batería que va de tolerable (Pixel stock) a directamente hostil (Huawei). Los patrones y los fixes por fabricante:

Algunas notas sobre los peores casos. Xiaomi MIUI y HyperOS vienen con autostart denegado para todo lo que no sea app del sistema, así que sin un interruptor explícito de autostart la app de proxy simplemente no arranca después de un reinicio. Samsung One UI mantiene una lista oculta de apps dormidas que crece sola: una app de proxy que el operador no abrió a mano puede caer ahí semanas después aunque la configuración inicial se vea correcta. Huawei EMUI y HarmonyOS históricamente exigieron marcar una app como “protegida” en una pantalla aparte del Battery Manager; sin eso, el limpiador del sistema la mata a los pocos minutos de mandarla a segundo plano.

El proyecto comunitario dontkillmyapp.com rastrea a los peores ofensores y las mitigaciones por OEM, con un puntaje de 1 a 5, y vale la pena marcarlo para cualquier operador con flotas mixtas. Para la tabla complementaria del lado de la versión de Android (Ahorro de batería, Batería adaptable, tope de carga al 80% en Pixel y Samsung), mira la guía de ahorro de energía a nivel sistema .

Política de Wi-Fi en reposo

Algunos celulares desconectan el Wi-Fi cuando se apaga la pantalla para ahorrar batería. Para un proxy eso es fatal: el celular cae a datos móviles solamente, o pierde la conexión del proxy por completo. Bloquea el Wi-Fi en “siempre encendido” o “no desconectar cuando está enchufado”, típicamente en Configuración → Wi-Fi → Avanzado → Mantener Wi-Fi activado durante el reposo.

Qué hacer, en orden de importancia

1. Desactiva el Ahorro de batería por completo. No dejes que se dispare solo. Mira el paso a paso por versión .
2. Pon la app de iProxy y cualquier app de túnel VPN de la que dependa en “Sin restricciones” (o “No optimizar”) en los ajustes de batería por app. La ruta cambia por versión de Android; para el flujo toque por toque en cada versión de la 9 a la 16, mira el paso a paso para dejar las apps Sin restricciones .
3. Concede POST_NOTIFICATIONS en la primera instalación (Android 13+).
4. Desactiva la hibernación de apps y “pausar cuando no se usa” para la app de proxy (Android 12+).
5. Saca la app de proxy de las listas de asesinos del OEM según la tabla de arriba. Xiaomi: autostart encendido, bloquear en Recientes. Samsung: sueño profundo apagado, app que nunca duerme encendida. Realme/Oppo: keep alive encendido. Huawei: app protegida encendida.
6. Nunca fuerces el cierre de la app de proxy desde la pantalla de info de la app. En Android 15+, el estado detenido persiste hasta una acción directa o indirecta del usuario y cancela los intents pendientes; si pasa, vuelve a abrir la app a mano.
7. Confirma que el tipo de foreground service de la app de proxy no esté sujeto al cap de 6 horas (Android 15+, apps con target SDK 35+).
8. Bloquea el Wi-Fi en siempre encendido cuando esté enchufado.
9. Desactiva la Batería adaptable, o asume que puede despriorizar la app de proxy y audita periódicamente.
10. Desactiva el Ahorrador de datos y cualquier interruptor de “restringir datos en segundo plano”.
11. Reabre visiblemente la app de proxy cada pocas semanas para mantenerla fuera de los buckets rare y restricted (sobre todo en Android 13+, que se dispara a los 8 días sin uso).

La regla general Si un ajuste promete ahorrar batería limitando la actividad en segundo plano, va a perjudicar el uptime del proxy. Los proxies son actividad en segundo plano. Desactiva todo lo de esa categoría y confía en las medidas del lado de la carga (van en la sección siguiente) para alargar la vida de la batería.

Solución de hardware: enchufes inteligentes y carga programada

La manera más confiable de mantener un celular 24/7 en el rango ideal de 20–80% es controlar la entrada de energía en vez de depender del software. Algunos celulares tienen un tope de carga nativo (los Pixel 6a+ de Google ofrecen “Límite al 80%”, Samsung One UI 6.1+ tiene “Protección de la batería”, Sony tiene “Battery Care”, Xiaomi expone un tope oculto al 80% en HyperOS en modelos seleccionados), pero la mayoría no, y aun donde existe, la implementación puede ser inconsistente.

Un enchufe inteligente, o sea un toma corriente controlado por Wi-Fi, resuelve esto de forma genérica. El enchufe enciende y apaga el cargador según un horario. El celular reporta su estado de carga por la red (o aparece en cualquier dashboard de gestión de flota), y un bucle simple carga hasta ~80%, queda en reposo y reanuda cuando el SoC baja a ~30%.

Setups prácticos:

• Enchufes inteligentes comerciales. TP-Link Tapo, Sonoff y enchufes Wi-Fi similares cuestan entre USD 5 y 15 cada uno y se integran con la mayoría de las plataformas de domótica. El enfoque crudo es un horario fijo (cargar 4 horas, apagado 8 horas), que alcanza como primer pase pero no sigue el SoC real.
• Firmware Tasmota o ESPHome. Flashear un enchufe inteligente con firmware abierto permite controlarlo vía MQTT o una API HTTP local, lo que deja a un script consultar el nivel real de batería del celular y alternar el enchufe.
• Home Assistant. Si Home Assistant ya corre, la integración es directa: un sensor de batería (vía un script ADB o una app dedicada de broadcast de batería) lee el SoC, y una automatización alterna el enchufe en los umbrales.
• Cortes DIY en la línea USB. Un relé en la línea de alimentación USB, controlado por un ESP32 o una Raspberry Pi, puede hacer lo mismo más cerca del equipo. Es lo más barato a escala pero lo más frágil.

Para la receta universal (un enchufe inteligente más un script ADB chico que lee el SoC del celular y alterna el enchufe en 30% y 80%), que funciona en cualquier modelo Android tenga o no un tope nativo del OEM, mira la sección de enchufe inteligente + script ADB en la guía de ahorro de energía del sistema .

Aviso: mantener el celular activo Algunos celulares entran en sueño profundo o hibernan cuando se desconecta el cargador, aun con la pantalla encendida. Prueba el modelo específico: confirma que el celular siga sirviendo tráfico de proxy cuando el enchufe inteligente está en la porción “apagada” del ciclo. Si no, puede hacer falta una app de wakelock, o intervalos de apagado más cortos.

Un horario razonable para la mayoría de los celulares: cargar al 80% (típicamente 1 a 2 horas desde 30%), reposar hasta que el SoC baje a 30% (típicamente 8 a 12 horas de tráfico normal del proxy), y volver a cargar. Eso da 2 o 3 ciclos parciales por día en el rango de voltaje suave, en lugar de flotar constante a 4,20V.

Checklist práctico de longevidad para operadores de proxy

Configura cada celular una vez, idealmente antes de que entre en producción:

1. Limita la carga al 80% por cualquier medio disponible: interruptor nativo del OEM (Pixel 6a+, Samsung One UI 6.1+) o un horario de enchufe inteligente. La receta ADB universal funciona en cualquier modelo.
2. Evita que el SoC baje del 20%. Si la carga de tráfico drena el celular más rápido de lo que el cargador puede sostener, eso es un problema de cableado o de potencia del cargador que vale la pena resolver antes de que la celda empiece a dañarse.
3. Desactiva el Ahorro de batería y la Batería adaptable al nivel del sistema operativo. Mira la guía de batería del lado sistema .
4. Pon iProxy y OpenVPN en “Sin restricciones” en los ajustes de batería por app, más autostart, más bloqueo en segundo plano. Paso a paso por versión: desactivar la optimización de batería de Android para iProxy y OpenVPN .
5. Saca la app de proxy de los asesinos específicos del OEM según la tabla de arriba. Xiaomi: autostart encendido, bloquear en Recientes. Samsung: sueño profundo apagado, app que nunca duerme encendida. Realme/Oppo: keep alive encendido. Huawei: app protegida encendida.
6. Bloquea el Wi-Fi en siempre encendido cuando esté enchufado, nunca dormido.
7. Elige equipos con tope nativo al 80% cuando puedas. La página de dispositivos Android recomendados para iProxy marca los Pixel 8/9 y los Galaxy recientes justo por esa función.
8. Carga lento. Usa un adaptador de pared de 1A o 1,5A, no un cargador rápido de 3A, para operación enchufada. Menor corriente significa menor temperatura y menos estrés sobre la celda.
9. Gestiona la temperatura. No apiles celulares pegados. No los pongas encima del router, del módem ni al sol directo. Apunta a aire ambiente alrededor de los celulares, idealmente por debajo de 25°C. La ventilación importa; mira la sección de higiene de flota en la guía para armar una red de proxies 4G .
10. Audita cada trimestre. Las actualizaciones de Android pueden reactivar funciones que habías desactivado. Revisa cada 90 días. El checklist de ajustes de conexión cubre la higiene operativa más amplia que va de la mano con esta auditoría.

Cuándo jubilar un celular

Incluso con el mejor cuidado, una batería es consumible. El umbral práctico de retiro para un celular proxy es cuando la capacidad cae por debajo del 70% del valor nuevo. Por debajo de ahí pasan tres cosas:

• El voltaje cae más bajo carga, causando cortes intermitentes sobre todo en picos de tráfico.
• La celda se calienta más rápido, acelerando su propio deterioro.
• El hinchamiento físico se vuelve probable. Una celda hinchada puede levantar la pantalla, la tapa trasera o, en casos raros, perforarse e incendiarse.

La mayoría de los celulares Android reporta la salud de la batería en los ajustes o vía ADB (dumpsys battery). Un operador de proxy con flota debería trackear la salud mensualmente y rotar celulares antes de que empiece el hinchamiento. Un celular jubilado al 70% y revendido o reasignado es un costo planificado; un celular que revienta la pantalla al 50% es un costo planificado más un equipo destruido. Elegir el hardware correcto desde el inicio paga dividendos acá: la lista de dispositivos recomendados de iProxy lleva control de modelos con soporte de OS largo, menús de batería predecibles y el tope nativo del 80% que hace más fácil todo lo de este artículo.

Números de referencia

Las recomendaciones de este artículo (limitar al 80%, evitar el float al 100%, carga lenta, gestionar la temperatura, configurar Android para que no interrumpa el proxy) no son buenas prácticas arbitrarias. Cada una responde a un mecanismo de degradación específico que escala exponencialmente con el voltaje o la temperatura: crecimiento de la SEI, disolución de metales de transición del cátodo, oxidación del electrolito, escalado térmico tipo Arrhenius. Las celdas son genuinamente sensibles al voltaje y la temperatura, de maneras que el indicador de porcentaje en la pantalla no expone.

Dos puntos de referencia para anclar el costo-beneficio. Tómalos como estimaciones de planificación de flota, no como una garantía para cada química de celda: la línea base viene de las tablas de almacenamiento y voltaje de carga del BU-808, mientras que el escenario de proxy 24/7 le suma encima variables reales de calor, cargador rápido y Android desatendido.

• Un celular proxy 24/7 con ajustes de Android por defecto, enchufado a un cargador rápido, al 100% todo el tiempo, en una pila tibia: típicamente pierde entre 30% y 40% de su capacidad inicial en 12 meses.
• El mismo celular limitado al 80%, cargado lento con un enchufe inteligente, con los ahorradores del OS desactivados y los asesinos del OEM en la whitelist, en una sala a 22°C con ventilación: típicamente conserva 90% o más de su capacidad inicial a los 12 meses, y es probable que siga por encima del umbral de retiro del 70% a los 36 meses.

El costo de configuración es bajo: un enchufe inteligente por equipo, una auditoría única de ajustes por modelo de celular, más los interruptores por app y a nivel sistema cubiertos en la guía Sin restricciones por app y en la guía del ahorrador de batería del lado sistema . La diferencia de costo de capital entre reemplazar un celular cada 12 meses y reemplazarlo cada 30 a 36 meses escala linealmente con la flota, y en cualquier flota de más de cinco equipos paga el tiempo de configuración antes del primer trimestre.