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

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 के लिए) में योगदान दें. साथ ही, इस अवसर का इस्तेमाल, बूट की वजह से जुड़ी समस्याओं के बारे में चर्चा करने के लिए फ़ोरम के तौर पर करें.