एंड्रॉइड 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
निम्नलिखित चरण निष्पादित करता है:
sys.powerctl=reboot,userspace
प्राप्त करता है।सॉफ्ट रीस्टार्ट की निगरानी के लिए एक अलग
UserspaceRebootWatchdogThread()
प्रक्रिया को फोर्क करता है।एक
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
कार्रवाई देखें।-
DoUserspaceReboot
फ़ंक्शन चलाता है, जो निम्नलिखित क्रियाएं करता है:-
userdata
माउंट होने के बाद शुरू होने वाली प्रक्रियाओं मेंSIGTERM
भेजता है और उनके रुकने की प्रतीक्षा करता है। - समय समाप्त होने के बाद, किसी भी चल रही प्रक्रिया को समाप्त करने के लिए
SIGKILL
भेजता है। - कॉल
/system/bin/vdc volume reset
। - zRAM बैकिंग डिवाइस को अनमाउंट करता है।
- सक्रिय APEX पैकेजों को अनमाउंट करता है।
- बूटस्ट्रैप माउंट नेमस्पेस पर वापस स्विच करता है।
-
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 परीक्षणों का उपयोग करके सॉफ्ट रीस्टार्ट को सत्यापित कर सकते हैं।