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

एंड्रॉइड 11 सॉफ्ट रीस्टार्ट का समर्थन करता है, जो उपयोगकर्ता स्थान में प्रक्रियाओं के रनटाइम रीस्टार्ट हैं जिनका उपयोग उन अपडेट को लागू करने के लिए किया जाता है जिनके लिए रीबूट की आवश्यकता होती है (उदाहरण के लिए, एपेक्स पैकेज के अपडेट)। वर्तमान में, सॉफ्ट रीस्टार्ट उन प्रक्रियाओं तक सीमित है जो userdata माउंट होने के बाद शुरू हुई हैं।

निम्नलिखित तरीकों से सॉफ्ट रीस्टार्ट का अनुरोध किया जाता है:

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

  • शेल से, adb shell svc power reboot userspace या adb reboot userspace उपयोग करके

सॉफ्ट रीस्टार्ट के बाद, क्रेडेंशियल एन्क्रिप्टेड स्टोरेज अनलॉक रहता है।

यदि कोई डिवाइस सॉफ्ट रीस्टार्ट का समर्थन करता है, तो PowerManager.isRebootingUserspace() API विधि 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 फ़ाइल सिस्टम कीरिंग में कुंजियों को पुनः स्थापित करता है।

हार्ड रीबूट पर वापस लौटें

यह सुनिश्चित करने के लिए कि सॉफ्ट रीस्टार्ट किसी डिवाइस को अनुपयोगी स्थिति में न छोड़े, एंड्रॉइड 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 एनीमेशन दिखाता है।

परिक्षण

एंड्रॉइड 11 में सॉफ्ट रीस्टार्ट का संदर्भ कार्यान्वयन शामिल है। इसके अलावा, आप UserspaceRebootHostTest में CTS परीक्षणों का उपयोग करके सॉफ्ट रीस्टार्ट को सत्यापित कर सकते हैं।