ऐप्लिकेशन स्टैंडबाय बकेट

Android 9 (एपीआई लेवल 28) और इसके बाद के वर्शन में, ऐप्लिकेशन स्टैंडबाय बकेट की सुविधा काम करती है. ऐप्लिकेशन स्टैंडबाय बकेट की मदद से सिस्टम, ऐप्लिकेशन के संसाधनों के अनुरोधों को प्राथमिकता देता है. ऐसा इस आधार पर किया जाता है कि ऐप्लिकेशन का इस्तेमाल हाल ही में कितनी बार किया गया है. ऐप्लिकेशन के इस्तेमाल के पैटर्न के आधार पर, हर ऐप्लिकेशन को प्राथमिकता के हिसाब से पांच बकेट में से किसी एक में रखा जाता है. सिस्टम, हर ऐप्लिकेशन के लिए डिवाइस के उपलब्ध संसाधनों को सीमित करता है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस बकेट में है.

प्रायॉरिटी बकेट

सिस्टम, हर ऐप्लिकेशन को डाइनैमिक तरीके से प्राथमिकता वाले बकेट में असाइन करता है. साथ ही, ज़रूरत के हिसाब से ऐप्लिकेशन को फिर से असाइन करता है. सिस्टम, पहले से लोड किए गए ऐसे ऐप्लिकेशन पर भरोसा कर सकता है जो मशीन लर्निंग का इस्तेमाल करता है. इससे यह तय किया जाता है कि हर ऐप्लिकेशन के इस्तेमाल किए जाने की कितनी संभावना है. साथ ही, ऐप्लिकेशन को सही बकेट में असाइन किया जाता है.

अगर किसी डिवाइस पर सिस्टम ऐप्लिकेशन मौजूद नहीं है, तो सिस्टम डिफ़ॉल्ट रूप से ऐप्लिकेशन को इस आधार पर क्रम से लगाता है कि उन्हें हाल ही में कब इस्तेमाल किया गया था. ज़्यादा इस्तेमाल किए जाने वाले ऐप्लिकेशन को उन बकेट में असाइन किया जाता है जिनमें उन्हें ज़्यादा प्राथमिकता मिलती है. इससे ऐप्लिकेशन के लिए ज़्यादा सिस्टम संसाधन उपलब्ध होते हैं. खास तौर पर, बकेट यह तय करती है कि ऐप्लिकेशन के टास्क कितनी बार चलेंगे और ऐप्लिकेशन कितनी बार अलार्म ट्रिगर कर सकता है. ये पाबंदियां सिर्फ़ तब लागू होती हैं, जब डिवाइस बैटरी पावर पर हो. डिवाइस चार्ज होने के दौरान, सिस्टम इन पाबंदियों को लागू नहीं करता.

ध्यान दें: हर मैन्युफ़ैक्चरर, उन ऐप्लिकेशन को बकेट में असाइन करने के लिए अपनी शर्तें तय कर सकता है जो चालू नहीं हैं. यह तय करने की कोशिश न करें कि आपके ऐप्लिकेशन को किस बकेट में असाइन किया गया है. इसके बजाय, इस बात पर ध्यान दें कि आपका ऐप्लिकेशन जिस भी बकेट में हो उसमें सही तरीके से काम करे. यह जानने के लिए कि आपका ऐप्लिकेशन किस बकेट में है, UsageStatsManager.getAppStandbyBucket()

को कॉल करें.

प्राथमिकता वाले बकेट ये हैं:

• चालू: ऐप्लिकेशन का इस्तेमाल किया जा रहा है या हाल ही में इसका इस्तेमाल किया गया था.
• वर्किंग सेट: ऐप्लिकेशन का नियमित तौर पर इस्तेमाल किया जा रहा है.
• अक्सर: ऐप्लिकेशन का इस्तेमाल अक्सर किया जाता है, लेकिन रोज़ नहीं.
• कभी-कभी: ऐप्लिकेशन का इस्तेमाल अक्सर नहीं किया जाता.
• पाबंदी लगी है: ऐप्लिकेशन, सिस्टम के बहुत ज़्यादा संसाधनों का इस्तेमाल करता है या हो सकता है कि वह अवांछित व्यवहार करता हो.

इन प्राथमिकता वाले बकेट के अलावा, एक खास कभी नहीं बकेट भी होता है. यह उन ऐप्लिकेशन के लिए होता है जिन्हें इंस्टॉल किया गया है, लेकिन कभी नहीं चलाया गया. सिस्टम, इन ऐप्लिकेशन पर गंभीर पाबंदियां लगाता है.

ध्यान दें: बैटरी सेवर मोड में काम न करने वाले ऐप्लिकेशन की सूची में शामिल ऐप्लिकेशन पर, ऐप्लिकेशन स्टैंडबाय बकेट के आधार पर लगाई गई पाबंदियां लागू नहीं होती हैं.

यहां दी गई जानकारी, अनुमान न लगाने से जुड़े मामले के लिए है. इसके उलट, जब अनुमान लगाने के लिए मशीन लर्निंग का इस्तेमाल किया जाता है, तो बकेट को उपयोगकर्ता की हाल ही की गतिविधि के आधार पर नहीं, बल्कि उसकी अगली गतिविधियों के अनुमान के आधार पर चुना जाता है. उदाहरण के लिए, हाल ही में इस्तेमाल किया गया कोई ऐप्लिकेशन, रेयर बकेट में शामिल हो सकता है. ऐसा इसलिए, क्योंकि मशीन लर्निंग को लगता है कि इस ऐप्लिकेशन का इस्तेमाल कई घंटों तक नहीं किया जाएगा.

चालू है

किसी ऐप्लिकेशन को ऐक्टिव बकेट में तब रखा जाता है, जब उसका इस्तेमाल किया जा रहा हो, हाल ही में उसका इस्तेमाल किया गया हो या जब वह इनमें से कोई काम करता हो:

• इससे कोई गतिविधि लॉन्च होती है.
• यह लंबे समय तक चलने वाली फ़ोरग्राउंड सेवा को चलाता है.
• जब उपयोगकर्ता सूचना पर टैप करता है.

अगर कोई ऐप्लिकेशन ऐक्टिव बकेट में है, तो सिस्टम उस ऐप्लिकेशन के टास्क या अलार्म पर कम से कम पाबंदियां लगाता है:

• Android 16 (एपीआई लेवल 36) से, बैकग्राउंड में चलने वाले टास्क के लिए रनटाइम कोटा ज़्यादा होता है. ऐसा तब होता है, जब उन्हें ऐक्टिव बकेट में मौजूद किसी ऐप्लिकेशन से शुरू किया जाता है. इसमें JobScheduler का इस्तेमाल करके सीधे तौर पर शेड्यूल की गई जॉब के साथ-साथ, WorkManager या DownloadManager जैसी अन्य लाइब्रेरी से बनाई गई जॉब भी शामिल हैं.

उपयोगकर्ता के इंटरैक्शन से, ऐप्लिकेशन को सक्रिय के तौर पर असाइन किया जाता है

Android 9 (एपीआई लेवल 28) और इसके बाद के वर्शन पर, जब उपयोगकर्ता कुछ तरीकों से आपके ऐप्लिकेशन का इस्तेमाल करता है, तो सिस्टम आपके ऐप्लिकेशन को कुछ समय के लिए ऐक्टिव बकेट में रख देता है. जब कोई उपयोगकर्ता आपके ऐप्लिकेशन का इस्तेमाल करना बंद कर देता है, तो सिस्टम उसे इस्तेमाल के इतिहास के आधार पर किसी बकेट में रख देता है.

यहां कुछ ऐसे इंटरैक्शन के उदाहरण दिए गए हैं जिनसे सिस्टम का यह व्यवहार ट्रिगर होता है:

• जब उपयोगकर्ता, आपके ऐप्लिकेशन से भेजी गई सूचना पर टैप करता है.

  ध्यान दें: अगर उपयोगकर्ता सूचना पर टैप किए बिना उसे स्वाइप करके खारिज कर देता है, तो सिस्टम इस कार्रवाई को आपके ऐप्लिकेशन के साथ इंटरैक्शन नहीं मानता.

• उपयोगकर्ता, आपके ऐप्लिकेशन में फ़ोरग्राउंड सेवा के साथ इंटरैक्ट करता है. इसके लिए, वह मीडिया बटन पर टैप करता है.

• उपयोगकर्ता, Android Automotive OS के साथ इंटरैक्ट करते समय आपके ऐप्लिकेशन से कनेक्ट होता है. इस दौरान, आपका ऐप्लिकेशन फ़ोरग्राउंड सेवा या CONNECTION_TYPE_PROJECTION का इस्तेमाल करता है.

वर्किंग सेट

अगर कोई ऐप्लिकेशन अक्सर चलता है, लेकिन चालू नहीं है, तो उसे वर्किंग सेट बकेट में रखा जाता है. उदाहरण के लिए, कोई ऐसा सोशल मीडिया ऐप्लिकेशन जिसे उपयोगकर्ता लगभग हर दिन लॉन्च करता है, उसके वर्किंग सेट में शामिल होने की संभावना ज़्यादा होती है. अगर ऐप्लिकेशन का इस्तेमाल सीधे तौर पर नहीं किया जाता है, तो उन्हें वर्किंग सेट बकेट में भी प्रमोट किया जाता है.

अगर कोई ऐप्लिकेशन वर्किंग सेट में है, तो सिस्टम उस पर कुछ पाबंदियां लगाता है. जैसे, ऐप्लिकेशन के जॉब चलाने और अलार्म ट्रिगर करने की क्षमता पर पाबंदी. ज़्यादा जानकारी के लिए, पावर मैनेजमेंट के संसाधन की सीमाएं देखें.

अक्सर

अगर किसी ऐप्लिकेशन का इस्तेमाल नियमित रूप से किया जाता है, लेकिन हर दिन नहीं, तो उसे अक्सर इस्तेमाल किया जाने वाला ऐप्लिकेशन माना जाता है. उदाहरण के लिए, जिम में कसरत को ट्रैक करने के लिए इस्तेमाल किया जाने वाला ऐप्लिकेशन, अक्सर इस्तेमाल किए जाने वाले ऐप्लिकेशन की कैटगरी में शामिल हो सकता है.

अगर कोई ऐप्लिकेशन अक्सर इस्तेमाल किया जाता है, तो सिस्टम उस पर कई तरह की पाबंदियां लगाता है. जैसे, बैकग्राउंड में टास्क करने और अलार्म ट्रिगर करने की क्षमता पर पाबंदियां. ज़्यादा जानकारी के लिए, पावर मैनेजमेंट के संसाधन की सीमाएं देखें.

काफ़ी कम बार

अगर किसी ऐप्लिकेशन का इस्तेमाल अक्सर नहीं किया जाता है, तो उसे कभी-कभी इस्तेमाल होने वाले ऐप्लिकेशन की कैटगरी में रखा जाता है. उदाहरण के लिए, कोई होटल ऐप्लिकेशन जिसे उपयोगकर्ता सिर्फ़ उस होटल में ठहरने के दौरान इस्तेमाल करता है, उसे रेयर बकेट में रखा जा सकता है.

अगर कोई ऐप्लिकेशन रेयर बकेट में है, तो सिस्टम उस पर जॉब चलाने और अलार्म ट्रिगर करने की क्षमता पर सख्त पाबंदियां लगाता है. सिस्टम, ऐप्लिकेशन को इंटरनेट से कनेक्ट करने की सुविधा को भी सीमित करता है. ज़्यादा जानकारी के लिए, पावर मैनेजमेंट के संसाधन की सीमाएं देखें.

पाबंदी लगी है

Android 12 (एपीआई लेवल 31) में जोड़े गए इस बकेट को सबसे कम प्राथमिकता दी जाती है. साथ ही, इस पर अन्य सभी बकेट की तुलना में सबसे ज़्यादा पाबंदियां होती हैं. सिस्टम, आपके ऐप्लिकेशन के व्यवहार के आधार पर यह तय करता है कि उसे प्रतिबंधित बकेट में रखना है या नहीं. जैसे, उपयोगकर्ता कितनी बार ऐप्लिकेशन से इंटरैक्ट करता है.

Android 13 (एपीआई लेवल 33) और इसके बाद के वर्शन पर, सिस्टम आपके ऐप्लिकेशन को इन स्थितियों में प्रतिबंधित बकेट में डाल देता है. हालांकि, ऐसा तब तक होता है, जब तक आपका ऐप्लिकेशन छूट पाने की ज़रूरी शर्तें पूरी नहीं करता:

• उपयोगकर्ता ने तय दिनों तक आपके ऐप्लिकेशन का इस्तेमाल न किया हो. Android 12 (एपीआई लेवल 31) और 12L (एपीआई लेवल 32) पर, यह अवधि 45 दिनों की होती है. Android 13 में, इस अवधि को घटाकर आठ दिन कर दिया गया है.

  ध्यान दें: डिवाइस के बंद रहने की अवधि को इंटरैक्टिविटी की सीमा में नहीं गिना जाता.

• आपका ऐप्लिकेशन, 24 घंटे की अवधि में बहुत ज़्यादा ब्रॉडकास्ट या बाइंडिंग शुरू करता है.

अगर सिस्टम आपके ऐप्लिकेशन को प्रतिबंधित बकेट में रखता है, तो ये पाबंदियां लागू होती हैं:

• बैच किए गए 10 मिनट के सेशन में, हर दिन एक बार जॉब चलाए जा सकते हैं. इस सेशन के दौरान, सिस्टम आपके ऐप्लिकेशन के टास्क को अन्य ऐप्लिकेशन के टास्क के साथ ग्रुप करता है.
  • पाबंदी वाली जॉब अपने-आप नहीं चलती हैं. उसी समय कम से कम एक अन्य जॉब चल रही हो या उसके शुरू होने का इंतज़ार किया जा रहा हो. इसमें कोई भी अन्य जॉब शामिल हो सकती है.
• सिस्टम आपके ऐप्लिकेशन को कम पाबंदी वाली बकेट में रखता है, तो आपका ऐप्लिकेशन कम तेज़ी से पूरे होने वाले जॉब चला सकता है.
• आपका ऐप्लिकेशन, हर दिन एक अलार्म सेट कर सकता है. यह अलार्म, तय समय पर बजने वाला अलार्म या तय समय पर न बजने वाला अलार्म हो सकता है.

ध्यान दें: अन्य बकेट के उलट, पावर मैनेजमेंट से जुड़ी ये पाबंदियां, प्रतिबंधित बकेट पर तब भी लागू होती हैं, जब डिवाइस चार्ज हो रहा हो. हालांकि, जब डिवाइस चार्ज हो रहा हो, इस्तेमाल में न हो, और अनलिमिटेड डेटा वाले नेटवर्क से कनेक्ट हो, तब इन पाबंदियों में ढील दी जाती है.

पाबंदियों वाले बकेट से छूट

यहां दिए गए ऐप्लिकेशन को, पाबंदी वाले बकेट में शामिल होने से छूट मिलती है. साथ ही, ये ऐप्लिकेशन Android 12 और इसके बाद के वर्शन पर भी, निष्क्रियता ट्रिगर को बायपास कर सकते हैं:

• कंपैनियन डिवाइस ऐप्लिकेशन
• डेमो मोड में चल रहे डिवाइस पर मौजूद ऐप्लिकेशन
• डिवाइस के मालिक के ऐप्लिकेशन
• प्रोफ़ाइल के मालिक के ऐप्लिकेशन
• स्थायी ऐप्लिकेशन
• VPN ऐप्स
• ऐसे ऐप्लिकेशन जिनके पास ROLE_DIALER की भूमिका है
• ऐसे ऐप्लिकेशन जिन्हें उपयोगकर्ता ने सिस्टम सेटिंग में जाकर, "बिना किसी पाबंदी के" फ़ंक्शन उपलब्ध कराने के लिए चुना है
• ऐसे ऐप्लिकेशन जिनके विजेट चालू हैं
• ऐसे ऐप्लिकेशन जिन्हें इनमें से कम से कम एक अनुमति दी गई हो:
  • USE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION

प्राथमिकता वाले बकेट का आकलन करना

यह देखने के लिए कि आपके ऐप्लिकेशन को किस बकेट में असाइन किया गया है, इनमें से कोई एक तरीका अपनाएं:

• getAppStandbyBucket() पर कॉल करें.

• टर्मिनल विंडो में यह कमांड चलाएं:

  adb shell am get-standby-bucket PACKAGE_NAME

सिस्टम, आपके ऐप्लिकेशन को तब थ्रॉटल करता है, जब उसे ऐसे ऐप्लिकेशन स्टैंडबाय बकेट में रखा जाता है जिसकी वैल्यू STANDBY_BUCKET_ACTIVE (10) से ज़्यादा होती है.

सबसे सही तरीके

अगर आपका ऐप्लिकेशन, डोज़ मोड और ऐप्लिकेशन स्टैंडबाय मोड के लिए सबसे सही तरीकों का पालन कर रहा है, तो पावर मैनेजमेंट की नई सुविधाओं को लागू करना मुश्किल नहीं होगा. हालांकि, ऐप्लिकेशन के कुछ ऐसे व्यवहारों से समस्याएँ हो सकती हैं जो पहले ठीक से काम करते थे.

• सिस्टम को इस तरह से इस्तेमाल न करें कि वह आपके ऐप्लिकेशन को किसी खास बकेट में रखे. सिस्टम, प्राथमिकता तय करने के तरीके में बदलाव कर सकता है. साथ ही, डिवाइस बनाने वाली हर कंपनी, अपने एल्गोरिदम के साथ खुद का बकेटिंग ऐप्लिकेशन बना सकती है. इसके बजाय, पक्का करें कि आपका ऐप्लिकेशन सही तरीके से काम करे, भले ही वह किसी भी बकेट में हो.
• अगर किसी ऐप्लिकेशन में लॉन्चर गतिविधि नहीं है, तो हो सकता है कि उसे कभी भी ऐक्टिव बकेट में प्रमोट न किया जाए. ऐसी गतिविधि के लिए, अपने ऐप्लिकेशन को फिर से डिज़ाइन करें.

• अगर उपयोगकर्ता, ऐप्लिकेशन की सूचनाओं से इंटरैक्ट नहीं कर सकते, तो वे ऐप्लिकेशन के प्रमोशन को ऐक्टिव बकेट में ट्रिगर नहीं कर पाएंगे. ऐसे में, उपयोगकर्ताओं को इंटरैक्ट करने की सुविधा देने वाली कुछ सूचनाओं को फिर से डिज़ाइन करें. कुछ दिशा-निर्देशों के लिए, Material Design के सूचनाओं के डिज़ाइन पैटर्न देखें.

• अगर ऐप्लिकेशन को ज़्यादा प्राथमिकता वाला Firebase Cloud Messaging (FCM) मैसेज मिलने पर कोई सूचना नहीं दिखती है, तो उपयोगकर्ता ऐप्लिकेशन से इंटरैक्ट नहीं कर पाएगा. इस वजह से, ऐप्लिकेशन को सक्रिय बकेट में प्रमोट नहीं किया जा सकेगा. दरअसल, ज़्यादा प्राथमिकता वाले FCM मैसेज का इस्तेमाल सिर्फ़ उपयोगकर्ता को सूचना भेजने के लिए किया जाता है. इसलिए, ऐसा नहीं होना चाहिए. अगर 12L (एपीआई लेवल 32) और इससे पहले के वर्शन पर, किसी ऐसे FCM मैसेज को ज़्यादा प्राथमिकता वाला मैसेज के तौर पर मार्क किया जाता है जिससे उपयोगकर्ता इंटरैक्शन ट्रिगर नहीं होता है, तो आने वाले समय में भेजे जाने वाले मैसेज को कम प्राथमिकता दी जा सकती है.

  ध्यान दें: अगर कोई उपयोगकर्ता बार-बार किसी सूचना को खारिज करता है, तो सिस्टम उसे आने वाले समय में उस सूचना को ब्लॉक करने का विकल्प देता है. उपयोगकर्ता को सूचनाएं भेजकर स्पैम न करें, ताकि आपका ऐप्लिकेशन ऐक्टिव बकेट में बना रहे.

• अगर ऐप्लिकेशन को कई पैकेज में बांटा गया है, तो हो सकता है कि वे पैकेज अलग-अलग बकेट में हों और उनके ऐक्सेस लेवल अलग-अलग हों. इन ऐप्लिकेशन को अलग-अलग बकेट में असाइन किए गए पैकेज के साथ टेस्ट करें, ताकि यह पक्का किया जा सके कि ऐप्लिकेशन सही तरीके से काम कर रहा है.