सॉफ़्ट रीस्टार्ट (<= AOSP 14)

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

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

4. DoUserspaceReboot फ़ंक्शन को चलाता है, जो ये कार्रवाइयां करता है:

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

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

फ़ाइल सिस्टम का चेकपॉइंट बनाना

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

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

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

अगर क्रेडेंशियल से एन्क्रिप्ट (सीई) और डिवाइस से एन्क्रिप्ट (डीई) की गई कुंजियों को मैनेज करने के लिए, फ़ाइल सिस्टम लेवल की कीरिंग का इस्तेमाल किया जाता है, तो 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 में सीटीएस जांच का इस्तेमाल करके, सॉफ़्ट रीस्टार्ट की पुष्टि की जा सकती है.