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

Android 9 में बूटलोडर को चालू करने की वजह से जुड़ी खास जानकारी में ये बदलाव शामिल हैं.

चालू करने की वजहें

बूटलोडर, अच्छी तरह से उपलब्ध हार्डवेयर और मेमोरी संसाधनों का इस्तेमाल करता है, ताकि पता करें कि उपकरण क्यों रीबूट हुआ है, तो निर्धारण androidboot.bootreason=<reason> को Android में जोड़ा जा रहा है कर्नेल कमांड लाइन जोड़ें. 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 पेज चुने जा सकते हैं.

कैननिकल बूट करने की वजह का फ़ॉर्मैट

bootloader_boot_reason_prop के लिए कैननिकल बूट वजह फ़ॉर्मैट Android 9 में इस सिंटैक्स का इस्तेमाल करता है:

<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 देखें) kernel में ड्राइवर) बैकिंग स्टोर में स्थायी सामग्री होती है.
  • "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"

ज़्यादा जानकारी के लिए, kBootReasonMap को इसमें देखें system/core/bootstat/bootstat.cpp और इससे जुड़ा git Android सोर्स डेटा स्टोर करने की जगह में चेंजलॉग इतिहास.

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

बूट लोड करने की सभी वजहें, चाहे वे बूटलोडर से हों या कैननिकल बूट में रिकॉर्ड की गई हों कारण, इसे इसके kBootReasonMap अनुभाग में रिकॉर्ड किया जाना चाहिए system/core/bootstat/bootstat.cpp. कॉन्टेंट बनाने 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) और इस अवसर का इस्तेमाल पर चर्चा के लिए फ़ोरम.