कैननिकल बूट की वजह

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) इस प्रॉपर्टी को फिर से लिख सकता है. हालांकि, सभी ऐप्लिकेशन को इसे पढ़ने के लिए, sepolicy से जुड़े अधिकार दिए जा सकते हैं.
  • उपयोगकर्ताओं को, 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 के साथ).

Bootstat लॉजिक, ज़्यादा जानकारी देने वाले और ज़रूरी शर्तों को पूरा करने वाले 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 (टर्मिनेशन या कॉमा से पहले का पहला स्पैन) के लिए दी गई वैल्यू, नीचे दिए गए सेट में से किसी एक में होनी चाहिए. इसे कोर, स्ट्रॉन्ग, और ब्लंट वजहों में बांटा गया है:

  • kernel set:
    • "watchdog"
    • "kernel_panic"
  • ज़्यादा सेट:
    • "recovery"
    • "bootloader"
  • ब्लंट सेट:
    • "cold". आम तौर पर, इससे सभी डिवाइसों का पूरा रीसेट होता है. इसमें मेमोरी भी शामिल है.
    • "hard". आम तौर पर, इससे पता चलता है कि हार्डवेयर की स्थिति को रीसेट कर दिया गया है और ramoops में मौजूद कॉन्टेंट को बनाए रखा जाना चाहिए.
    • "warm". आम तौर पर, इससे पता चलता है कि मेमोरी और डिवाइसों में कुछ जानकारी सेव रहती है. साथ ही, ramoops (pstore कर्नेल में ड्राइवर देखें) बैकिंग स्टोर में हमेशा मौजूद कॉन्टेंट होता है.
    • "shutdown"
    • "reboot". आम तौर पर इसका मतलब है कि ramoops की स्थिति के बारे में जानकारी नहीं है और हार्डवेयर की स्थिति के बारे में जानकारी नहीं है. यह वैल्यू सभी के लिए है, क्योंकि cold, hard, और warm वैल्यू से, डिवाइस के रीसेट होने के बारे में पता चलता है.

बूटलोडर को एक कर्नेल सेट या ब्लंट सेट reason देना होगा. अगर subreason तय किया जा सकता है, तो हमारा सुझाव है कि आप 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 सोर्स रिपॉज़िटरी में, उससे जुड़े बदलावों का इतिहास देखें.

डिवाइस के बूट होने की वजहों की रिपोर्ट करना

बूट होने की सभी वजहें, बूटलोडर से या कैननिकल बूट होने की वजह के तौर पर रिकॉर्ड की गई वजहें, system/core/bootstat/bootstat.cpp के kBootReasonMap सेक्शन में रिकॉर्ड की जानी चाहिए. kBootReasonMap सूची में, नीतियों का पालन न करने और नीतियों का पालन करने से जुड़ी वजहें शामिल होती हैं. बूटलोडर डेवलपर को यहां सिर्फ़ नई वजहें रजिस्टर करनी चाहिए, जो नीति के मुताबिक हों. साथ ही, नीति का पालन न करने की वजहें तब तक रजिस्टर नहीं करनी चाहिए, जब तक कि प्रॉडक्ट पहले से ही शिप न हो गया हो और उसमें बदलाव न किया जा सके.

हमारा सुझाव है कि आप system/core/bootstat/bootstat.cpp में, मौजूदा और नियमों का पालन करने वाली एंट्री का इस्तेमाल करें. साथ ही, नियमों का पालन न करने वाली स्ट्रिंग का इस्तेमाल करने से पहले, सावधानी बरतें. दिशा-निर्देश के तौर पर, यह है:

  • ठीक है, ताकि bootloader से "kernel_panic" की शिकायत की जा सके. ऐसा इसलिए, क्योंकि bootstat, kernel_panic signatures के लिए ramoops की जांच कर सकता है, ताकि सब-वजह को कैननिकल system_boot_reason_prop में बेहतर बनाया जा सके.
  • kBootReasonMap में, नीतियों का पालन न करने वाली स्ट्रिंग की शिकायत करना ठीक नहीं है. जैसे, bootloader से "panic"), क्योंकि इससे reason को बेहतर बनाने की सुविधा काम नहीं करेगी.

उदाहरण के लिए, अगर kBootReasonMap में "wdog_bark" है, तो bootloader डेवलपर को:

  • इसे "watchdog,bark" में बदलें और सूची में kBootReasonMap में जोड़ें.
  • देखें कि टेक्नोलॉजी के बारे में जानकारी न रखने वाले लोगों के लिए, "bark" का क्या मतलब है. साथ ही, यह तय करें कि क्या कोई ऐसा "bark" उपलब्ध है जो ज़्यादा काम का हो.subreason

बूट करने की वजह से जुड़ी नीति का पालन करने की पुष्टि करना

फ़िलहाल, Android ऐसा कोई चालू CTS टेस्ट उपलब्ध नहीं कराता है जो बूटलोडर से मिलने वाली सभी संभावित वजहों को सटीक तरीके से ट्रिगर या जांच कर सके. हालांकि, पार्टनर अब भी काम करने की जांच करने के लिए, पैसिव टेस्ट चला सकते हैं.

इसलिए, बूटलोडर के लिए बने नियमों का पालन करने के लिए, बूटलोडर डेवलपर को ऊपर बताए गए नियमों और दिशा-निर्देशों का पालन करना होगा. हम ऐसे डेवलपर से अनुरोध करते हैं कि वे AOSP (खास तौर पर system/core/bootstat/bootstat.cpp) में योगदान दें. साथ ही, इस फ़ोरम का इस्तेमाल, बूट होने से जुड़ी समस्याओं के बारे में चर्चा करने के लिए करें.