सॉफ़्ट रीस्टार्ट (<= 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 कार्रवाई को ट्रिगर करता है.

अगर सॉफ़्ट रीस्टार्ट से पहले फ़ाइल सिस्टम चेकपॉइंटिंग का अनुरोध किया गया था, तो 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 को उसी कोड पाथ का इस्तेमाल करके माउंट किया जाता है जिसका इस्तेमाल सामान्य चेकपॉइंटिंग बूट में किया जाता है.

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

हार्ड रीबूट पर वापस जाएं

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

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