औसतन, Android का कोई उपयोगकर्ता अपने डिवाइसों पर 50 से ज़्यादा ऐप्लिकेशन इंस्टॉल करता है. डिवाइसों के रैम-टीयर के बढ़ने के साथ, यह संख्या बढ़ती जाती है. हालांकि, इनमें से कई ऐप्लिकेशन का इस्तेमाल उपयोगकर्ता लंबे समय तक नहीं करते.
ऐप्लिकेशन के हाइबरनेशन मोड की मदद से, उन ऐप्लिकेशन को हाइबरनेट किया जाता है जिनका इस्तेमाल उपयोगकर्ता ने कुछ महीनों तक नहीं किया है. यह सुविधा, अनुमति अपने-आप वापस लेने की सुविधा जैसी ही है. यह ऐप्लिकेशन को ज़बरदस्ती रोक देता है और उसे ऐसी स्थिति में रखता है जहां हम परफ़ॉर्मेंस के बजाय स्टोरेज के लिए ऑप्टिमाइज़ करते हैं. अनुमति अपने-आप रद्द होना भी इस स्थिति के साथ बंडल किया गया है. साथ ही, ये सेटिंग में एक ही छूट की सेटिंग शेयर करते हैं. जब किसी ऐप्लिकेशन को जबरदस्ती बंद किया जाता है, तो वह बैकग्राउंड में न तो कोई टास्क करता है और न ही सूचनाएं भेजता है. जब उपयोगकर्ता ऐप्लिकेशन का फिर से इस्तेमाल करता है, तो ऐप्लिकेशन हाइबरनेट मोड से बाहर निकल जाता है और जॉब/सूचनाएं/सूचनाएं फिर से सामान्य रूप से चलने लगती हैं. ऐप्लिकेशन के हाइबरनेशन मोड में जाने से पहले शेड्यूल किए गए जॉब/चेतावनियों/सूचनाओं को फिर से शेड्यूल करना होगा.
प्लैटफ़ॉर्म में बदलाव करने वाले ओईएम, ऐप्लिकेशन के हाइबरनेशन मोड को लागू करने में समस्या का सामना कर सकते हैं. उदाहरण के लिए
- अगर ऐप्लिकेशन के इस्तेमाल की परिभाषा में बदलाव किया जाता है या ऐसे ऐप्लिकेशन को चालू करने के तरीके पेश किए जाते हैं जो एओएसपी में नहीं हैं, तो हो सकता है कि ऐप्लिकेशन के हाइबरनेशन की प्रोसेस पूरी होने में रुकावट आए
- ऐप्लिकेशन को हाइबरनेट करने की सुविधा की तरह, OEM का मालिकाना हक वाला पाबंदी वाला तरीका भी ऐसा ही काम कर सकता है. हालांकि दोनों मौजूद हो सकते हैं, लेकिन कुछ ओवरलैप हो सकते हैं.
CDD, ऐप्लिकेशन के इस्तेमाल के हिसाब से बदलावों के लिए ज़रूरी शर्तों के एक नए सेट की जानकारी देता है. यह शर्तें, मौजूदा 3.5.1 ज़रूरी शर्तों की तरह हैं. ऐप्लिकेशन का हाइबरनेशन मोड इन ज़रूरी शर्तों को पूरा करता है.
फ़्रेमवर्क कोड यहां मौजूद होता है:
- repo: platform/frameworks/base
- डायरेक्ट्री: services/core/java/com/android/server/apphibernation
यह नीति इन देशों/इलाकों में लागू होती है:
- रेपो: प्लैटफ़ॉर्म/पैकेज/मॉड्यूल/अनुमति
- डायरेक्ट्री: PermissionController/src/com/android/permissioncontroller/hibernation
हाई-लेवल आर्किटेक्चर
ऐप्लिकेशन को हाइबरनेट करने की सिस्टम सेवा, उपयोगकर्ता के उन ऐप्लिकेशन को स्टोरेज के लिए ऑप्टिमाइज़ करती है जिन्हें अक्सर इस्तेमाल नहीं किया जाता. साथ ही, उन ऐप्लिकेशन को बैकग्राउंड में चलने से रोकती है. ये नतीजे पाने के लिए, जब हम किसी ऐप्लिकेशन को हाइबरनेट करते हैं, तो हम खास तौर पर:
- अनुमतियां अपने-आप वापस होना
- ऐप्लिकेशन को ज़बरदस्ती बंद करना
- ODEX और VDEX फ़ाइलें मिटाएं
- ऐप्लिकेशन की कैश मेमोरी मिटाना
हमारा लक्ष्य हाइबरनेशन की सुविधा को एक ऐसी कार्रवाई के तौर पर लागू करना है जिसे वापस पाया जा सके. इससे, ऐप्लिकेशन उपयोगकर्ता के लिए लॉन्चर और ऐसे अन्य प्लैटफ़ॉर्म के ज़रिए उपलब्ध रहेगा जहां ऐप्लिकेशन का डेटा एक-दूसरे के साथ मिलकर काम करेगा. ऐप्लिकेशन को लॉन्च करने पर, हम उसे जबरन बंद किए जाने की स्थिति से वापस ला देंगे. साथ ही, ODEX और VDEX फ़ाइल बनाने की प्रोसेस को सामान्य तरीके से जारी रखेंगे.
प्लान किए गए डिज़ाइन में दो मुख्य हिस्से हैं:
- यह तय करना कि किसी पैकेज को हाइबरनेट कब करना चाहिए
- हाइबरनेटिंग पैकेज को ऑप्टिमाइज़ किया जा रहा है
AppHibernationService
एक नई सिस्टम सेवा है और AppHibernationJobService,
एक जॉब सेवा है.PermissionController
में ये दोनों सेवाएं, फ़ैसले लेने और लॉजिक को कंट्रोल करती हैं.
किसी पैकेज को हाइबरनेट कब करना चाहिए, यह तय करना मुख्य रूप से UsageStatsService
की मदद से काम करता है. साथ ही, इसे PermissionController
AppHibernationJobService
में मैनेज किया जाता है. PermissionController
में मौजूद नीति का लॉजिक, हमें मुख्य वर्शन के ज़रिए डाइनैमिक तौर पर अपडेट करने की अनुमति देता है. इसके अलावा, हम UsageStatsService
में एक नई मेट्रिक के तौर पर, पैकेज के कॉम्पोनेंट (उदाहरण के लिए, सेवाएं, कॉन्टेंट देने वाली कंपनियां) के इस्तेमाल को कैप्चर करने के लिए, एक नया सिग्नल, कॉम्पोनेंट के इस्तेमाल को जोड़ने वाले हैं.
किसी पैकेज को ऑप्टिमाइज़ करने पर, असल में बचत होती है और ऑप्टिमाइज़ेशन होता है. AppHibernationService
पैकेज को रोकने, कैश मेमोरी का डेटा मिटाने, ART आर्टफ़ैक्ट मिटाने वगैरह के लिए सिस्टम के अलग-अलग हिस्सों से संपर्क करता है.
अनुमति रद्द करने की प्रोसेस, सीधे AppHibernationJobService
से शुरू की जाती है. ऐसा इसलिए किया जाता है, ताकि Android 11 और उससे पहले के वर्शन वाले डिवाइसों पर, अनुमति अपने-आप रद्द होने की सुविधा बनी रहे.
उपयोगकर्ता अनुभव
उपयोगकर्ता को यह जानकारी और कंट्रोल मिलता है कि किन ऐप्लिकेशन को हाइबरनेट किया जा सकता है.
अपने-आप रद्द होने की सुविधा की तरह ही, उपयोगकर्ता को यह सूचना मिलती है कि किन ऐप्लिकेशन को हाइबरनेट किया गया है. साथ ही, वह सूचना से सीधे सेटिंग पर जाकर, ऐप्लिकेशन को खोल सकता है और उसे हाइबरनेट मोड से बाहर ला सकता है. इसके अलावा, ज़रूरत पड़ने पर, इस्तेमाल नहीं किए जा रहे ऐप्लिकेशन को मिटा सकता है.
हम डेवलपर के उस इंटेंट का समर्थन करते रहेंगे जिसमें उपयोगकर्ता से, अनुमतियों के अपने-आप रद्द होने से छूट पाने का अनुरोध किया जाता है.
पुराने सिस्टम के साथ काम करने की सुविधा
हाइबरनेट मोड से जुड़ी सुविधाएं, Android 12 और उसके बाद के वर्शन में उपलब्ध हैं. यह सुविधा पुराने वर्शन पर काम नहीं कर सकती, क्योंकि इसमें प्लैटफ़ॉर्म के कॉम्पोनेंट (जैसे, नई सिस्टम सेवा) मौजूद नहीं हैं. ऑटो-रिवोक की सुविधा, पहले के ओएस वर्शन के लिए लागू की गई सुविधा के मुताबिक ही काम करती रहेगी.
Android 12 में, ऐप्लिकेशन के पेज पर सेटिंग में ऐप्लिकेशन और सूचनाएं में, ऐप्लिकेशन के पेज पर'हाइबरनेट करें' टॉगल जोड़ा गया है. इससे, ऐप्लिकेशन के लिए अनुमति अपने-आप रद्द होने की मूल सेटिंग को अनुमतियां सब-मेन्यू में रखा जा सकता है. इस टॉगल से ऐप्लिकेशन के लिए हाइबरनेशन सिस्टम में उपलब्ध पूरी छूट को कंट्रोल किया जाता है.
पसंद के मुताबिक बनाएं
लागू करने के कुछ तरीके, मॉड्यूलर सिस्टम कॉम्पोनेंट का हिस्सा हैं. इसलिए, पार्टनर को सुविधा में बदलाव करने की सलाह नहीं दी जाती है. हालांकि, पार्टनर ऐसी ही सुविधाएं या फ़ंक्शन लागू कर सकते हैं. इसके लिए, ज़रूरी है कि वे सीडीडी की ज़रूरी शर्तों का पालन करें.
Android 11 या इसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, ऐप्लिकेशन को हाइबरनेट करने की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए. यह सुविधा, अनुमतियों के अपने-आप वापस होने की सुविधा जैसी ही है. सेटिंग चालू होने के बावजूद, ऐप्लिकेशन को हाइबरनेट करने की सुविधा, Android 11 और Android 12 को टारगेट करने वाले ऐप्लिकेशन के लिए अलग-अलग हो सकती है. खास तौर पर, ऐप्लिकेशन के हाइबरनेट होने की सुविधा सिर्फ़ Android 11 को टारगेट करने वाले ऐप्लिकेशन के लिए काम करती है. वहीं, Android 12 को टारगेट करने वाले ऐप्लिकेशन के लिए, यह सुविधा अपने-आप रद्द हो जाती है.
इसके अलावा, OEM भी ऐसी ही सुविधा लागू कर सकते हैं. हालांकि, उन सुविधाओं को बैटरी ऑप्टिमाइज़ेशन के लिए बहुत कम समय के लिए टारगेट किया गया है, जो कि OEM के हिसाब से हो सकता है. ऐप्लिकेशन पर पाबंदी से जुड़ी ऐसी कोई भी सुविधा जिसे OEM ने डेवलप किया है, वह ऐप्लिकेशन के हाइबरनेशन सिस्टम के साथ तब तक मौजूद रह सकती है, जब तक वह सीडीडी में दी गई शर्तों को पूरा करती है.
टेस्ट करना
ऐप्लिकेशन के हाइबरनेट मोड में, सीटीएस और यूनिट टेस्ट होते हैं. इससे यह पक्का किया जाता है कि ऐप्लिकेशन सही तरीके से काम कर रहा है.
AutoRevokeTest
AppHibernationIntegrationTest