Android 9 में बूटलोडर को चालू करने की वजह से जुड़ी खास जानकारी में ये बदलाव शामिल हैं.
चालू करने की वजहें
बूटलोडर, खास तौर पर उपलब्ध हार्डवेयर और मेमोरी संसाधनों का इस्तेमाल करके यह पता लगाता है कि डिवाइस को फिर से चालू क्यों किया गया. इसके बाद, यह
लॉन्च के लिए Android कर्नेल कमांड लाइन में androidboot.bootreason=<reason>
को जोड़कर तय करने की जानकारी देता है. इसके बाद, init
इस कमांड लाइन का अनुवाद Android प्रॉपर्टी bootloader_boot_reason_prop
(ro.boot.bootreason
) में करता है. Android 12 या इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, कर्नेल के 5.10 या इसके बाद के वर्शन का इस्तेमाल करके, androidboot.bootreason=<reason>
को कर्नेल कमांड लाइन के बजाय बूट कॉन्फ़िगरेशन में जोड़ा जाता है.
बूट करने की वजह से जुड़ी खास जानकारी
Android की पिछली रिलीज़ में, बूट करने की वजह का ऐसा फ़ॉर्मैट इस्तेमाल किया गया था जिसमें
स्पेस का इस्तेमाल नहीं किया गया था. यह फ़ॉर्मैट, छोटे अक्षरों में था, जिसमें कुछ ज़रूरी शर्तें (जैसे,
kernel_panic
, watchdog
,
cold
/warm
/hard
) की रिपोर्ट शामिल की गई थीं. साथ ही, इन्हें अन्य खास वजहों से अनुमति दी गई थी. इस बदलाव की वजह से, पसंद के मुताबिक बनाई गई सैकड़ों स्ट्रिंग (और कभी-कभी बेमतलब के)
बूट रीज़न स्ट्रिंग शुरू हो गई. इन स्ट्रिंग की वजह से स्थिति को मैनेज करना मुश्किल हो गया. Android के मौजूदा
वर्शन के बाद, बूटलोडर से फ़ाइल किए गए ऐसे कॉन्टेंट को लेकर परेशान न हों जो पार्स नहीं किया जा सकता या जिसे बेमतलब का है.
इस वजह से, bootloader_boot_reason_prop
के लिए नियमों का पालन करने से जुड़ी समस्याएं पैदा हो गई हैं.
Android 9 रिलीज़ होने के बाद, Android टीम
मानती है कि लेगसी bootloader_boot_reason_prop
काफ़ी तेज़ी से काम कर रहा है और रनटाइम के दौरान इसे फिर से नहीं लिखा जा सकता. इसलिए, बूट की वजह
से जुड़ी ज़रूरी शर्तों में किए जाने वाले सभी सुधार,
बूटलोडर के डेवलपर के साथ हुए इंटरैक्शन से और मौजूदा सिस्टम में किए जाने वाले बदलावों की वजह से होने चाहिए. इस वजह से,
Android टीम:
- बूटलोडर डेवलपर के साथ जुड़ना, ताकि उन्हें ये काम करने का बढ़ावा मिले:
bootloader_boot_reason_prop
को कैननिकल, पार्स करने लायक, और पहचानने लायक वजह बताएं.system/core/bootstat/bootstat.cpp
kBootReasonMap
सूची में हिस्सा लें.
system_boot_reason_prop
(sys.boot.reason
) का कंट्रोल और रनटाइम के ज़रिए बदलाव किया जा सकने वाला सोर्स जोड़ना. सिस्टम ऐप्लिकेशन (जैसे,bootstat
औरinit
) का सीमित सेट इस प्रॉपर्टी को फिर से लिख सकता है. हालांकि, सभी ऐप्लिकेशन को इसे पढ़ने के लिए से-नीति के अधिकार दिए जा सकते हैं.- उपयोगकर्ताओं को यह सूचना देना कि सिस्टम को चालू करने की वजह बताने वाली प्रॉपर्टी
system_boot_reason_prop
में मौजूद कॉन्टेंट पर भरोसा करने से पहले, उपयोगकर्ता डेटा को माउंट किए जाने तक इंतज़ार करने की वजह क्या है.
इतनी देरी क्यों हुई? जब bootloader_boot_reason_prop
बूट होने पर उपलब्ध होती है, तब Android की सुरक्षा नीति ने इसे ज़रूरत के हिसाब से ब्लॉक कर दिया
है. ऐसा इसलिए है, क्योंकि यह गलत, पार्स नहीं की जा सकने वाली, और गैर-कैननिकल जानकारी दिखाती है.
ज़्यादातर मामलों में, यह जानकारी सिर्फ़ उन डेवलपर को ऐक्सेस करनी होगी जिन्हें बूट सिस्टम की अच्छी जानकारी है. system_boot_reason_prop
के साथ चालू करने की वजह के लिए, बेहतर, पार्स किया जा सकने वाला, और कैननिकल एपीआई, उपयोगकर्ता के डेटा को माउंट करने के बाद ही भरोसेमंद और सही तरीके से चुना जा सकता है.
खास तौर से:
- उपयोगकर्ता डेटा को माउंट करने से पहले,
system_boot_reason_prop
मेंbootloader_boot_reason_prop
की वैल्यू शामिल होगी. - उपयोगकर्ता का डेटा माउंट होने के बाद,
system_boot_reason_prop
को अपडेट किया जा सकता है, ताकि उसे नीतियों के मुताबिक बनाया जा सके या ज़्यादा सटीक जानकारी दी जा सके.
इस वजह से, Android 9, बूट की वजह को
आधिकारिक तौर पर हासिल करने से पहले की समयावधि को बढ़ा देता है.
इस वजह से, इसे
बूट (bootloader_boot_reason_prop
के साथ) में तुरंत सटीक होने से बदलकर, उपयोगकर्ता का डेटा
माउंट किए जाने के बाद ही उपलब्ध कराया जाता है (system_boot_reason_prop
के साथ).
बूटस्टेट लॉजिक, ज़्यादा जानकारी वाले और नियमों के मुताबिक
bootloader_boot_reason_prop
पर निर्भर करता है. जब इस प्रॉपर्टी में
अनुमान लगाने के लिए उपलब्ध फ़ॉर्मैट का इस्तेमाल किया जाता है, तो यह सभी कंट्रोल को फिर से चालू करने और
शटडाउन करने की सभी स्थितियों को ज़्यादा सटीक बनाता है. इससे system_boot_reason_prop
को ज़्यादा सटीक और
ज़्यादा सटीक बनाया जा सकता है.
कैननिकल बूट करने की वजह का फ़ॉर्मैट
Android 9 में bootloader_boot_reason_prop
के लिए,
बूट (बूट) की वजह बताने वाले कैननिकल फ़ॉर्मैट में इस सिंटैक्स का इस्तेमाल किया जाता है:
<reason>,<subreason>,<detail>…
फ़ॉर्मैटिंग के नियम:
- लोअर केस
- कोई खाली जगह नहीं (अंडरलाइन का इस्तेमाल करें)
- प्रिंट किए जा सकने वाले सभी वर्ण
reason
,subreason
, और एक या एक से ज़्यादाdetail
इंस्टेंस को कॉमा लगाकर अलग किया गया.- ज़रूरी
reason
, जो डिवाइस को फिर से चालू करने या बंद करने की सबसे अहम वजह के बारे में बताता हो. - एक वैकल्पिक
subreason
, जो कम शब्दों में यह बताता है कि डिवाइस को फिर से चालू या बंद क्यों करना पड़ा. इसके अलावा, यह भी बताया जा सकता है कि डिवाइस को किसने फिर से चालू या शटडाउन किया है. - एक या एक से ज़्यादा वैकल्पिक
detail
वैल्यू.detail
एक सबसिस्टम की मदद से यह तय कर सकता है कि किस सिस्टम सेsubreason
मिला. एक से ज़्यादाdetail
वैल्यू तय की जा सकती हैं. आम तौर पर, इन वैल्यू को क्रम के हिसाब से अहमियत दी जानी चाहिए. हालांकि,detail
की एक जैसी अहमियत वाली कई वैल्यू को रिपोर्ट किया जा सकता है.
- ज़रूरी
bootloader_boot_reason_prop
के लिए कोई खाली वैल्यू गैर-कानूनी माना जाता है. ऐसा इसलिए, क्योंकि इससे दूसरे एजेंट को जांच के बाद बूट की वजह इंजेक्ट करने की अनुमति मिल जाती है.
वजह बताने की ज़रूरी शर्तें
reason
(खत्म होने से पहले या कॉमा से पहले की अवधि में) के लिए दी गई वैल्यू, इन सेट में से होनी चाहिए: कर्नेल, दमदार, और डेटा की ज़्यादा जानकारी
- कर्नेल सेट:
- ''
watchdog"
"kernel_panic"
- ''
- मज़बूत सेट:
"recovery"
"bootloader"
- ब्लंट सेट:
"cold"
. आम तौर पर, यह बताता है कि मेमोरी के साथ-साथ सभी डिवाइसों को पूरी तरह से रीसेट किया गया है."hard"
. आम तौर पर यह बताता है कि हार्डवेयर को रीसेट कर दिया गया है औरramoops
में लगातार कॉन्टेंट बना रहना चाहिए."warm"
. आम तौर पर, इससे पता चलता है कि मेमोरी और डिवाइस, कुछ स्थिति में हैं. साथ ही,ramoops
(कर्नेल मेंpstore
ड्राइवर देखें) बैकिंग स्टोर में लगातार कॉन्टेंट मौजूद रहता है."shutdown"
"reboot"
. आम तौर पर, इसका मतलब है किramoops
की स्थिति के बारे में जानकारी नहीं है और हार्डवेयर की स्थिति के बारे में जानकारी नहीं है. यह वैल्यू एक कैचऑल है, क्योंकिcold
,hard
, औरwarm
वैल्यू से इस बात के संकेत मिलते हैं कि डिवाइस को कितनी गहराई से रीसेट किया गया है.
बूटलोडर को एक कर्नेल सेट या एक ब्लंट सेट reason
देना चाहिए.
अगर सही तरीके से subreason
दिया जा सकता है, तो
उसे उपलब्ध कराने के लिए जोर दिया जाता है. उदाहरण के लिए, किसी पावर कुंजी को देर तक दबाकर रखने पर, हो सकता है कि ramoops
बैकअप की सुविधा चालू हो या न हो. ऐसा होने पर, चालू करने की वजह "reboot,longkey"
होगी.
कोई भी फ़र्स्ट-स्पैन reason
, किसी भी subreason
या
detail
का हिस्सा नहीं हो सकता. हालांकि, उपयोगकर्ता के स्पेस के हिसाब से कर्नेल के सेट की वजहें
नहीं बनाई जा सकतीं, इसलिए "watchdog"
का इस्तेमाल, एक ब्लंट सेट वजह के बाद फिर से किया जा सकता है. साथ ही, सोर्स की जानकारी (उदाहरण के लिए, "reboot,watchdog,service_manager_unresponsive"
या
"reboot,software,watchdog"
) भी इस्तेमाल की जा सकती है.
बूट करने से जुड़ी वजहों को समझने के लिए, विशेषज्ञ की इंटरनल जानकारी की ज़रूरत नहीं होनी चाहिए और/या
जानकारी देने वाली रिपोर्ट की मदद से, लोग उसे आसानी से पढ़ सकते हैं. उदाहरण:
"shutdown,vbxd"
(खराब), "shutdown,uv"
(बेहतर),
"shutdown,undervoltage"
(पसंदीदा).
वजहों की अलग-अलग वजहें
Android, reason
-subreason
के ऐसे कॉम्बिनेशन का सेट सुरक्षित रखता है जिन्हें सामान्य रूप से इस्तेमाल करते समय ओवरलोड नहीं किया जाना चाहिए. हालांकि,
अलग-अलग मामलों के हिसाब से इनका इस्तेमाल किया जा सकता है. ऐसा तब ही किया जा सकता है, जब यह कॉम्बिनेशन सही तरीके से जुड़ी
शर्त को पूरा करता हो. रिज़र्व किए गए कॉम्बिनेशन के उदाहरण:
"reboot,userrequested"
"shutdown,userrequested"
"shutdown,thermal"
(thermald
से)"shutdown,battery"
"shutdown,battery,thermal"
(BatteryStatsService
से)"reboot,adb"
"reboot,shell"
"reboot,bootloader"
"reboot,recovery"
ज़्यादा जानकारी के लिए, system/core/bootstat/bootstat.cpp
में kBootReasonMap
और Android के सोर्स डेटा स्टोर करने की जगह में इससे जुड़ा Git
चेंजलॉग इतिहास देखें.
बूट करने की वजहों की रिपोर्ट करें
बूटलोडर से ली गई या कैननिकल बूट
वजह में रिकॉर्ड की गई सभी वजहों को
system/core/bootstat/bootstat.cpp
के kBootReasonMap
सेक्शन में रिकॉर्ड किया जाना चाहिए.
kBootReasonMap
सूची में, नियमों का पालन न करने वाली और लेगसी
वजहों से शामिल किए गए हैं. बूटलोडर डेवलपर को यहां सिर्फ़ ऐसी नई वजहें
रजिस्टर करनी चाहिए जो नियमों का पालन नहीं करती हैं. अगर प्रॉडक्ट पहले ही शिप किया जा चुका है और उसे बदला नहीं जा सकता, तो
उन्हें नीति का पालन न करने वाली वजहों को रजिस्टर नहीं करना चाहिए.
हमारा सुझाव है कि
system/core/bootstat/bootstat.cpp
में, नीतियों का पालन करने वाली मौजूदा एंट्री का इस्तेमाल करें. साथ ही, नीतियों का पालन न करने वाली स्ट्रिंग का इस्तेमाल करने से पहले,
पाबंदियों का पालन करें. दिशा-निर्देश के हिसाब से, इसमें:
- बूटलोडर से
"kernel_panic"
की शिकायत करने में ठीक है. हालांकि,bootstat
kernel_panic signatures
के लिएramoops
की जांच कर सकता है, ताकि कैननिकलsystem_boot_reason_prop
में सब वजहों को बेहतर बना सके. kBootReasonMap
में, नीति का पालन न करने वाली स्ट्रिंग (जैसे कि बूटलोडर से"panic")
) की शिकायत करना ठीक नहीं है. ऐसा करने पर,reason
को बेहतर बनाने की सुविधा काम नहीं करेगी.
उदाहरण के लिए, अगर kBootReasonMap
में "wdog_bark"
है,
तो बूटलोडर डेवलपर को यह करना चाहिए:
"watchdog,bark"
में बदलें औरkBootReasonMap
में सूची में जोड़ें.- सोचें कि जिन लोगों को टेक्नोलॉजी के बारे में नहीं पता है उनके लिए
"bark"
का क्या मतलब है. साथ ही, यह तय करें कि उनसे बेहतरsubreason
उपलब्ध हो या नहीं.
पुष्टि करें कि बूट करने की वजह, चालू है
इस समय, Android ऐसा ऐक्टिव सीटीएस टेस्ट उपलब्ध नहीं कराता है जो बूटलोडर के चालू होने की सभी संभावित वजहों को सही तरीके से ट्रिगर कर सके या उनकी जांच कर सके. पार्टनर अब भी पैसिव टेस्ट चलाकर यह पता लगा सकते हैं कि वे काम करते हैं या नहीं.
इसलिए, बूटलोडर के नियमों का पालन करना ज़रूरी है. इसके लिए ज़रूरी है कि बूटलोडर डेवलपर
अपने मन से ऊपर बताए गए नियमों और दिशा-निर्देशों का पालन करें.
हम ऐसे डेवलपर से अनुरोध करते हैं कि वे एओएसपी (खास तौर पर, system/core/bootstat/bootstat.cpp
के लिए) में योगदान दें. साथ ही, इस अवसर का इस्तेमाल, बूट की वजह से जुड़ी समस्याओं के बारे में चर्चा करने के लिए फ़ोरम के तौर पर करें.