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
यह तरीका अपनाता है:
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
ऊपर दी गई प्रॉपर्टी को चालू करने के क्रम के दौरान, फिर से सेट किया जाना चाहिए. ज़रूरत पड़ने पर, अतिरिक्त प्रॉपर्टी रीसेट कर सकता है. उदाहरण के लिए,
on userspace-reboot-requested
कार्रवाई हुईrootdir/init.rc
.यह चलाता है
DoUserspaceReboot
फ़ंक्शन की मदद से ये काम करते हैं:- यह
SIGTERM
को उन प्रोसेस में भेजता है जोuserdata
के माउंट होने और उनके रुकने का इंतज़ार करता है. - टाइम आउट की अवधि पूरी होने के बाद, किसी भी रनिंग को बंद करने के लिए
SIGKILL
भेज देता है प्रोसेस. /system/bin/vdc volume reset
को कॉल करता है.- zRAM बैकिंग डिवाइस को अप्रतिबंधित करता है.
- यह चालू APEX पैकेज को अलग करता है.
- बूटस्ट्रैप माउंट नेमस्पेस पर वापस स्विच करता है.
- यह
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
को उसी कोड पाथ का इस्तेमाल करके माउंट किया जाता है जिसका इस्तेमाल किया गया था सामान्य चेकपॉइंटिंग बूट की सुविधा मौजूद है.
अगर फ़ाइल सिस्टम लेवल पर मौजूद कीरिंग का इस्तेमाल, क्रेडेंशियल से एन्क्रिप्ट किए गए (सीई) और
डिवाइस से एन्क्रिप्ट की गई (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
). अगर कोई डिवाइस सॉफ़्ट चालू नहीं हो पाता है दिए गए टाइम आउट में रीस्टार्ट होता है, तो हार्ड रीबूट पर फ़ॉलबैक ट्रिगर हो जाता है.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
.