कैनोनिकल बूट कारण

एंड्रॉइड 9 में बूटलोडर बूट कारण विनिर्देश में निम्नलिखित परिवर्तन शामिल हैं।

बूट कारण

एक बूटलोडर यह निर्धारित करने के लिए विशिष्ट रूप से उपलब्ध हार्डवेयर और मेमोरी संसाधनों का उपयोग करता है कि डिवाइस रीबूट क्यों हुआ, फिर इसके लॉन्च के लिए एंड्रॉइड कर्नेल कमांड लाइन में androidboot.bootreason=<reason> जोड़कर उस निर्धारण को संचारित करता है। init फिर एंड्रॉइड प्रॉपर्टी bootloader_boot_reason_prop ( ro.boot.bootreason ) को प्रसारित करने के लिए इस कमांड लाइन का अनुवाद करता है। एंड्रॉइड 12 या उसके बाद लॉन्च होने वाले उपकरणों के लिए, कर्नेल संस्करण 5.10 या उससे अधिक का उपयोग करते हुए, androidboot.bootreason=<reason> को कर्नेल कमांड लाइन के बजाय बूटकॉन्फिग में जोड़ा जाता है।

बूट कारण विशिष्टताएँ

एंड्रॉइड के पिछले रिलीज में एक बूट कारण प्रारूप निर्दिष्ट किया गया था जिसमें कोई रिक्त स्थान का उपयोग नहीं किया गया था, सभी लोअरकेस थे, इसमें कुछ आवश्यकताएं शामिल थीं (जैसे कि kernel_panic , watchdog , cold / warm / hard रिपोर्टिंग के लिए), और जो अन्य अद्वितीय कारणों के लिए अनुमति देता था। इस ढीले विनिर्देश के परिणामस्वरूप सैकड़ों कस्टम (और कभी-कभी अर्थहीन) बूट कारण स्ट्रिंग्स का प्रसार हुआ, जिसके परिणामस्वरूप एक असहनीय स्थिति पैदा हुई। वर्तमान एंड्रॉइड रिलीज़ के अनुसार, बूटलोडर द्वारा दायर की गई लगभग अप्राप्य या अर्थहीन सामग्री की तीव्र गति ने bootloader_boot_reason_prop के लिए अनुपालन समस्याएं पैदा कर दी हैं।

एंड्रॉइड 9 रिलीज के साथ, एंड्रॉइड टीम मानती है कि लीगेसी bootloader_boot_reason_prop में पर्याप्त गति है और इसे रनटाइम पर दोबारा नहीं लिखा जा सकता है। इसलिए बूट कारण विनिर्देश में कोई भी सुधार बूटलोडर डेवलपर्स के साथ बातचीत और मौजूदा सिस्टम में बदलाव से आना चाहिए। उस अंत तक एंड्रॉइड टीम है:

• बूटलोडर डेवलपर्स को प्रोत्साहित करने के लिए उनसे जुड़ना:
  • 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 बूट के प्रारंभ में उपलब्ध है, इसे एंड्रॉइड सुरक्षा नीति द्वारा आवश्यकता के आधार पर अवरुद्ध कर दिया गया है क्योंकि यह गलत, अप्राप्य और गैर-विहित जानकारी का प्रतिनिधित्व करता है। अधिकांश स्थितियों में, केवल बूट सिस्टम का गहन ज्ञान रखने वाले डेवलपर्स को ही इस जानकारी तक पहुंचने की आवश्यकता होनी चाहिए। system_boot_reason_prop के माध्यम से बूट कारण के लिए एक परिष्कृत, पार्स करने योग्य और विहित एपीआई को उपयोगकर्ता डेटा माउंट होने के बाद ही विश्वसनीय और सटीक रूप से उठाया जा सकता है। विशेष रूप से:

• उपयोगकर्ताडेटा माउंट होने से पहले , system_boot_reason_prop bootloader_boot_reason_prop का मान शामिल होगा।
• उपयोगकर्ता डेटा माउंट होने के बाद , system_boot_reason_prop अनुपालन के लिए या अधिक सटीक जानकारी रिपोर्ट करने के लिए अद्यतन किया जा सकता है।

इस कारण से, एंड्रॉइड 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" (पसंदीदा)।

कारण-उपकारण संयोग

एंड्रॉइड 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 कैनोनिकल system_boot_reason_prop में उप-कारणों को परिष्कृत करने के लिए kernel_panic signatures के लिए ramoops निरीक्षण करने में सक्षम हो सकता है।
• बूटलोडर से kBootReasonMap (जैसे "panic") में एक गैर-अनुपालक स्ट्रिंग की रिपोर्ट करना ठीक नहीं है , क्योंकि यह अंततः reason को परिष्कृत करने की क्षमता को तोड़ देगा।

उदाहरण के लिए, यदि kBootReasonMap में "wdog_bark" शामिल है, तो एक बूटलोडर डेवलपर को यह करना चाहिए:

• "watchdog,bark" में बदलें और kBootReasonMap में सूची में जोड़ें।
• विचार करें कि प्रौद्योगिकी से अपरिचित लोगों के लिए "bark" क्या अर्थ है और निर्धारित करें कि क्या अधिक सार्थक subreason उपलब्ध है।

बूट कारण अनुपालन का सत्यापन

इस समय, एंड्रॉइड एक सक्रिय सीटीएस परीक्षण प्रदान नहीं करता है जो बूटलोडर द्वारा प्रदान किए जा सकने वाले सभी संभावित बूट कारणों को सटीक रूप से ट्रिगर या निरीक्षण कर सकता है; संगतता निर्धारित करने के लिए भागीदार अभी भी एक निष्क्रिय परीक्षण चलाने का प्रयास कर सकते हैं।

परिणामस्वरूप, बूटलोडर अनुपालन के लिए बूटलोडर डेवलपर्स को ऊपर वर्णित नियमों और दिशानिर्देशों की भावना का स्वेच्छा से पालन करने की आवश्यकता होती है। हम ऐसे डेवलपर्स से AOSP (विशेष रूप से system/core/bootstat/bootstat.cpp ) में योगदान करने का आग्रह करते हैं और बूट कारण मुद्दों के बारे में चर्चा के लिए एक मंच के रूप में इस अवसर का उपयोग करते हैं।