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