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

अगर फ़ाइल सिस्टम के लेवल पर मौजूद कीरिंग का इस्तेमाल, क्रेडेंशियल की मदद से एन्क्रिप्ट किए गए (सीई) और डिवाइस पर एन्क्रिप्ट किए गए (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. अगर कोई डिवाइस दिए गए टाइम आउट में सॉफ़्ट रीस्टार्ट शुरू नहीं कर पाता है, तो हार्ड रीबूट ट्रिगर हो जाता है.
  • userdata को अलग करने के लिए, init.userspace_reboot.userdata_remount.timeoutmillis मिलीसेकंड में टाइम आउट को कंट्रोल करता है. अगर कोई डिवाइस तय किए गए टाइम आउट के अंदर 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 में सीटीएस टेस्ट का इस्तेमाल करके सॉफ़्ट रीस्टार्ट की पुष्टि की जा सकती है.