Mobile Proxy Phone Battery Longevity: A 24/7 Operator Guide

Key Takeaway: A 24/7 mobile-proxy phone’s battery dies from calendar aging at high state of charge, not from cycle count. Cap charging at 80% via a built-in OEM toggle or a smart plug + ADB script , mark iProxy and OpenVPN as Unrestricted , disable Android Battery Saver and Adaptive Battery , and keep ambient temperature below 25°C. Done together, these measures take a typical Android proxy phone from losing 30–40% of capacity in 12 months to retaining 90%+ at 12 months: a 2–3× extension of fleet hardware life.

Why battery health is the limiting factor for 24/7 proxy phones

Mobile proxy phone battery longevity is the single largest predictable cost in any 24/7 Android proxy operation. Mobile proxies run on real Android phones, plugged into mains power around the clock, and the phone is consumable hardware. On the timescale of a year or two of 24/7 use, the battery is the component that decays first. A typical lithium-ion cell loses 25 to 40 percent of its initial capacity in 12 to 18 months of unmanaged charging. The phone keeps booting, but it heats up under load, drops proxy connections more frequently, and eventually swells enough that the chassis or screen separates.

The lab baseline already explains why. Battery University’s BU-808 storage table estimates that cobalt-based Li-ion stored at 25°C retains about 80% capacity after one year at 100% charge, versus 96% at 40% charge; at 40°C, the 100% case falls to 65% after one year.

For a fleet of any size, that turnover is the largest predictable cost in mobile proxy operations. The aging mechanisms behind it are well understood and respond to operator-controllable variables: the upper voltage limit at which the cell sits, the time spent at that voltage, and the operating temperature.

This article covers the electrochemistry of how lithium-ion cells age, the implications for 24/7 operation, the Android-side configuration tradeoffs (many “battery saver” features actively reduce proxy uptime), and the hardware tools available for managing charging on a phone-based proxy farm.

How a lithium-ion cell actually works

A lithium-ion cell has three functional parts: a graphite anode, a cathode of lithium-cobalt-oxide or a related compound, and an electrolyte solution that lets lithium ions shuttle between them. There is also a separator that prevents the electrodes from short-circuiting, and a current collector on each side: copper on the anode, aluminum on the cathode.

When the cell charges, electrical force pushes lithium ions out of the cathode lattice and into the graphite anode. The ions slot between the carbon layers in a process called intercalation. When the cell discharges, the ions migrate back, and the energy released as they return to the cathode flows out through the external circuit as electric current.

The state of charge (SoC) of the cell, meaning how full it is, corresponds to how much lithium currently sits in the anode versus the cathode. At 100% SoC, the anode is nearly saturated. At 0% SoC, the cathode is nearly saturated.

The cell voltage is what the phone measures and reports as a percentage. But voltage is not linear with SoC. The relationship is closer to a stretched-out S-curve, and that nonlinearity is the single most important fact in this article.

The voltage curve and the 80% knee

Plot voltage against SoC for a typical lithium-ion cell and three regions appear:

• Below ~20% SoC: voltage drops steeply from about 3.4V toward the cutoff at 3.0V. Below 3.0V, the cell shuts down to protect itself.
• Between ~20% and ~80% SoC: voltage rises gently from about 3.6V to about 4.05V. This is the gentle, working part of the curve.
• Above ~80% SoC: voltage rises sharply from 4.05V to the hard ceiling of 4.20V (some chemistries push to 4.35V, but the principle is the same).

The transition above 80% is often called the “knee” of the curve. It is not a marketing line, it is where the electrochemistry shifts from comfortable to stressed. Two things happen as the cell pushes past the knee:

1. The graphite anode becomes nearly fully packed with lithium. The lattice is mechanically swollen, like a sponge held just at the edge of bursting. Each additional ion intercalating costs more strain and creates more risk of structural defects.
2. The voltage approaches the electrochemical stability window of the electrolyte. At 4.20V, the electrolyte is at the edge of where its molecules can survive without decomposing. Above that, side reactions accelerate exponentially.

Why the curve matters more than the percentage When the phone shows “100%”, the cell is at roughly 4.20V. When it shows “80%”, the cell is at roughly 4.05V. That is a 0.15V difference for what looks on screen like a 20% gap, and 0.15V translates to a roughly 2 to 3× difference in aging rate; BU-808 summarizes the same relationship as roughly doubled cycle life for each 0.10V reduction in peak charge voltage below 4.20V/cell.

Why high state of charge accelerates aging

The dominant aging mechanism at high SoC is solid electrolyte interphase (SEI) growth. The SEI is a thin film that forms on the anode the first time the cell is charged. It is actually a useful layer: it protects the anode from continuous reaction with the electrolyte. But it is not stable. At high voltage, the electrolyte slowly decomposes at the SEI surface, thickening it and consuming a small amount of cyclable lithium each time. That lithium is now trapped, and the cell’s usable capacity drops.

SEI growth follows a roughly Arrhenius relationship with voltage and temperature. As a rule of thumb, each 0.1V reduction in maximum charge voltage roughly doubles the cycle life of the cell; the same voltage sensitivity also reduces calendar-aging stress. Temperature moves in the same direction: every 10°C reduction in operating temperature is a meaningful life extender rather than a cosmetic change.

There is a second mechanism on the cathode side. At high voltage, transition metals such as cobalt, manganese, and nickel can dissolve out of the cathode lattice into the electrolyte, migrate to the anode, and deposit on its surface. This poisons the SEI and accelerates further degradation. This is why cells charged habitually to 100% can lose capacity faster than cycle-count alone would predict.

Calendar aging, meaning degradation as a function of time, voltage, and temperature regardless of whether the cell is being cycled, is the single most important variable for a phone that lives plugged in. BU-808’s storage table gives the operator-facing number: a Li-ion cell stored at 100% SoC at 25°C retains about 80% after one year, while the same table reports about 96% remaining at 40% SoC. A peer-reviewed calendar-aging study of Li-ion cells reaches the same directional conclusion: 100% storage SoC has a large impact, while the influence is small below 80%.

For a 24/7 proxy phone, the implication is direct: leave it plugged in at 100% and calendar aging will dominate. The phone barely cycles, since it is always full, so there is no cycle-count mileage being earned in exchange.

Why deep discharge is also damaging

The mirror-image problem at low SoC is less talked about, but it is real.

Below ~20% SoC, the cathode is almost fully packed with lithium and its crystal structure becomes unstable. In cobalt-rich cathodes, oxygen atoms can start releasing from the lattice. Below 2.5V, well below the phone’s “0%” cutoff, the copper current collector on the anode side begins to dissolve into the electrolyte. Once the cell drops that low, dendritic deposits can form on subsequent recharges, raising internal resistance and creating short-circuit risk.

The phone’s firmware shuts the cell off well before this happens, typically at 3.0V cell voltage, which corresponds to the displayed “0%”. But repeated cycling close to the cutoff still applies stress, and a cell that gets to 5% routinely will age faster than one that bottoms out at 30%.

The window between 20% and 80% SoC is the structurally and electrochemically least stressful regime for both electrodes. That is the entire reason for the “20-80 rule” repeated in battery research.

The 79→80% vs 99→100% paradox

A common point of confusion: if the phone is set to charge only to 80%, is it not constantly cycling between 79% and 80%? Why is that better than cycling between 99% and 100%?

The answer is that the percentage swing does not matter. What matters is the voltage at which the swing happens.

A 79→80% cycle moves the cell between roughly 4.00V and 4.05V. SEI growth at this voltage is slow. Electrolyte decomposition is slow. The graphite lattice has room to flex. The cell experiences this as a gentle micro-cycle.

A 99→100% cycle moves the cell between roughly 4.17V and 4.20V. SEI growth here is multiple times faster. Electrolyte oxidation rate is exponentially higher. The graphite lattice is at maximum stress. Even a 1% top-up at this level applies disproportionate damage.

In practical terms, a phone capped at 80%, which spends most of its life micro-cycling around the 4.00V mark, can outlast an unconstrained phone by a factor of 2 to 5. BU-808’s charge-voltage table estimates 300–500 cycles at 4.20V/cell, 600–1,000 at 4.06V/cell, and 1,200–2,000 at 3.92V/cell, which is exactly the range that matters when a proxy phone stops floating at 100%.

What kills batteries in 24/7 proxy operation, in order

For a phone living plugged in as a proxy node, the dominant aging mechanisms in rough order of impact are:

1. Calendar aging at high SoC. Sitting at 100% for hours or days is the worst pattern. Float voltage at 4.20V drives steady SEI growth.
2. Heat. BU-808’s storage table estimates about 80% remaining after one year at 25°C and 100% charge, but only 65% remaining at 40°C and 100% charge. A phone in a stack, near a wall, in summer, with no airflow is operating in the expensive part of that curve.
3. High C-rate charging. Fast charging warms the cell and stresses the electrodes. For 24/7 operation, slow charging at 0.3 to 0.5C is far better than fast charging.
4. Deep discharges. Less critical for plugged-in phones, but if the phone drops to 5% during occasional power blips, those events accumulate damage faster than the same phone bottoming at 30%.
5. Cycle count. This is what cycle-life specs measure, but for an always-plugged-in phone it is almost irrelevant. The phone barely cycles, and calendar effects dominate.

A useful mental model: think of every minute the phone spends above 4.10V cell voltage as expensive, every minute between 3.7V and 4.05V as cheap, and every minute below 3.4V as expensive again.

Android battery features and their effect on proxy uptime

Two pieces of mental model help here.

The first is the App Standby Bucket system, introduced in Android 9 and tightened in every release since. Every app sits in one of five buckets (active, working_set, frequent, rare, or restricted) based on how often the user interacts with it. Apps in the lower buckets get progressively fewer jobs, alarms, and (in rare and restricted) network access. The Adaptive Battery feature, also from Android 9, layers a machine-learning model on top of bucket assignment. Doze mode (Android 6) sits underneath all of this and defers background network and CPU when the phone is idle and stationary.

The second is the foreground service contract. An app holding a foreground service with a visible persistent notification is treated by the OS as user-perceptible work, and most bucket-based restrictions are suspended while the service runs. iProxy, like every long-running networking app, relies on a foreground service to stay reachable.

A useful caveat from the official Android Standby Bucket documentation: “These restrictions apply only while the device is on battery power. While the device is charging, the system doesn’t impose these restrictions.” That carve-out is why a phone that spends every minute plugged into a wall outlet generally runs the proxy fine even when it would otherwise be in the rare or frequent bucket. It is also why a phone on smart-plug cycled charging, which alternates between charging and not, can suddenly hit bucket restrictions during off-charging windows. And it is why two specific changes apply regardless of charging state: the Android 12 restricted bucket and the Android 15 foreground service cap.

What follows is a version-by-version summary of the changes that matter for a 24/7 proxy app, focused on what an operator needs to do.

Looking for the click-by-click steps? The version-by-version subsections below explain what changed in each release and why. For the actual taps required to set both the iProxy app and the OpenVPN for Android tunnel app to “Unrestricted” on each Android version, with screenshots, see how to disable Android battery optimization for iProxy and OpenVPN . For the system-side toggles (Battery Saver, Adaptive Battery, 80% charge cap), see the companion guide on disabling Android Battery Saver and the 80% charge limit on proxy phones .

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

• App Standby Buckets and Adaptive Battery are introduced. Apps in lower buckets get jobs and alarms throttled progressively.
• Apps targeting Android 9 must request the FOREGROUND_SERVICE permission. Without it, starting a foreground service throws SecurityException.
• Notifications from suspended apps are hidden until the app resumes, rather than being cancelled outright.

For a plugged-in proxy phone running Android 9, none of this is fatal as long as the app holds a foreground service.

Android 10 (API 29): Background activity start restrictions

• Apps in the background can no longer launch activities, with a small exemption list (notification trampolines, accessibility, etc.).
• Background location now requires a separate runtime permission (ACCESS_BACKGROUND_LOCATION), distinct from foreground location.

A proxy app does not typically launch activities from background, so the impact is minor. The change matters only if the app brings its UI back from a remote command.

Android 11 (API 30): Auto-reset permissions, WorkManager required

• Runtime permissions are auto-reset for apps the user has not interacted with for “a few months”. Predecessor to Android 12’s full app hibernation.
• Firebase JobDispatcher and GcmNetworkManager are disabled for apps targeting API 30+. WorkManager is the only supported scheduler.
• Background location can no longer be requested via a runtime dialog. The user has to grant it from Settings explicitly.

For a proxy app the user installs once and never visibly reopens, the auto-reset is a real risk. Either the user must visibly interact every few months, or hibernation must be disabled per-app (the toggle arrives in Android 12).

Android 12 (API 31): App hibernation, restricted bucket, FGS-from-background ban

This is the first version where multiple changes can break a 24/7 proxy on a phone that is otherwise plugged in continuously.

• App hibernation. Builds on Android 11’s auto-reset. Apps unused for several months have permissions revoked and are placed in a hibernation state where they cannot run in the background until reopened. Per-app toggle: Settings → Apps → iProxy → toggle off “Pause app activity if unused” (or the equivalent OEM label).
• Restricted standby bucket. A new fifth bucket beneath rare. Restrictions apply even when charging: at most one job per day in a 10-minute batched session, one alarm per day (exact or inexact), and severe network throttling. Trigger: the user does not interact with the app for 45 days, or the app is flagged for excessive broadcasts or bindings.
• Foreground services cannot be started from background. Apps targeting Android 12+ can no longer start a foreground service while the app itself is in the background, except for a small exempt list (alarms, push messages, accessibility services, notification taps). The proxy’s foreground service has to start from a context the OS considers foreground (boot completion, exact alarm, user interaction).
• Phantom process limit. 32 child processes per app. Affects apps that spawn many subprocesses; a single-process proxy app rarely hits it.

Operator actions on Android 12+: disable hibernation explicitly for the proxy app, ensure the FGS is started from a permitted context, and visibly reopen the app at least every couple of months to keep it out of the rare bucket and away from the 45-day restricted-bucket trigger.

Android 13 (API 33): POST_NOTIFICATIONS runtime permission, restricted bucket tightening

• POST_NOTIFICATIONS as a runtime permission. Apps targeting API 33+ must request it before showing ordinary notifications. The Android notification permission docs make one important distinction for foreground services: if the user denies the permission, foreground-service notices still appear in Task Manager, but not in the notification drawer. That means the service does not become an ordinary background service solely because the notification permission was denied, but the operator loses the persistent drawer signal used to notice drops and restarts.
• Restricted bucket trigger reduced from 45 days to 8 days for apps targeting Android 13+. A proxy app the user does not visibly open for one week of normal calendar time can drop into restricted.
• BOOT_COMPLETED suppressed in user-set “restricted” battery state. The Android docs note: “If the user places your app in the restricted state for background battery usage while your app targets Android 13, the system doesn’t deliver the BOOT_COMPLETED broadcast or the LOCKED_BOOT_COMPLETED broadcast until the app is started for other reasons.” Boot-time autostart is not guaranteed in this state.
• Task Manager UI lets users see and stop foreground services from the notification shade, regardless of the notification permission grant.

Operator actions on Android 13+: grant POST_NOTIFICATIONS at first install for visibility and diagnostics, set the proxy app to “Unrestricted” in per-app battery settings, and accept that the 8-day window means the app must be visibly active periodically, either through normal use or an external watchdog (ADB script + cron) that reopens the app on a fixed schedule.

Android 14 (API 34): Mandatory foreground service types, JobScheduler ANRs

• Mandatory foreground service type declaration. Every long-running foreground service must declare its type in the manifest: dataSync, mediaPlayback, connectedDevice, specialUse, shortService, health, remoteMessaging, etc. Apps that do not declare a type get killed; misdeclared apps can be flagged by Google Play policy.
• JobScheduler ANR enforcement. If onStartJob or onStopJob runs too long on the main thread, the system raises an ANR (“No response to onStartJob”). Previously these failed silently.
• ACCESS_NETWORK_STATE required for JobScheduler calls that use setRequiredNetworkType() or setRequiredNetwork(). Missing it throws SecurityException.

The big one for proxy apps is the foreground service type declaration. Picking the wrong type now affects what restrictions apply, including the Android 15 6-hour cap covered next.

Android 15 (API 35): The 6-hour foreground service cap

• For apps targeting Android 15, the foreground service types dataSync and the new mediaProcessing are subject to a cumulative 6-hour limit per 24-hour window, per Android’s foreground-service timeout docs . After 6 hours of FGS runtime, the system invokes Service.onTimeout(), and if the service does not call stopSelf() within seconds, throws RemoteServiceException (“A foreground service of type dataSync did not stop within its timeout”).
• After the quota is exhausted, attempting to start another dataSync (or mediaProcessing) FGS throws ForegroundServiceStartNotAllowedException with the message “Time limit already exhausted for foreground service type dataSync”.
• The 6-hour budget resets when the user brings the app to foreground. For a 24/7 proxy node, that does not happen on its own.
• Foreground service types not subject to the 6-hour cap include specialUse, connectedDevice, mediaPlayback, camera, phoneCall, microphone, and location (subject to current Google Play policy on appropriate use of each type).

For a proxy app this is the change most likely to break a 24/7 setup. The mitigation is to declare a non-capped FGS type appropriate for the app’s purpose. iProxy’s traffic-forwarding role fits specialUse or connectedDevice more cleanly than dataSync, which Google intends for periodic sync of user data rather than always-on traffic forwarding.

Android 16 (API 36): JobScheduler quota tightening

• Standby-bucket-based job runtime quotas are now enforced for the active bucket as well, not only the lower buckets, per the Android 16 behavior-change docs .
• Top-state and FGS-concurrent job quotas. Jobs that start while the app is visible and continue after it becomes invisible, plus jobs running concurrently with a foreground service, now adhere to runtime quotas they previously bypassed.
• JobInfo.setImportantWhileForeground is fully deprecated and ignored.
• scheduleAtFixedRate only catches up one missed execution after the app returns to a valid lifecycle. Previously, all missed executions ran immediately.
• A new STOP_REASON_TIMEOUT_ABANDONED distinguishes jobs that were not properly cleaned up from ordinary timeouts.

For a proxy app that uses jobs alongside the main FGS, the practical effect is that jobs cannot rely on FGS-concurrent execution for unlimited runtime. Long work belongs inside the FGS itself, or inside a user-initiated data transfer job.

Android 17 (API 37): Background activity launches further restricted

• Background Activity Launch (BAL) tightened. Apps that previously used MODE_BACKGROUND_ACTIVITY_START_ALLOWED need to migrate to MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, or accept that background activity starts will be blocked.
• Background audio hardening. Audio playback, audio focus, and volume APIs now require either an FGS with while-in-use capability or exact alarm permission with USAGE_ALARM audio streams. Mostly relevant to media apps.

For a typical proxy app, Android 17 is mostly invisible: confirm targetSdkVersion is current and that the app does not rely on launching activities from the background.

OEM-specific killers (orthogonal to Android version)

Independent of stock Android, OEM skins ship aggressive battery management that ranges from tolerable (stock Pixel) to outright hostile (Huawei). The patterns and per-vendor fixes:

A few notes on the worst offenders. Xiaomi MIUI and HyperOS ship with autostart denied for everything outside system apps, so without an explicit autostart toggle the proxy app simply does not start after a reboot. Samsung One UI keeps a hidden Sleeping apps list that auto-grows: a proxy app the operator hasn’t manually opened can land on it weeks later even after the initial setup looks right. Huawei EMUI and HarmonyOS historically required marking an app as “protected” through a separate Battery Manager screen; without that, the system cleaner will kill it within minutes of being put in background.

The community-maintained dontkillmyapp.com project tracks the worst offenders and per-OEM mitigations, scored on a 1–5 scale, and is worth bookmarking for any operator running mixed fleets. For the Android-version-side companion to this table (Battery Saver, Adaptive Battery, the 80% charge cap on Pixel and Samsung), see the system-side power saving guide .

Wi-Fi sleep policy

Some phones disconnect Wi-Fi when the screen is off to save battery. For a proxy this is fatal: the phone falls back to mobile data only, or drops the proxy connection entirely. Lock Wi-Fi to “always on” or “never disconnect when plugged in”, typically under Settings → Wi-Fi → Advanced → Keep Wi-Fi on during sleep.

What to do, in order of importance

1. Disable Battery Saver entirely. Do not let it auto-trigger. See the per-version walkthrough .
2. Set the iProxy app and any VPN tunnel app it relies on to “Unrestricted” (or “Don’t optimize”) in per-app battery settings. The path differs per Android version; for the click-by-click flow on every version from 9 through 16, see the per-app Unrestricted walkthrough .
3. Grant POST_NOTIFICATIONS at first install (Android 13+).
4. Disable app hibernation and “pause when unused” for the proxy app (Android 12+).
5. Whitelist the proxy app from OEM-specific killers per the table above. Xiaomi: autostart on, lock in recents. Samsung: deep sleep off, never sleeping app on. Realme/Oppo: keep alive on. Huawei: protected app on.
6. Never force-stop the proxy app from the app info screen. On Android 15+, the stopped state persists until direct or indirect user action and cancels pending intents; launch the app again if this happens.
7. Confirm the proxy app’s foreground service type is not subject to the 6-hour cap (Android 15+, target SDK 35+ apps).
8. Lock Wi-Fi to always-on when plugged in.
9. Disable Adaptive Battery, or accept that it may deprioritize the proxy app and audit periodically.
10. Disable Data Saver and any “restrict background data” toggles.
11. Visibly reopen the proxy app every few weeks to keep it out of the rare and restricted buckets (especially Android 13+, which trips at 8 days unused).

The general rule If a setting promises to save battery by limiting background activity, it will hurt proxy uptime. Proxies are background activity. Disable everything in this category, and rely on charging-side measures (covered next) to extend battery life instead.

Hardware solution: smart plugs and scheduled charging

The most reliable way to keep a 24/7 phone in the 20–80% sweet spot is to control the power input rather than rely on software. Some phones have a built-in charge cap (Google’s Pixel 6a+ offers “Limit to 80%”, Samsung One UI 6.1+ has “Battery protection”, Sony has “Battery Care”, Xiaomi exposes a hidden 80% charge limit in HyperOS on selected models), but most do not, and even where they do, the implementation can be inconsistent.

A smart plug, meaning a Wi-Fi controlled mains outlet, solves this generically. The plug switches the charger off and on according to a schedule. The phone reports its state of charge over the network (or it shows up in any fleet-management dashboard), and a simple loop charges to ~80%, idles, and resumes when SoC drops to ~30%.

Practical setups:

• Off-the-shelf smart plugs. TP-Link Tapo, Sonoff, and similar Wi-Fi plugs cost $5 to $15 each and integrate with most home automation platforms. The crude approach is a fixed schedule (charge for 4 hours, off for 8 hours), which is good enough as a first pass but does not track actual SoC.
• Tasmota or ESPHome firmware. Flashing a smart plug with open firmware allows control via MQTT or a local HTTP API, which means a script can poll the phone’s actual battery level and toggle the plug.
• Home Assistant. If Home Assistant is already running, the integration is straightforward: a battery sensor (via an ADB script or a dedicated battery-broadcast app) reads SoC, and an automation toggles the plug at thresholds.
• DIY USB-line cutoffs. A relay on the USB power line, controlled by an ESP32 or Raspberry Pi, can do the same thing closer to the device. This is the cheapest at scale but the most fragile.

For the universal recipe (a smart plug plus a small ADB script that reads SoC from the phone and toggles the plug at 30% and 80%), which works on any Android model regardless of whether the OEM ships a built-in cap, see the smart plug + ADB script section in the system-side power saving guide .

Caveat: keep the phone running Some phones go to deep sleep or hibernate when the charger is disconnected, even with the screen on. Test the specific model: confirm the phone still serves proxy traffic when the smart plug is in its “off” portion of the cycle. If it does not, a wakelock app may be needed, or the off intervals may need to be shorter.

A reasonable target schedule for most phones: charge to 80% (typically 1 to 2 hours from 30%), idle until SoC drops to 30% (typically 8 to 12 hours of normal proxy traffic), then charge again. This produces 2 to 3 partial cycles per day in the gentle voltage range, instead of constant float at 4.20V.

A practical longevity checklist for proxy operators

Configure each phone once, ideally before it goes into production:

1. Cap charging at 80%, by whatever means available: built-in OEM toggle (Pixel 6a+, Samsung One UI 6.1+) or a smart plug schedule. The universal ADB recipe works on any model.
2. Avoid letting SoC fall below 20%. If the traffic load drains the phone faster than the charger can keep up, that is a wiring or charger-power problem worth solving before the cell starts taking damage.
3. Disable Battery Saver and Adaptive Battery at the OS level. See the system-side battery guide .
4. Set the iProxy app and OpenVPN to “Unrestricted” in per-app battery settings, plus autostart, plus background lock. Per-version walkthrough: disable Android battery optimization for iProxy and OpenVPN .
5. Whitelist the proxy app from OEM-specific killers per the table above. Xiaomi: autostart on, lock in recents. Samsung: deep sleep off, never sleeping app on. Realme/Oppo: keep alive on. Huawei: protected app on.
6. Lock Wi-Fi to always-on when plugged in, never sleep.
7. Pick devices that ship a built-in 80% cap when you can. The recommended Android devices for iProxy page flags Pixel 8/9 and recent Galaxy models specifically for this feature.
8. Slow-charge. Use a 1A or 1.5A wall adapter, not a 3A fast charger, for plugged-in operation. Lower current means lower temperatures and less stress on the cell.
9. Manage temperature. Do not stack phones tightly. Do not park them on top of routers, modems, or in direct sun. Aim for ambient air around the phones, ideally below 25°C. Airflow matters; see the fleet-hygiene section of the 4G proxy network setup guide .
10. Audit quarterly. Phone OS updates can re-enable disabled features. Check every 90 days. The connection-settings checklist covers the broader operator hygiene that pairs with this audit.

When to retire a phone

Even with the best care, a battery is consumable. The practical retirement threshold for a proxy phone is when capacity drops below about 70% of the new value. Below that, three things tend to happen:

• Voltage sags more under load, causing intermittent dropouts especially during traffic spikes.
• The cell heats up faster, accelerating its own decline.
• Physical swelling becomes likely. A swollen cell can pop the screen, the back cover, or in rare cases puncture and ignite.

Most Android phones report battery health in settings or via ADB (dumpsys battery). A proxy operator running a fleet should track health monthly and rotate phones out before swelling starts. A phone retired at 70% capacity and resold or repurposed is a planned cost; a phone that swells a screen at 50% is a planned cost plus a destroyed device. Picking the right hardware in the first place pays off here: the iProxy recommended devices list tracks models with long OS support, predictable battery menus, and the built-in 80% cap that makes everything in this article easier.

Reference numbers

The recommendations in this article (cap at 80%, avoid 100% float, slow-charge, manage temperature, configure Android so it does not interrupt the proxy) are not arbitrary best practices. Each one corresponds to a specific degradation mechanism that scales exponentially with voltage or temperature: SEI growth, transition-metal dissolution from the cathode, electrolyte oxidation, Arrhenius temperature scaling. The cells are genuinely sensitive to voltage and temperature, in ways the percentage indicator on the screen does not expose.

Two reference points to anchor the cost-benefit. Treat them as fleet-planning estimates, not a guarantee for every cell chemistry: the baseline comes from BU-808’s storage and charge-voltage tables, while the 24/7 proxy scenario adds real-world heat, fast-charger, and unattended-Android variables on top.

• A 24/7 proxy phone configured with default Android settings, plugged into a fast charger, sitting at 100 percent all the time, in a warm stack: typically loses 30 to 40 percent of its initial capacity within 12 months.
• The same phone, capped at 80 percent, slow-charged on a smart plug, with the OS battery savers disabled and OEM killers whitelisted, in a 22°C room with airflow: typically retains 90 percent or more of its initial capacity at 12 months, and is likely to still be above the 70 percent retirement threshold at 36 months.

The configuration cost is small: a smart plug per device, a one-time settings audit per phone model, plus the per-app and system-level toggles covered in the per-app Unrestricted guide and the system-side battery saver guide . The capital cost difference between replacing a phone every 12 months and replacing it every 30 to 36 months scales linearly with the fleet — and on any fleet over five devices, it pays back the configuration time inside the first quarter.