Mobile Proxy Phone Battery Longevity: 24/7 Operator Guide

मुख्य बात: 24/7 mobile proxy phone की battery cycle count से नहीं, बल्कि high state of charge पर calendar aging से मरती है। Charging को 80% पर cap करें: built-in OEM toggle या smart plug + ADB script के ज़रिए, iProxy और OpenVPN को Unrestricted mark करें , Android Battery Saver और Adaptive Battery बंद करें , और ambient temperature 25°C से नीचे रखें। ये सब मिलाकर एक typical Android proxy phone को 12 महीनों में 30–40% capacity loss से 12 महीनों में 90%+ retention तक ले आते हैं: fleet hardware life में 2–3× extension।

24/7 proxy phones के लिए battery health सबसे बड़ा limiting factor क्यों है

Mobile proxy phone battery longevity किसी भी 24/7 Android proxy operation में सबसे बड़ी predictable cost है। Mobile proxies असली Android phones पर चलते हैं, चौबीस घंटे mains power से plugged रहते हैं, और phone एक consumable hardware है। एक-दो साल के 24/7 use की timescale पर battery वह component है जो सबसे पहले decay होता है। एक typical lithium-ion cell unmanaged charging के 12 से 18 महीनों में अपनी initial capacity का 25 से 40 प्रतिशत खो देती है। Phone boot होता रहता है, लेकिन load पर गरम हो जाता है, proxy connections बार-बार drop करता है, और अंततः इतना swell हो जाता है कि chassis या screen अलग हो जाए।

Lab baseline इसका कारण पहले ही explain कर देती है। Battery University की BU-808 storage table का अनुमान है कि 25°C पर stored cobalt-based Li-ion 100% charge पर एक साल बाद करीब 80% capacity रखती है, जबकि 40% charge पर 96%; 40°C पर वही 100% case एक साल बाद 65% तक गिर जाती है।

किसी भी size के fleet के लिए, यह turnover mobile proxy operations में सबसे बड़ी predictable cost है। इसके पीछे के aging mechanisms अच्छी तरह समझे हुए हैं और operator-controllable variables पर response देते हैं: upper voltage limit जिस पर cell बैठती है, उस voltage पर बिताया गया समय, और operating temperature।

यह article cover करता है lithium-ion cells की aging electrochemistry, 24/7 operation के implications, Android-side configuration trade-offs (कई “battery saver” features actually proxy uptime घटाते हैं), और phone-based proxy farm पर charging manage करने के hardware tools।

Lithium-ion cell actually काम कैसे करती है

एक lithium-ion cell के तीन functional parts होते हैं: एक graphite anode, lithium-cobalt-oxide या similar compound का cathode, और एक electrolyte solution जो दोनों के बीच lithium ions को shuttle करने देता है। एक separator भी होता है जो electrodes को short-circuit होने से रोकता है, और हर side पर एक current collector: anode पर copper, cathode पर aluminium।

जब cell charge होती है, electrical force lithium ions को cathode lattice से बाहर graphite anode में push करती है। Ions carbon layers के बीच slot होते जाते हैं, इस process को intercalation कहते हैं। जब cell discharge होती है, ions वापस migrate करते हैं, और cathode पर लौटते वक़्त जो energy release होती है वह external circuit के through electric current बनकर बाहर बहती है।

Cell का state of charge (SoC), यानी कितनी भरी हुई है, इस बात से तय होता है कि अभी कितना lithium anode में है versus cathode में। 100% SoC पर anode लगभग saturated है। 0% SoC पर cathode लगभग saturated है।

Cell voltage वही है जो phone measure करके percentage में report करता है। लेकिन voltage SoC के साथ linear नहीं है। Relationship एक stretched-out S-curve जैसा है, और यही non-linearity इस पूरे article का सबसे important fact है।

Voltage curve और 80% का knee

एक typical lithium-ion cell के लिए voltage बनाम SoC plot करें तो तीन regions नज़र आते हैं:

• ~20% SoC के नीचे: voltage करीब 3.4V से steeply गिरकर 3.0V के cutoff तक पहुँच जाती है। 3.0V के नीचे cell अपनी रक्षा के लिए शट डाउन हो जाती है।
• ~20% और ~80% SoC के बीच: voltage करीब 3.6V से 4.05V तक gently बढ़ती है। यही curve का gentle, working portion है।
• ~80% SoC के ऊपर: voltage 4.05V से sharply बढ़कर hard ceiling 4.20V तक पहुँच जाती है (कुछ chemistries 4.35V तक push करती हैं, पर principle वही है)।

80% के ऊपर के transition को अक्सर curve का “knee” कहते हैं। यह marketing line नहीं है, यह वह जगह है जहाँ electrochemistry comfortable से stressed में shift करती है। Cell knee पार करते ही दो चीज़ें होती हैं:

1. Graphite anode lithium से लगभग पूरा भर जाता है। Lattice mechanically swollen हो जाता है, जैसे एक sponge बस फटने के कगार पर हो। हर अतिरिक्त intercalating ion ज़्यादा strain और structural defects का ज़्यादा risk बनाता है।
2. Voltage electrolyte की electrochemical stability window के पास पहुँच जाती है। 4.20V पर electrolyte वहीं है जहाँ उसके molecules बिना decompose हुए जैसे-तैसे survive कर पाते हैं। उसके ऊपर, side reactions exponentially accelerate होती हैं।

Percentage से ज़्यादा curve क्यों matter करती है जब phone “100%” दिखाता है, cell लगभग 4.20V पर है। जब वह “80%” दिखाता है, cell करीब 4.05V पर है। Screen पर वो 20% gap जैसा दिखता है, असल में 0.15V का फ़र्क है, और यह 0.15V aging rate में लगभग 2 से 3× फ़र्क लाता है; BU-808 इसी relationship को 4.20V/cell से नीचे हर 0.10V कटौती पर cycle life के लगभग double होने के रूप में summarize करता है।

High state of charge aging को क्यों तेज़ करता है

High SoC पर dominant aging mechanism है solid electrolyte interphase (SEI) growth। SEI एक पतली film है जो cell के पहली बार charge होने पर anode पर बनती है। दरअसल यह एक useful layer है: यह anode को electrolyte के साथ continuous reaction से बचाती है। लेकिन यह stable नहीं है। High voltage पर electrolyte धीरे-धीरे SEI surface पर decompose होता है, उसे thicker बनाता है और हर बार थोड़ी cyclable lithium को consume कर लेता है। वह lithium अब trapped है, और cell की usable capacity गिर जाती है।

SEI growth voltage और temperature के साथ लगभग Arrhenius relationship follow करता है। एक rule of thumb: maximum charge voltage में हर 0.1V की कमी cell के cycle life को लगभग double कर देती है; वही voltage sensitivity calendar aging stress भी कम करती है। Temperature भी इसी direction में चलता है: operating temperature में हर 10°C की कमी एक cosmetic change नहीं बल्कि meaningful life extender है।

Cathode side पर एक दूसरा mechanism है। High voltage पर transition metals जैसे cobalt, manganese, और nickel cathode lattice से electrolyte में dissolve हो सकते हैं, anode तक migrate कर सकते हैं, और उसकी surface पर deposit हो सकते हैं। यह SEI को poison करता है और degradation को और तेज़ करता है। इसी वजह से habitually 100% तक charge होने वाली cells cycle count से predict की गई rate से ज़्यादा तेज़ी से capacity खो सकती हैं।

Calendar aging, यानी समय, voltage, और temperature के function के रूप में degradation (चाहे cell cycle हो रही हो या नहीं), एक plugged-in phone के लिए सबसे important variable है। BU-808 की storage table operator के काम का number देती है: 25°C पर 100% SoC पर stored Li-ion cell एक साल बाद लगभग 80% retain करती है, जबकि वही table 40% SoC पर लगभग 96% remaining report करती है। एक peer-reviewed Li-ion cells की calendar-aging study directionally उसी conclusion पर पहुँचती है: 100% storage SoC का बहुत बड़ा impact है, जबकि 80% के नीचे influence small है।

24/7 proxy phone के लिए implication सीधा है: 100% पर plugged छोड़ दीजिए, और calendar aging dominate कर लेगा। Phone barely cycle होता है क्योंकि हमेशा full है, तो बदले में cycle-count mileage भी कुछ नहीं मिल रहा।

Deep discharge भी क्यों damaging है

Low SoC पर इसका mirror-image problem कम discuss होता है, पर असली है।

~20% SoC के नीचे cathode लगभग पूरा lithium से packed है और उसका crystal structure unstable हो जाता है। Cobalt-rich cathodes में oxygen atoms lattice से release होने लगते हैं। 2.5V के नीचे, यानी phone के “0%” cutoff से बहुत नीचे, anode side पर copper current collector electrolyte में dissolve होने लगता है। एक बार cell इतनी नीचे चली जाए, अगले recharges पर dendritic deposits बन सकते हैं, internal resistance बढ़ा सकते हैं, और short-circuit risk पैदा कर सकते हैं।

Phone का firmware ऐसा होने से पहले ही cell को off कर देता है, आम तौर पर 3.0V cell voltage पर, जो displayed “0%” से correspond करता है। लेकिन cutoff के पास बार-बार cycling फिर भी stress डालती है, और जो cell routinely 5% तक जाती है वह 30% पर bottom out होने वाली से तेज़ी से age होगी।

20% और 80% SoC के बीच की window दोनों electrodes के लिए structurally और electrochemically सबसे कम stressful regime है। Battery research में बार-बार दोहराए जाने वाले “20-80 rule” का यही पूरा कारण है।

79→80% vs 99→100% का paradox

एक common confusion: अगर phone सिर्फ़ 80% तक charge करने पर set है, तो क्या यह लगातार 79% और 80% के बीच cycle नहीं हो रहा? यह 99% और 100% के बीच cycle करने से बेहतर क्यों है?

जवाब है: percentage swing matter नहीं करता। जो matter करता है वह है, swing किस voltage पर हो रहा है।

79→80% का cycle cell को लगभग 4.00V और 4.05V के बीच move करता है। इस voltage पर SEI growth slow है। Electrolyte decomposition slow है। Graphite lattice के पास flex करने की जगह है। Cell इसे एक gentle micro-cycle के रूप में experience करती है।

99→100% का cycle cell को लगभग 4.17V और 4.20V के बीच move करता है। यहाँ SEI growth कई गुना तेज़ है। Electrolyte oxidation rate exponentially ज़्यादा है। Graphite lattice maximum stress पर है। इस level पर 1% का top-up भी disproportionate damage करता है।

Practical terms में, 80% पर capped phone (जो अपनी ज़्यादातर ज़िंदगी 4.00V mark के आस-पास micro-cycling में बिताता है) unconstrained phone से 2 से 5 गुना ज़्यादा चल सकता है। BU-808 की charge-voltage table 4.20V/cell पर 300–500 cycles, 4.06V/cell पर 600–1,000, और 3.92V/cell पर 1,200–2,000 cycles का अनुमान देती है, जो exactly वही range है जब proxy phone 100% पर float करना बंद कर देता है।

24/7 proxy operation में batteries को क्या मारता है, order में

Proxy node के तौर पर plugged-in रहने वाले phone के लिए dominant aging mechanisms मोटे तौर पर impact के order में:

1. High SoC पर calendar aging. घंटों या दिनों तक 100% पर बैठना सबसे बुरा pattern है। 4.20V पर float voltage steady SEI growth drive करती है।
2. Heat. BU-808 की storage table 25°C और 100% charge पर एक साल बाद लगभग 80% remaining का अनुमान देती है, पर 40°C और 100% charge पर सिर्फ़ 65%। एक phone जो stack में, दीवार के पास, गर्मियों में, बिना airflow के है, वह उस curve के expensive हिस्से में operate कर रहा है।
3. High C-rate charging. Fast charging cell को warm करती है और electrodes पर stress डालती है। 24/7 operation के लिए 0.3 से 0.5C पर slow charging fast charging से कहीं बेहतर है।
4. Deep discharges. Plugged-in phones के लिए कम critical है, पर अगर occasional power blips के दौरान phone 5% तक चला जाता है, ये events 30% पर bottom out होने वाले phone से तेज़ी से damage accumulate करते हैं।
5. Cycle count. यही वह चीज़ है जो cycle-life specs measure करते हैं, पर एक हमेशा plugged-in phone के लिए यह लगभग irrelevant है। Phone barely cycle होता है, और calendar effects dominate करते हैं।

एक useful mental model: हर वो minute जब phone 4.10V cell voltage के ऊपर है, expensive है; हर वो minute जो 3.7V और 4.05V के बीच है, cheap है; और हर वो minute जो 3.4V के नीचे है, फिर से expensive है।

Android battery features और proxy uptime पर उनका असर

यहाँ दो mental models काम आते हैं।

पहला है App Standby Bucket system, जो Android 9 में introduce हुआ और हर release के साथ tighten हुआ है। हर app पाँच buckets में से एक में बैठता है (active, working_set, frequent, rare, या restricted), user उससे कितनी बार interact करता है उस आधार पर। निचले buckets के apps को progressively कम jobs, alarms, और (rare और restricted में) network access मिलता है। Adaptive Battery feature, भी Android 9 से, इसके ऊपर एक machine-learning model layer करता है। Doze mode (Android 6) इन सबके नीचे बैठता है और जब phone idle और stationary होता है तो background network और CPU defer कर देता है।

दूसरा है foreground service contract। एक app जो visible persistent notification वाला foreground service hold करता है, उसे OS user-perceptible work मानता है, और service running रहते bucket-based restrictions ज़्यादातर suspend रहते हैं। iProxy, हर long-running networking app की तरह, reachable रहने के लिए एक foreground service पर depend करता है।

Official Android Standby Bucket documentation से एक useful caveat: “These restrictions apply only while the device is on battery power. While the device is charging, the system doesn’t impose these restrictions.” यही carve-out वह कारण है जिससे एक phone जो हर minute wall outlet में plugged है वह आम तौर पर proxy ठीक चलाता है, भले ही वरना वह rare या frequent bucket में होता। यह भी कारण है कि smart-plug cycled charging पर एक phone, जो charging और not-charging के बीच alternate करता है, off-charging windows के दौरान अचानक bucket restrictions में जा सकता है। और इसी कारण दो specific changes charging state से बेपरवाह apply होते हैं: Android 12 का restricted bucket और Android 15 का foreground service cap।

आगे आता है 24/7 proxy app के लिए relevant changes का version-by-version summary, एक operator को क्या करना है उस पर focused।

Click-by-click steps चाहिए? नीचे दी version-by-version subsections explain करती हैं कि हर release में क्या बदला और क्यों। हर Android version पर iProxy app और OpenVPN for Android tunnel app को “Unrestricted” set करने के actual taps के लिए, screenshots सहित, देखें iProxy और OpenVPN के लिए Android battery optimization disable कैसे करें । System-side toggles (Battery Saver, Adaptive Battery, 80% charge cap) के लिए companion guide देखें: proxy phones पर Android Battery Saver disable करना और 80% charge limit set करना ।

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

• App Standby Buckets और Adaptive Battery introduce होते हैं। निचले buckets के apps के jobs और alarms progressively throttle होते हैं।
• Android 9 target करने वाले apps को FOREGROUND_SERVICE permission request करनी ज़रूरी है। इसके बिना foreground service start करने पर SecurityException throw होता है।
• Suspended apps की notifications तब तक hidden रहती हैं जब तक app resume न हो; पहले cancel हो जाती थीं।

Android 9 पर चलने वाले plugged-in proxy phone के लिए, जब तक app foreground service hold करता है तब तक यह सब fatal नहीं है।

Android 10 (API 29): Background activity start restrictions

• Background के apps अब activities launch नहीं कर सकते, छोटी सी exemption list के साथ (notification trampolines, accessibility, etc.)।
• Background location को अब एक अलग runtime permission (ACCESS_BACKGROUND_LOCATION) चाहिए, foreground location से अलग।

एक proxy app आम तौर पर background से activities launch नहीं करता, तो impact minor है। यह change तभी matter करता है जब app remote command से अपनी UI वापस लाता हो।

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

• Runtime permissions उन apps के लिए auto-reset होती हैं जिनसे user ने “कुछ महीनों” तक interact नहीं किया। Android 12 के पूर्ण app hibernation का predecessor।
• API 30+ target करने वाले apps के लिए Firebase JobDispatcher और GcmNetworkManager disabled हैं। WorkManager ही supported scheduler है।
• Background location अब runtime dialog से request नहीं हो सकती। User को Settings से explicitly grant करनी होगी।

User एक बार install करके phir visibly कभी न reopen करने वाले proxy app के लिए auto-reset एक real risk है। या तो user हर कुछ महीनों में visibly interact करे, या hibernation per-app disable हो (toggle Android 12 में आता है)।

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

यह पहला version है जहाँ multiple changes एक 24/7 proxy को ऐसे phone पर break कर सकते हैं जो वरना लगातार plugged-in है।

• App hibernation. Android 11 के auto-reset पर बनी है। कई महीनों से unused apps की permissions revoke हो जाती हैं और उन्हें एक hibernation state में डाल दिया जाता है जहाँ वे reopen होने तक background में नहीं चल सकते। Per-app toggle: Settings → Apps → iProxy → “Pause app activity if unused” off करें (या equivalent OEM label)।
• Restricted standby bucket. rare के नीचे एक नया पाँचवाँ bucket। Restrictions charging के दौरान भी apply होते हैं: 10-minute batched session में ज़्यादा से ज़्यादा एक job per day, एक alarm per day (exact या inexact), और severe network throttling. Trigger: user 45 दिनों तक app से interact नहीं करता, या app excessive broadcasts/bindings के लिए flag होता है।
• Foreground services background से start नहीं हो सकतीं. Android 12+ target करने वाले apps तब foreground service start नहीं कर सकते जब app खुद background में हो, एक छोटी exempt list (alarms, push messages, accessibility services, notification taps) को छोड़कर। Proxy का foreground service उस context से start होना चाहिए जिसे OS foreground मानता है (boot completion, exact alarm, user interaction)।
• Phantom process limit. हर app पर 32 child processes। यह उन apps को affect करता है जो बहुत सारे subprocesses spawn करते हैं; एक single-process proxy app इस तक shayad ही पहुँचेगा।

Android 12+ पर operator actions: proxy app के लिए hibernation explicitly disable करें, ensure करें कि FGS एक permitted context से start हो, और हर एक-दो महीने में app को visibly reopen करें ताकि वह rare bucket से बाहर रहे और 45-day restricted-bucket trigger से दूर रहे।

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

• POST_NOTIFICATIONS as a runtime permission. API 33+ target करने वाले apps को ordinary notifications दिखाने से पहले इसे request करना ज़रूरी है। Android notification permission docs foreground services के लिए एक important distinction बताते हैं: अगर user permission deny करता है, तो foreground-service notices अब भी Task Manager में दिखते हैं, पर notification drawer में नहीं। मतलब service सिर्फ़ notification permission deny होने से ordinary background service नहीं बन जाती, पर operator drops और restarts notice करने वाले persistent drawer signal को खो देता है।
• Restricted bucket trigger 45 दिनों से घटकर Android 13+ target करने वाले apps के लिए 8 दिन हो गया। एक proxy app जिसे user normal calendar time के एक week तक visibly open नहीं करता, restricted में जा सकता है।
• User-set “restricted” battery state में BOOT_COMPLETED suppressed. Android docs कहते हैं: “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.” इस state में boot-time autostart guarantee नहीं है।
• Task Manager UI users को notification shade से foreground services देखने और stop करने देता है, चाहे notification permission grant हो या न हो।

Android 13+ पर operator actions: visibility और diagnostics के लिए first install पर POST_NOTIFICATIONS grant करें, per-app battery settings में proxy app को “Unrestricted” set करें, और accept करें कि 8-day window का मतलब है कि app को periodically visibly active रहना होगा, या तो normal use से या एक external watchdog (ADB script + cron) से जो fixed schedule पर app reopen करे।

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

• Mandatory foreground service type declaration. हर long-running foreground service को अपना type manifest में declare करना होगा: dataSync, mediaPlayback, connectedDevice, specialUse, shortService, health, remoteMessaging, etc. Type declare न करने वाले apps killed होते हैं; mis-declared apps को Google Play policy flag कर सकती है।
• JobScheduler ANR enforcement. अगर onStartJob या onStopJob main thread पर बहुत देर तक चले, system ANR raise करता है (“No response to onStartJob”)। पहले ये silently fail होते थे।
• ACCESS_NETWORK_STATE उन JobScheduler calls के लिए ज़रूरी है जो setRequiredNetworkType() या setRequiredNetwork() use करते हैं। Missing होने पर SecurityException throw होता है।

Proxy apps के लिए बड़ी बात है foreground service type declaration। Wrong type pick करना अब affect करता है कि कौन-सी restrictions apply होंगी, including Android 15 का 6-hour cap जो आगे cover होगा।

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

• Android 15 target करने वाले apps के लिए foreground service types dataSync और नया mediaProcessing एक cumulative 6-hour limit per 24-hour window के subject हैं, Android के foreground-service timeout docs के अनुसार। 6 hours FGS runtime के बाद system Service.onTimeout() invoke करता है, और अगर service seconds के अंदर stopSelf() call नहीं करती, तो RemoteServiceException throw होता है (“A foreground service of type dataSync did not stop within its timeout”)।
• Quota exhaust होने के बाद, दूसरा dataSync (या mediaProcessing) FGS start करने की कोशिश ForegroundServiceStartNotAllowedException throw करती है, message: “Time limit already exhausted for foreground service type dataSync”।
• 6-hour budget तभी reset होता है जब user app को foreground में लाए। 24/7 proxy node के लिए यह अपने आप नहीं होता।
• 6-hour cap के subject नहीं हैं ये foreground service types: specialUse, connectedDevice, mediaPlayback, camera, phoneCall, microphone, और location (हर type के appropriate use पर current Google Play policy के subject)।

एक proxy app के लिए यह वह change है जो 24/7 setup को break करने की सबसे ज़्यादा संभावना रखता है। Mitigation है: app के purpose के लिए appropriate non-capped FGS type declare करना। iProxy का traffic-forwarding role dataSync से ज़्यादा cleanly specialUse या connectedDevice में fit होता है; Google ने dataSync का intent user data के periodic sync के लिए रखा है, always-on traffic forwarding के लिए नहीं।

Android 16 (API 36): JobScheduler quota tightening

• Standby-bucket-based job runtime quotas अब active bucket पर भी enforce होते हैं, सिर्फ़ निचले buckets पर नहीं, Android 16 behavior-change docs के अनुसार।
• Top-state और FGS-concurrent job quotas. जो jobs तब start होते हैं जब app visible है और invisible होने के बाद भी continue होते हैं, plus foreground service के साथ concurrently चलने वाले jobs, अब उन runtime quotas के adhere करते हैं जिन्हें वे पहले bypass करते थे।
• JobInfo.setImportantWhileForeground पूरी तरह deprecated और ignored है।
• scheduleAtFixedRate app के valid lifecycle में वापस आने पर सिर्फ़ एक missed execution catch up करता है। पहले सारी missed executions immediately चलती थीं।
• एक नया STOP_REASON_TIMEOUT_ABANDONED उन jobs को ordinary timeouts से distinguish करता है जो properly cleaned up नहीं हुए।

Main FGS के साथ jobs use करने वाले proxy app के लिए, practical effect है: jobs unlimited runtime के लिए FGS-concurrent execution पर rely नहीं कर सकते। Long work FGS के अंदर ही होना चाहिए, या एक user-initiated data transfer job के अंदर।

Android 17 (API 37): Background activity launches और भी restricted

• Background Activity Launch (BAL) tightened. जो apps पहले MODE_BACKGROUND_ACTIVITY_START_ALLOWED use करते थे उन्हें MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE पर migrate करना होगा, या accept करना होगा कि background activity starts block होंगे।
• Background audio hardening. Audio playback, audio focus, और volume APIs को अब या तो while-in-use capability वाली FGS चाहिए या USAGE_ALARM audio streams के साथ exact alarm permission। ज़्यादातर media apps के लिए relevant।

एक typical proxy app के लिए Android 17 mostly invisible है: confirm करें कि targetSdkVersion current है और app background से activities launch करने पर rely नहीं करता।

OEM-specific killers (Android version से orthogonal)

Stock Android से independent, OEM skins aggressive battery management ship करती हैं जो tolerable (stock Pixel) से लेकर outright hostile (Huawei) तक हैं। Patterns और per-vendor fixes:

सबसे बुरे offenders पर कुछ notes। Xiaomi MIUI और HyperOS system apps के अलावा सब के लिए autostart denied ship करती हैं, तो एक explicit autostart toggle के बिना proxy app reboot के बाद simply start नहीं होता। Samsung One UI एक hidden Sleeping apps list रखती है जो auto-grow होती है: एक proxy app जिसे operator ने manually open नहीं किया वह initial setup सही दिखने के हफ़्तों बाद उसमें आ सकता है। Huawei EMUI और HarmonyOS historically एक app को एक अलग Battery Manager screen से “protected” mark करवाते थे; उसके बिना system cleaner background में जाते ही उसे minutes में kill कर देगा।

Community-maintained dontkillmyapp.com project worst offenders और per-OEM mitigations को track करता है, 1–5 scale पर scored, और किसी भी mixed-fleet operator के लिए bookmark करने लायक है। इस table के Android-version-side companion के लिए (Battery Saver, Adaptive Battery, Pixel और Samsung पर 80% charge cap), देखें system-side power saving guide ।

Wi-Fi sleep policy

कुछ phones battery बचाने के लिए screen off होने पर Wi-Fi disconnect कर देते हैं। एक proxy के लिए यह fatal है: phone केवल mobile data पर fall back हो जाता है, या proxy connection पूरी तरह drop हो जाती है। Wi-Fi को “always on” या “never disconnect when plugged in” पर lock करें, आम तौर पर Settings → Wi-Fi → Advanced → Keep Wi-Fi on during sleep के तहत।

क्या करें, importance के order में

1. Battery Saver पूरी तरह disable करें. इसे auto-trigger न होने दें। देखें per-version walkthrough ।
2. iProxy app और जिस भी VPN tunnel app पर वह depend करता है उसे per-app battery settings में “Unrestricted” (या “Don’t optimize”) पर set करें। Path हर Android version पर अलग है; 9 से 16 तक हर version पर click-by-click flow के लिए, देखें per-app Unrestricted walkthrough ।
3. First install पर POST_NOTIFICATIONS grant करें (Android 13+)।
4. App hibernation और proxy app के लिए “pause when unused” disable करें (Android 12+)।
5. ऊपर वाली table के अनुसार proxy app को OEM-specific killers से whitelist करें. Xiaomi: autostart on, recents में lock। Samsung: deep sleep off, never sleeping app on। Realme/Oppo: keep alive on। Huawei: protected app on।
6. App info screen से proxy app को कभी force-stop न करें. Android 15+ पर stopped state direct या indirect user action तक persist रहती है और pending intents cancel कर देती है; ऐसा होने पर app फिर launch करें।
7. Confirm करें कि proxy app का foreground service type 6-hour cap के subject नहीं है (Android 15+, target SDK 35+ apps)।
8. Plugged in रहते Wi-Fi को always-on पर lock करें.
9. Adaptive Battery disable करें, या accept करें कि वह proxy app को deprioritize कर सकती है और periodically audit करें।
10. Data Saver और कोई भी “restrict background data” toggles disable करें.
11. हर कुछ हफ़्तों में proxy app को visibly reopen करें ताकि वह rare और restricted buckets से बाहर रहे (खासकर Android 13+, जो 8 दिनों unused पर trigger होता है)।

General rule अगर कोई setting background activity limit करके battery बचाने का वादा करती है, तो वह proxy uptime को नुक़सान पहुँचाएगी। Proxies background activity ही तो हैं। इस category की हर चीज़ disable करें, और battery life बढ़ाने के लिए charging-side measures (आगे cover हैं) पर rely करें।

Hardware solution: smart plugs और scheduled charging

24/7 phone को 20–80% sweet spot में रखने का सबसे reliable तरीक़ा software पर rely करने की बजाय power input को control करना है। कुछ phones में built-in charge cap है (Google के Pixel 6a+ में “Limit to 80%”, Samsung One UI 6.1+ में “Battery protection”, Sony में “Battery Care”, Xiaomi selected models पर HyperOS में एक hidden 80% charge limit expose करता है), पर ज़्यादातर में नहीं; और जहाँ है भी, implementation inconsistent हो सकती है।

एक smart plug, यानी एक Wi-Fi controlled mains outlet, इसे generically solve कर देता है। Plug schedule के मुताबिक़ charger को off और on करता है। Phone अपना state of charge network पर report करता है (या वह किसी भी fleet-management dashboard पर दिखता है), और एक simple loop ~80% तक charge करता है, idle रहता है, और SoC ~30% तक गिरने पर resume करता है।

Practical setups:

• Off-the-shelf smart plugs. TP-Link Tapo, Sonoff, और similar Wi-Fi plugs $5 से $15 तक के होते हैं और ज़्यादातर home automation platforms के साथ integrate होते हैं। Crude approach है fixed schedule (4 hours charge, 8 hours off): first pass के तौर पर good enough, पर actual SoC track नहीं करता।
• Tasmota या ESPHome firmware. एक smart plug को open firmware से flash करना MQTT या local HTTP API से control allow करता है, मतलब एक script phone का actual battery level poll कर सकता है और plug toggle कर सकता है।
• Home Assistant. अगर Home Assistant पहले से चल रहा है, integration straightforward है: एक battery sensor (ADB script या dedicated battery-broadcast app के ज़रिए) SoC पढ़ता है, और एक automation thresholds पर plug toggle करती है।
• DIY USB-line cutoffs. USB power line पर एक relay, ESP32 या Raspberry Pi से controlled, यही चीज़ device के क़रीब कर सकता है। Scale पर यह सबसे सस्ता है पर सबसे fragile।

Universal recipe (एक smart plug plus एक छोटा ADB script जो phone से SoC पढ़े और 30% और 80% पर plug toggle करे) के लिए, जो किसी भी Android model पर काम करता है चाहे OEM built-in cap ship करता हो या नहीं, देखें system-side power saving guide में smart plug + ADB script section ।

Caveat: phone running रखें कुछ phones charger disconnect होने पर deep sleep या hibernate में चले जाते हैं, screen on होने पर भी। Specific model test करें: confirm करें कि smart plug के “off” portion में भी phone proxy traffic serve करता है। अगर नहीं, तो एक wakelock app की ज़रूरत हो सकती है, या off intervals shorter करने पड़ सकते हैं।

ज़्यादातर phones के लिए एक reasonable target schedule: 80% तक charge (30% से आम तौर पर 1 से 2 hours), SoC 30% तक गिरने तक idle (normal proxy traffic पर आम तौर पर 8 से 12 hours), फिर वापस charge। यह 4.20V पर constant float के बजाय gentle voltage range में दिन भर में 2–3 partial cycles produce करता है।

Proxy operators के लिए practical longevity checklist

हर phone को एक बार configure करें, ideally production में जाने से पहले:

1. जिस भी method से available हो (built-in OEM toggle जैसे Pixel 6a+, Samsung One UI 6.1+, या smart plug schedule) उससे charging को 80% पर cap करें. Universal ADB recipe किसी भी model पर काम करती है।
2. SoC को 20% से नीचे न जाने दें. अगर traffic load phone को charger के keep-up rate से तेज़ drain कर रहा है, यह एक wiring या charger-power problem है जिसे cell को damage होने से पहले solve करना चाहिए।
3. OS level पर Battery Saver और Adaptive Battery disable करें. देखें system-side battery guide ।
4. iProxy app और OpenVPN को per-app battery settings में “Unrestricted” पर set करें, plus autostart, plus background lock। Per-version walkthrough: iProxy और OpenVPN के लिए Android battery optimization disable करें ।
5. Proxy app को OEM-specific killers से whitelist करें ऊपर वाली table के अनुसार। Xiaomi: autostart on, recents में lock। Samsung: deep sleep off, never sleeping app on। Realme/Oppo: keep alive on। Huawei: protected app on।
6. Plugged in रहते Wi-Fi को always-on पर lock करें, never sleep.
7. जब हो सके built-in 80% cap वाले devices चुनें. Recommended Android devices for iProxy page Pixel 8/9 और recent Galaxy models को specifically इस feature के लिए flag करती है।
8. Slow-charge. Plugged-in operation के लिए 3A fast charger की जगह 1A या 1.5A wall adapter use करें। कम current का मतलब है कम temperature और cell पर कम stress।
9. Temperature manage करें. Phones को tightly stack न करें। उन्हें routers, modems, या direct sun पर park न करें। Phones के आस-पास ambient air चाहिए, ideally 25°C से नीचे। Airflow matters; देखें 4G proxy network setup guide का fleet-hygiene section।
10. Quarterly audit करें. Phone OS updates disabled features फिर से enable कर सकते हैं। हर 90 दिनों में check करें। Connection-settings checklist उस broader operator hygiene को cover करती है जो इस audit के साथ pair होती है।

Phone को कब retire करें

सबसे अच्छी देखभाल के साथ भी battery एक consumable है। एक proxy phone के लिए practical retirement threshold है: जब capacity new value के लगभग 70% से नीचे चली जाए। उसके नीचे तीन चीज़ें होती हैं:

• Load पर voltage ज़्यादा गिरती है, traffic spikes के दौरान intermittent dropouts का कारण।
• Cell तेज़ी से गरम होती है, अपनी ही decline को accelerate करती है।
• Physical swelling की संभावना बढ़ जाती है। एक swollen cell screen, back cover pop कर सकती है, या rare cases में puncture और ignite हो सकती है।

ज़्यादातर Android phones battery health settings में या ADB (dumpsys battery) के through report करते हैं। Fleet चलाने वाले operator को health monthly track करनी चाहिए और swelling शुरू होने से पहले phones को rotate out करना चाहिए। 70% capacity पर retire किया गया और बेच दिया या repurpose किया गया phone एक planned cost है; 50% पर screen फाड़ देने वाला phone एक planned cost plus destroyed device है। पहले से right hardware pick करना यहाँ pay off करता है: iProxy की recommended devices list उन models को track करती है जिनका OS support long है, battery menus predictable हैं, और जिनमें built-in 80% cap है जो इस article की हर चीज़ को आसान बना देता है।

Reference numbers

इस article की recommendations (80% पर cap, 100% float avoid करें, slow-charge, temperature manage करें, Android को ऐसे configure करें कि वह proxy को interrupt न करे) arbitrary best practices नहीं हैं। हर एक specific degradation mechanism से correspond करती है जो voltage या temperature के साथ exponentially scale होती है: SEI growth, cathode से transition-metal dissolution, electrolyte oxidation, Arrhenius temperature scaling। Cells genuinely voltage और temperature के प्रति sensitive हैं, ऐसे तरीक़ों से जो screen पर percentage indicator expose नहीं करता।

Cost-benefit anchor करने के लिए दो reference points। इन्हें fleet-planning estimates मानें, हर cell chemistry के लिए guarantee नहीं: baseline BU-808 की storage और charge-voltage tables से आता है, जबकि 24/7 proxy scenario इसके ऊपर real-world heat, fast-charger, और unattended-Android variables जोड़ता है।

• एक 24/7 proxy phone जो default Android settings के साथ configure है, fast charger में plugged है, हमेशा 100% पर बैठा है, एक warm stack में: 12 महीनों में आम तौर पर अपनी initial capacity का 30 से 40 प्रतिशत खो देता है।
• वही phone, 80% पर capped, smart plug पर slow-charged, OS battery savers disabled और OEM killers whitelisted, airflow वाले 22°C कमरे में: 12 महीनों में आम तौर पर अपनी initial capacity का 90 प्रतिशत या ज़्यादा retain करता है, और 36 महीनों पर भी 70% retirement threshold से ऊपर रहने की संभावना है।

Configuration cost छोटा है: per device एक smart plug, per phone model एक one-time settings audit, plus per-app Unrestricted guide और system-side battery saver guide में cover किए गए per-app और system-level toggles। हर 12 महीनों में phone replace करने और हर 30 से 36 महीनों में replace करने के बीच capital cost का अंतर fleet के साथ linearly scale करता है, और पाँच devices से बड़े किसी भी fleet पर यह पहले quarter के अंदर configuration time का payback कर देता है।