सॉफ़्ट रीस्टार्ट

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

सॉफ़्ट रीस्टार्ट के लिए, ये तरीके अपनाए जाते हैं:

• PowerManager से, कॉल करके PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

• शेल से, adb shell svc power reboot userspace या adb reboot userspace का इस्तेमाल करके

कुछ समय के लिए रीस्टार्ट होने के बाद भी, क्रेडेंशियल का एन्क्रिप्ट (सुरक्षित) किया गया स्टोरेज अनलॉक रहता है.

अगर किसी डिवाइस पर सॉफ़्ट रीस्टार्ट की सुविधा काम करती है, तो PowerManager.isRebootingUserspace() एपीआई तरीका true दिखाता है और मान सिस्टम प्रॉपर्टी का init.userspace_reboot.is_supported, 1 के बराबर है.

अगर डिवाइस में सॉफ़्ट रीस्टार्ट की सुविधा काम नहीं करती है, तो इस नंबर पर कॉल किया जा सकता है PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace, और adb shell svc power reboot userspace इस्तेमाल नहीं किए जा सके.

सॉफ़्ट रीस्टार्ट एक्ज़ीक्यूशन

सॉफ़्ट रीस्टार्ट करने का अनुरोध करने के बाद (PowerManager या शेल से), init यह तरीका अपनाता है:

1. sys.powerctl=reboot,userspace को पैसे मिलेंगे.

2. एक अलग UserspaceRebootWatchdogThread() सॉफ़्ट रीस्टार्ट को मॉनिटर करने की प्रोसेस.

3. इससे userspace-reboot-requested की कार्रवाई ट्रिगर होती है, जो सभी सिस्टम को रीसेट कर देती है प्रॉपर्टी जो सॉफ़्ट रीस्टार्ट पर असर डाल सकती हैं. ऐसी प्रॉपर्टी जिन पर असर हुआ है:

   • sys.usb.config
   • sys.usb.state
   • sys.boot_completed
   • dev.bootcomplete
   • sys.init.updatable_crashing
   • sys.init.updatable_crashing_process_name
   • apexd.status
   • sys.user.0.ce_available
   • sys.shutdown.requested
   • service.bootanim.exit

   ऊपर दी गई प्रॉपर्टी को चालू करने के क्रम के दौरान, फिर से सेट किया जाना चाहिए. ज़रूरत पड़ने पर, अतिरिक्त प्रॉपर्टी रीसेट कर सकता है. उदाहरण के लिए, on userspace-reboot-requested कार्रवाई हुई rootdir/init.rc.

4. यह चलाता है DoUserspaceReboot फ़ंक्शन की मदद से ये काम करते हैं:

   1. यह SIGTERM को उन प्रोसेस में भेजता है जो userdata के माउंट होने और उनके रुकने का इंतज़ार करता है.
   2. टाइम आउट की अवधि पूरी होने के बाद, किसी भी रनिंग को बंद करने के लिए SIGKILL भेज देता है प्रोसेस.
   3. /system/bin/vdc volume reset को कॉल करता है.
   4. zRAM बैकिंग डिवाइस को अप्रतिबंधित करता है.
   5. यह चालू APEX पैकेज को अलग करता है.
   6. बूटस्ट्रैप माउंट नेमस्पेस पर वापस स्विच करता है.
   7. यह userspace-reboot-resume को ट्रिगर करता है कार्रवाई.

अगर सॉफ़्ट रीस्टार्ट से पहले, फ़ाइल सिस्टम चेकपॉइंटिंग का अनुरोध किया गया था, तो userdata को इस दौरान चेकपॉइंट मोड में फिर से सेट किया गया: userspace-reboot-fs-remount कार्रवाई (ज़्यादा जानकारी के लिए, नीचे दिया गया सेक्शन देखें). ऐप्लिकेशन sys.boot_completed property के सेट होने के बाद, सॉफ़्ट रीस्टार्ट माना जाता है 1 तक. सॉफ़्ट रीस्टार्ट के बाद, डिसप्ले को बंद रखा जाता है और उसे सक्रिय करने के लिए, एक्सप्लिसिट यूज़र इंटरैक्शन ज़रूरी है.

फ़ाइल सिस्टम की जांच के लिए चेकपॉइंट

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

• फ़ाइल सिस्टम लेवल की जांच (उदाहरण के लिए, f2fs), userdata है checkpoint=disable विकल्प के साथ फिर से माउंट किया गया.

• ब्लॉक लेवल चेकपॉइंटिंग (जैसे, ext4) को हटाने के बाद, /data को अलग कर दिया जाता है और इसके ऊपर माउंट किए गए सभी पैरंट डिवाइस मैपर डिवाइस हैं नष्ट कर दिया गया. इसके बाद, userdata को उसी कोड पाथ का इस्तेमाल करके माउंट किया जाता है जिसका इस्तेमाल किया गया था सामान्य चेकपॉइंटिंग बूट की सुविधा मौजूद है.

अगर फ़ाइल सिस्टम लेवल पर मौजूद कीरिंग का इस्तेमाल, क्रेडेंशियल से एन्क्रिप्ट किए गए (सीई) और डिवाइस से एन्क्रिप्ट की गई (DE) कुंजियां, userdata को अलग करने के बाद कुंजियां खो जाती हैं. यहां की यात्रा पर हूं कुंजी को वापस पाने की अनुमति दें, फ़ाइल सिस्टम कीरिंग में कुंजी इंस्टॉल करते समय, vold यह सेशन-लेवल पर भी fscrypt-provisioning टाइप की एक ही कुंजी को इंस्टॉल करता है की-रिंग. init_user0 को कॉल करने पर, vold फ़ाइल में मौजूद कुंजियों को फिर से इंस्टॉल करता है की-रिंग.

हार्ड रीबूट पर फ़ॉलबैक

यह पक्का करने के लिए कि सॉफ़्ट रीस्टार्ट की सुविधा किसी डिवाइस को इस्तेमाल करने लायक नहीं बनाती है, Android 11 में, हार्ड रीबूट की प्रोसेस के दौरान, यह विकल्प तब ट्रिगर होता है, जब इनमें से कोई एक शर्त पूरी होती है:

• डिवाइस सॉफ़्ट रीस्टार्ट नहीं हो पाता है. इसका मतलब है कि sys.init.userspace_reboot.in_progress=1).
• प्रोसेस को दिए गए टाइम आउट में बंद नहीं किया जा सकता.
• /system/bin/vdc volume reset कार्रवाई पूरी नहीं हुई.
• zRAM डिवाइस को अलग करने में गड़बड़ी होती है.
• एक चालू APEX पैकेज, गलत तरीके से अलग हो गया.
• userdata को चेकपॉइंट मोड में फिर से माउंट करने की कोशिश नहीं की जा सकी.
• कोई डिवाइस इसके अंदर सफलतापूर्वक बूट नहीं हो पाता (यानी sys.boot_completed=1) दिया गया टाइम आउट दिया गया है.

हर डिवाइस के हिसाब से कॉन्फ़िगरेशन

सॉफ़्ट रीस्टार्ट की गई कुछ सुविधाओं को, यहां दी गई वैल्यू में बदलाव करके ट्यून किया जा सकता है प्रॉपर्टी:

• init.userspace_reboot.is_supported यह कंट्रोल करता है कि कोई डिवाइस कब कार्रवाई कर सकता है सॉफ़्ट रीस्टार्ट करें. अगर इस प्रॉपर्टी की वैल्यू false, 0 है या इसके बारे में नहीं बताया गया है, तो तो, रीस्टार्ट करने की कोशिश को अस्वीकार कर दिया जाता है.
• init.userspace_reboot.sigkill.timeoutmillis इसमें टाइम आउट को कंट्रोल करता है उन प्रोसेस के लिए मिलीसेकंड जिसे रोकने के लिए SIGKILL सिग्नल मिला. अगर इनमें से कोई दिए गए टाइम आउट में प्रोसेस बंद नहीं हो पाती हैं. इसके बाद, बैक अप लेना मुश्किल होता है रीबूट हो जाता है.
• init.userspace_reboot.sigterm.timeoutmillis इसमें टाइम आउट को कंट्रोल करता है उन प्रोसेस के लिए मिलीसेकंड जिसे खत्म करने के लिए SIGTERM सिग्नल मिला. सभी दिए गए टाइम आउट में खत्म नहीं हो पाने वाली प्रोसेस को SIGKILL सिग्नल.
• init.userspace_reboot.started.timeoutmillis इसमें टाइम आउट को कंट्रोल करता है सॉफ़्ट रीस्टार्ट शुरू करने के लिए मिलीसेकंड (यानी, sys.init.userspace_reboot.in_progress=1). अगर कोई डिवाइस सॉफ़्ट चालू नहीं हो पाता है दिए गए टाइम आउट में रीस्टार्ट होता है, तो हार्ड रीबूट पर फ़ॉलबैक ट्रिगर हो जाता है.
• init.userspace_reboot.userdata_remount.timeoutmillis इसमें टाइम आउट को कंट्रोल करता है userdata को अलग करने के लिए मिलीसेकंड. अगर कोई डिवाइस, userdata को अलग नहीं कर पाता है दिए गए टाइम आउट के अंदर, हार्ड रीबूट पर फ़ॉलबैक ट्रिगर हो जाता है.
• init.userspace_reboot.watchdog.timeoutmillis यह कंट्रोल करता है कि डिवाइस (यानी, sys.boot_completed=1) को सफलतापूर्वक बूट करने में सक्षम हो. अगर कोई डिवाइस दिए गए टाइम आउट के अंदर बूट नहीं हो पाता है, तो हार्ड रीबूट का फ़ॉलबैक है ट्रिगर किया गया.

सॉफ़्ट रीस्टार्ट के दौरान, ऐनिमेशन को पसंद के मुताबिक बनाएं

सॉफ़्ट रीस्टार्ट के बाद, अपनी ज़रूरत के हिसाब से डेटा ट्रांसफ़र किया जा सकता है सॉफ़्ट रीस्टार्ट के दौरान दिखाया गया ऐनिमेशन.

userspace-reboot-fs-remount कार्रवाई खत्म होने पर, init शुरू हो जाता है bootanim सेवा. यह सेवा, इस तरह की मौजूदगी का पता लगाती है ऐनिमेशन फ़ाइलें, सूची में मौजूद होती हैं और मिलने वाली पहली फ़ाइल को चलाती हैं:

• /product/media/userspace-reboot.zip
• /oem/media/userspace-reboot.zip
• /system/media/userspace-reboot.zip

अगर सॉफ़्ट रीस्टार्ट के लिए कोई खास ऐनिमेशन फ़ाइल तय नहीं की गई है, तो bootanim डिफ़ॉल्ट android ऐनिमेशन.

टेस्ट करना

Android 11 में, सॉफ़्ट रीस्टार्ट करें. इसके अलावा, सीटीएस का इस्तेमाल करके सॉफ़्ट रीस्टार्ट की पुष्टि की जा सकती है में जांच UserspaceRebootHostTest.