App Standby — यह क्या है, प्रतीक्षा स्तर और कार्य सिद्धांत

App Standby क्या है

App Standby — यह Android ऊर्जा प्रबंधन प्रणाली का एक घटक है, जिसे Android 6.0 (API 23) में पेश किया गया और Android 9 (API 28) में महत्वपूर्ण रूप से पुनः डिज़ाइन किया गया। इसका कार्य यह निर्धारित करना है कि उपयोगकर्ता किन ऐप्स का कम उपयोग करता है, और उनकी पृष्ठभूमि गतिविधि को सीमित करना: नेटवर्क अनुरोध, सिंक्रनाइज़ेशन, JobScheduler और AlarmManager। Doze के विपरीत, App Standby स्क्रीन या डिवाइस की गति की स्थिति पर निर्भर नहीं करता।

सिस्टम ऐप्स को चार bucket (स्तरों) में वर्गीकृत करता है: Active, Working Set, Frequent और Rare। प्रत्येक स्तर यह निर्धारित करता है कि पृष्ठभूमि गतिविधि कितनी प्रतिबंधित है। स्तरों के बीच संक्रमण ऐप उपयोग पैटर्न के आधार पर स्वचालित रूप से होता है: उपयोगकर्ता इसे कितनी बार खोलता है, सूचनाएं प्राप्त करता है, विजेट्स के साथ इंटरैक्ट करता है।

App Standby Doze Mode के साथ मिलकर काम करता है, लेकिन इसे प्रतिस्थापित नहीं करता। यदि Doze डिवाइस के निष्क्रिय होने पर सभी ऐप्स की पृष्ठभूमि गतिविधि को सीमित करता है, तो App Standby डिवाइस की स्थिति से स्वतंत्र रूप से विशिष्ट ऐप्स को सीमित करता है। Rare स्तर वाला ऐप फोन के सक्रिय उपयोग के दौरान भी प्रतिबंधित रहेगा, यदि उपयोगकर्ता ने इसे कई दिनों से नहीं खोला है।

Android 9+ में Bucket

Android 9 (API 28) से शुरू करके, Google ने App Standby Buckets — संख्यात्मक मानों के साथ औपचारिक वर्गीकरण — पेश किया। सिस्टम ऐप के अगले लॉन्च की भविष्यवाणी करने के लिए मशीन लर्निंग का उपयोग करता है। यदि मॉडल भविष्यवाणी करता है कि ऐप अगले कुछ घंटों में खोला जाएगा, तो इसे Active bucket मिलता है। यदि भविष्यवाणी दुर्लभ उपयोग का संकेत देती है — तो Rare निर्धारित किया जाता है।

App Standby कैसे काम करता है

App Standby bucket निर्धारित करने के लिए कई कारकों का विश्लेषण करता है: उपयोगकर्ता द्वारा ऐप को अंतिम बार खोलने का समय, इंटरैक्शन आवृत्ति (प्रति दिन/सप्ताह लॉन्च की संख्या), FCM सूचनाएं प्राप्त करना, डेस्कटॉप पर सक्रिय विजेट्स की उपस्थिति और AlarmManager की सदस्यता। ऐप जितने लंबे समय तक उपयोग नहीं किया जाता, उसका bucket उतना ही कम होता है और प्रतिबंध उतने ही सख्त होते हैं।

सिस्टम सेवा UsageStatsManager ऐप उपयोग के आँकड़े एकत्र करती है और उन्हें StandbyController — framework घटक जो प्रत्येक ऐप के लिए bucket की गणना करता है — को भेजती है। StandbyController सिस्टम घटनाओं को भी ध्यान में रखता है: ऐप अपडेट के बाद, इसका bucket कुछ दिनों के लिए Active पर रीसेट हो जाता है ताकि उपयोगकर्ता नई सुविधाओं का मूल्यांकन कर सके।

एक महत्वपूर्ण विशेषता: App Standby ऐप प्रक्रिया को समाप्त नहीं करता, बल्कि इसकी पृष्ठभूमि क्षमताओं को सीमित करता है। यदि उपयोगकर्ता ऐप के साथ इंटरैक्ट करता है (bucket Active) तो ऐप काम करता रहता है। जैसे ही उपयोगकर्ता ऐप को बंद करता है और उस पर वापस नहीं लौटता, सिस्टम निष्क्रियता का समय गिनना शुरू करता है और bucket को Working Set या Frequent तक कम कर सकता है।

FCM का bucket पर प्रभाव

FCM high-priority संदेश प्राप्त करना अस्थायी रूप से ऐप के bucket को Active तक बढ़ा सकता है। यह ऐप को बिना प्रतिबंधों के कार्य करने (संदेश संसाधित करना, डेटा सिंक्रोनाइज़ करना) का अवसर देता है। हालांकि, प्रसंस्करण पूरा होने के बाद bucket अपने मूल मान पर वापस आ जाता है। Google महत्वपूर्ण सूचनाएं वितरित करने के लिए इस तंत्र का उपयोग करने की सलाह देता है, न कि ऐप को "जीवित" रखने के लिए।

App Standby के स्तर

App Standby ऐप्स को वर्गीकृत करने के लिए चार स्तरों (bucket) का उपयोग करता है। प्रत्येक स्तर पृष्ठभूमि कार्यों के लिए विलंब समय निर्धारित करता है: स्तर जितना कम होगा, विलंब उतना ही अधिक होगा। सिस्टम पिछले 7–14 दिनों में एकत्रित उपयोग के आँकड़ों के आधार पर ऐप को स्तरों के बीच स्वचालित रूप से स्थानांतरित करता है।

Active — सक्रिय ऐप

Active — वह ऐप जिसके साथ उपयोगकर्ता ने हाल ही में इंटरैक्ट किया (लॉन्च किया, सूचना प्राप्त की या विजेट का उपयोग किया)। इस bucket में कोई प्रतिबंध नहीं: JobScheduler तुरंत चलता है, नेटवर्क उपलब्ध है, AlarmManager सटीक रूप से काम करता है। ऐप Active में तब तक रहता है जब तक उपयोगकर्ता कई घंटों तक इसके साथ इंटरैक्ट करना बंद नहीं करता।

Working Set और Frequent

Working Set — ऐप नियमित रूप से उपयोग होता है (सप्ताह में कई बार)। पृष्ठभूमि कार्यों में 2 घंटे तक की देरी। Frequent — ऐप महीने में कई बार उपयोग होता है। 4 घंटे तक की देरी। दोनों स्तरों में नेटवर्क केवल सेवा विंडो में उपलब्ध है, और AlarmManager में देरी हो सकती है। JobScheduler निकटतम विंडो में कार्य करता है।

Rare — कम उपयोग होने वाला

Rare — सबसे सख्त स्तर, उन ऐप्स को निर्धारित किया जाता है जिन्हें उपयोगकर्ता ने 30 दिनों से अधिक समय से नहीं खोला। पृष्ठभूमि कार्यों में 24 घंटे तक की देरी। सेवा विंडो के बाहर नेटवर्क पूरी तरह से अवरुद्ध होता है, AlarmManager केवल setAndAllowWhileIdle() फ्लैग के साथ 9 मिनट में 1 बार की सीमा के साथ काम करता है। FCM high-priority सूचनाएं अभी भी वितरित होती हैं, लेकिन bucket को नहीं बढ़ा सकतीं।

App Standby में प्रतिबंध

App Standby पृष्ठभूमि संचालन की कई श्रेणियों पर प्रतिबंध लगाता है। Doze के विपरीत, App Standby के प्रतिबंध स्क्रीन और चार्जर की स्थिति से स्वतंत्र रूप से काम करते हैं। डेवलपर को इन प्रतिबंधों को ध्यान में रखते हुए ऐप डिज़ाइन करना चाहिए, खासकर यदि लक्षित दर्शक ऐप का अनियमित रूप से उपयोग करते हैं।

JobScheduler और WorkManager

JobScheduler — मुख्य API जो App Standby से प्रभावित होता है। bucket के आधार पर कार्य निष्पादन में 2 से 24 घंटे तक की देरी होती है। WorkManager, जो अंतर्निहित रूप से JobScheduler का उपयोग करता है (API 23+ पर), भी इन देरी के अधीन है। समय-महत्वपूर्ण कार्यों के लिए Expedited Work का उपयोग करें, जो अंतर्निहित रूप से Foreground Service चलाता है और bucket पर निर्भर नहीं करता।

नेटवर्क प्रतिबंध

Working Set, Frequent और Rare bucket वाले ऐप किसी भी समय मनमाने नेटवर्क अनुरोध नहीं कर सकते। सिस्टम केवल सेवा विंडो में नेटवर्क तक पहुंच की अनुमति देता है, जो Doze के साथ सिंक्रनाइज़ हैं। महत्वपूर्ण डेटा भेजने के लिए FCM high-priority का उपयोग करें, जिसके बाद सेवा विंडो में सिंक्रनाइज़ेशन हो।

AlarmManager

AlarmManager App Standby में Doze के समान नियमों का पालन करता है: सटीक अलार्म (setExact()) विलंबित होते हैं, और setAndAllowWhileIdle() 9 मिनट में 1 सक्रियण तक सीमित है। Rare bucket के लिए देरी 24 घंटे तक पहुंच सकती है, जो कम उपयोग होने वाले ऐप्स में सटीक कार्य नियोजन के लिए AlarmManager को अनुपयुक्त बनाती है।

• JobScheduler — कार्य bucket के आधार पर 2–24 घंटे तक विलंबित होते हैं
• नेटवर्क — Working Set और नीचे के लिए केवल सेवा विंडो में पहुंच
• AlarmManager — सटीक अलार्म विलंबित; setAndAllowWhileIdle — 1/9 मिनट
• SyncManager — खाता सिंक्रनाइज़ेशन सेवा विंडो तक विलंबित
• Widget updates — विजेट अपडेट की आवृत्ति कम हो सकती है

अपवाद कैसे प्राप्त करें

अपवाद App Standby से दो तरीकों से प्राप्त किया जा सकता है: उपयोगकर्ता बैटरी सेटिंग्स (मैन्युअल Whitelist) के माध्यम से या सिस्टम Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS के माध्यम से। हालांकि, Google अपवादों तक पहुंच को सख्ती से नियंत्रित करता है — जिन ऐप्स के पास अपवाद के लिए ठोस कारण नहीं है, उन्हें Google Play में अस्वीकार किए जाने का जोखिम है।

उपयोगकर्ता सेटिंग्स → ऐप्स → [ऐप] → बैटरी → ऑप्टिमाइज़ेशन → ऑप्टिमाइज़ न करें के माध्यम से किसी विशिष्ट ऐप के लिए प्रतिबंध मैन्युअल रूप से हटा सकता है। यह चयनित ऐप के लिए App Standby और Doze के प्रतिबंधों को पूरी तरह से हटा देता है। डेवलपर उपयोगकर्ता को निर्देश या सिस्टम डायलॉग दिखा सकता है, लेकिन ऐप को अपवादों में जबरदस्ती नहीं जोड़ सकता।

Foreground Service सूचना के साथ स्वचालित रूप से App Standby से अस्थायी अपवाद प्राप्त करता है। जब तक सेवा चलती है और सूचना प्रदर्शित करती है, ऐप उसके वास्तविक स्तर से स्वतंत्र रूप से Active bucket में स्थानांतरित हो जाता है। सेवा बंद होने के बाद bucket अपने मूल मान पर वापस आ जाता है। सिस्टम अपवादों का अनुरोध किए बिना पृष्ठभूमि कार्य सुनिश्चित करने का यह सबसे विश्वसनीय तरीका है।

अपवाद का अनुरोध कब करें

Whitelist का अनुरोध केवल उन ऐप्स के लिए समझ में आता है जिनमें महत्वपूर्ण पृष्ठभूमि कार्यक्षमता है: रीयल-टाइम नेविगेशन, स्वास्थ्य निगरानी, VoIP कॉल, डिवाइस सुरक्षा। अधिकांश ऐप्स के लिए Foreground Service या WorkManager का उपयोग करना पर्याप्त है। यदि ऐप स्पष्ट आवश्यकता के बिना अपवाद का अनुरोध करता है तो Google Play प्रकाशन को अस्वीकार कर सकता है।

// ऐप स्टैंडबाई से अपवाद का अनुरोध
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// वर्तमान स्थिति की जांच
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

App Standby का परीक्षण

परीक्षण ADB के माध्यम से App Standby का आपको ऐप को किसी भी bucket में强制 रूप से निर्धारित करने और उसके व्यवहार की जांच करने की अनुमति देता है। यह उन ऐप्स के लिए महत्वपूर्ण है जो पृष्ठभूमि सिंक्रनाइज़ेशन, सूचनाएं या समय-समय पर अपडेट पर निर्भर करते हैं। परीक्षण Android 9+ वाले भौतिक उपकरण या एम्यूलेटर पर किया जाना चाहिए।

bucket को强制 रूप से सेट करने के लिए कमांड adb shell am set-standby-bucket [package] [bucket] का उपयोग किया जाता है, जहां bucket हो सकता है: active, working_set, frequent या rare। वर्तमान bucket देखने के लिए — adb shell am get-standby-bucket [package]। सिस्टम कमांड adb shell dumpsys usagestats के माध्यम से ऐप की लंबी निष्क्रियता का अनुकरण भी करने की अनुमति देता है।

# ऐप के लिए Rare bucket सेट करना
$ adb shell am set-standby-bucket com.example.app rare

# वर्तमान bucket देखना
$ adb shell am get-standby-bucket com.example.app

# सभी buckets को Active पर रीसेट करना
$ adb shell dumpsys usagestats clear

# सिस्टम के सभी buckets देखना
$ adb shell dumpsys usagestats

क्या जांचें

Rare bucket सेट करने के बाद जांचें: क्या WorkManager कार्य 24 घंटों के भीतर निष्पादित होता है, क्या AlarmManager सक्रिय होता है, क्या FCM सूचनाएं वितरित होती हैं, क्या Foreground Service बिना प्रतिबंधों के काम करता है। WorkManager Expedited Work नीति के साथ Rare bucket में भी तुरंत निष्पादित होना चाहिए, क्योंकि यह Foreground Service का उपयोग करता है। सामान्य WorkManager कार्य bucket के अनुसार विलंबित होंगे।

सर्वोत्तम अभ्यास

App Standby के प्रति सहनशील ऐप विकसित करने के लिए पृष्ठभूमि कार्यों के लिए एक जागरूक दृष्टिकोण की आवश्यकता होती है। मूल सिद्धांत: यह न मानें कि ऐप हमेशा Active bucket में है। पृष्ठभूमि कार्य को इस तरह डिज़ाइन करें कि वह Frequent और Rare bucket की विशिष्ट देरी के साथ सही ढंग से निष्पादित हो।

WorkManager का Expedited Work के साथ उपयोग करें

Expedited Work (WorkManager 2.7+) अंतर्निहित रूप से Foreground Service चलाता है, जो कार्य को bucket से स्वतंत्र रूप से तुरंत निष्पादित करने की अनुमति देता है। यह उन कार्यों के लिए सबसे अच्छा विकल्प है जिनमें देरी नहीं हो सकती: संदेश भेजना, भुगतान के बाद सिंक्रनाइज़ेशन, इनकमिंग कॉल का प्रसंस्करण। सामान्य WorkManager कार्य bucket को ध्यान में रखते हुए सेवा विंडो में निष्पादित होते हैं।

पुनर्सक्रियण के लिए FCM

App Standby से ऐप को जगाने के लिए FCM high-priority संदेशों का उपयोग करें। जब ऐप ऐसा संदेश प्राप्त करता है, तो इसका bucket अस्थायी रूप से Active तक बढ़ जाता है, और यह आवश्यक कार्य (सिंक्रनाइज़ेशन, डेटा अपडेट) कर सकता है। प्रसंस्करण पूरा होने के बाद bucket अपने मूल स्तर पर वापस आ जाता है।

मेमोरी में स्थायी रूप से बने रहने से बचें

स्थायी पृष्ठभूमि सेवाओं, WakeLock या समय-समय पर FCM संदेशों के साथ App Standby को बायपास करने का प्रयास न करें। Google ऐसी प्रथाओं के खिलाफ सक्रिय रूप से लड़ता है — ऐप को ऊर्जा-खर्चीले के रूप में चिह्नित किया जा सकता है और और भी सख्ती से सीमित किया जा सकता है। समय-समय पर कार्यों के लिए WorkManager का उपयोग करें और Foreground Service केवल तब जब कार्य वास्तव में उपयोगकर्ता को दिखाई देता है।

• WorkManager — पसंदीदा API; Expedited Work बिना देरी के कार्य निष्पादित करता है
• FCM high-priority — संदेश प्रसंस्करण के लिए अस्थायी रूप से bucket को Active तक बढ़ाता है
• बायपास न करें App Standby — इससे सिस्टम द्वारा ऐप ब्लॉक हो जाता है
• Foreground Service — कार्य की अवधि के लिए अस्थायी रूप से ऐप को Active में लाता है
• परीक्षण करें प्रत्येक रिलीज़ से पहले ADB के माध्यम से Rare और Frequent bucket में ऐप का