ऐप्लिकेशन का हाइबरनेशन मोड

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

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

प्लैटफ़ॉर्म में बदलाव करने वाले ओईएम, ऐप्लिकेशन के हाइबरनेशन मोड को लागू करने में समस्या का सामना कर सकते हैं. उदाहरण के लिए

  • ऐप्लिकेशन के इस्तेमाल की परिभाषा में बदलाव करने या ऐप्लिकेशन को जगाने के ऐसे तरीकों को शामिल करने पर जो AOSP में मौजूद नहीं हैं, हो सकता है कि ऐप्लिकेशन के हाइबरनेट होने की सटीक जानकारी न मिल पाए
  • ऐप्लिकेशन को हाइबरनेट करने की सुविधा की तरह, OEM का मालिकाना हक वाला पाबंदी वाला तरीका भी ऐसा ही काम कर सकता है. दोनों मौजूद हो सकते हैं, लेकिन हो सकता है कि कुछ ओवरलैप हो.

सीडीडी में, ऐप्लिकेशन के इस्तेमाल के आधार पर किए जाने वाले बदलावों के लिए, ज़रूरी शर्तों के नए सेट के बारे में बताया गया है. यह शर्तें, मौजूदा 3.5.1 की शर्तों से मिलती-जुलती हैं. ऐप्लिकेशन के हाइबरनेशन मोड के लिए, ये ज़रूरी शर्तें पूरी करनी होती हैं.

फ़्रेमवर्क कोड यहां मौजूद होता है:

नीति का लॉजिक इनमें मौजूद होता है:

  • repo: platform/packages/modules/Permission
  • डायरेक्ट्री: PermissionController/src/com/android/permissioncontroller/hibernation

हाई-लेवल आर्किटेक्चर

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

  • अनुमतियां अपने-आप वापस होना
  • ऐप्लिकेशन को ज़बरदस्ती बंद करना
  • ODEX और VDEX फ़ाइलें मिटाना
  • ऐप्लिकेशन की कैश मेमोरी मिटाना

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

प्लान किए गए डिज़ाइन में दो मुख्य हिस्से हैं:

  • यह तय करना कि किसी पैकेज को हाइबरनेट कब करना चाहिए
  • हाइबरनेट किए गए पैकेज को ऑप्टिमाइज़ करना

AppHibernationService एक नई सिस्टम सेवा है और AppHibernationJobService, एक जॉब सेवा है.PermissionController में ये दोनों सेवाएं, फ़ैसले लेने और लॉजिक को कंट्रोल करती हैं.

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

किसी पैकेज को ऑप्टिमाइज़ करने पर, असल में बचत होती है और ऑप्टिमाइज़ेशन होता है. AppHibernationService, पैकेज को रोकने, कैश मेमोरी का डेटा मिटाने, ART आर्टफ़ैक्ट मिटाने वगैरह के लिए, सिस्टम के अलग-अलग हिस्सों के साथ काम करता है. Android 11 और उससे पहले के वर्शन वाले डिवाइसों पर, अनुमति अपने-आप रद्द होने की सुविधा को बनाए रखने के लिए, अनुमति रद्द करने की प्रोसेस सीधे AppHibernationJobService से शुरू की जाती है.

उपयोगकर्ता अनुभव

उपयोगकर्ता को यह जानकारी और कंट्रोल मिलता है कि किन ऐप्लिकेशन को हाइबरनेट किया जा सकता है.

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

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

पुराने सिस्टम के साथ काम करने की सुविधा

हाइबरनेट मोड से जुड़ी सुविधाएं, Android 12 और उसके बाद के वर्शन में उपलब्ध हैं. यह सुविधा, पिछले वर्शन पर काम नहीं कर सकती, क्योंकि इसमें प्लैटफ़ॉर्म के कॉम्पोनेंट (जैसे, नई सिस्टम सेवा) मौजूद नहीं होते. ऑटो-रिवोक की सुविधा, पहले के ओएस वर्शन के लिए लागू की गई सुविधा के मुताबिक ही काम करती रहेगी.

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

पसंद के मुताबिक बनाएं

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

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

इसके अलावा, OEM भी ऐसी ही सुविधा लागू कर सकते हैं. हालांकि, इन सुविधाओं को बैटरी के ऑप्टिमाइज़ेशन के लिए, बहुत कम समयसीमा के हिसाब से टारगेट किया जाता है. ये सुविधाएं, OEM के हिसाब से हो सकती हैं. OEM की ओर से बनाई गई, ऐप्लिकेशन पर पाबंदी लगाने से जुड़ी मिलती-जुलती सुविधाएं, ऐप्लिकेशन को हाइबरनेट करने वाले सिस्टम के साथ काम कर सकती हैं. हालांकि, इसके लिए ज़रूरी है कि वे सीडीडी में बताई गई मौजूदा शर्तों को पूरा करती हों.

टेस्ट करना

ऐप्लिकेशन के हाइबरनेट होने की सुविधा में सीटीएस और यूनिट टेस्ट होते हैं, ताकि यह पक्का किया जा सके कि यह सही तरीके से काम कर रहा है.