बचाव दल

कई उपयोगकर्ता अपने फ़ोन पर बहुत अधिक निर्भर रहते हैं और उन्हें हर समय एक कार्यशील उपकरण की आवश्यकता होती है। हालाँकि, कभी-कभी डिवाइस रिबूट लूप में समाप्त हो जाते हैं, जिसके कारण उपयोगकर्ताओं को समर्थन टिकट या वारंटी पूछताछ दर्ज करनी पड़ती है। यह प्रक्रिया उपयोगकर्ताओं के लिए निराशाजनक है और डिवाइस निर्माताओं और वाहकों के लिए महंगी है।

एंड्रॉइड 8.0 में एक सुविधा शामिल है जो क्रैश लूप में फंसे कोर सिस्टम घटकों को नोटिस करने पर "बचाव पार्टी" भेजती है। फिर बचाव दल डिवाइस को पुनर्प्राप्त करने के लिए कार्रवाई की एक श्रृंखला के माध्यम से आगे बढ़ता है। अंतिम उपाय के रूप में, रेस्क्यू पार्टी डिवाइस को रिकवरी मोड में रीबूट करती है और उपयोगकर्ता को फ़ैक्टरी रीसेट करने के लिए संकेत देती है।

एंड्रॉइड संगतता परिभाषा दस्तावेज़ के लिए इन बचाव सुविधाओं की आवश्यकता नहीं है, लेकिन फिर भी समर्थन मामलों को कम करने के लिए उपयोगी हो सकते हैं।

कार्यान्वयन

एंड्रॉइड 8.0 में रेस्क्यू पार्टी डिफ़ॉल्ट रूप से सक्षम है, और कार्यान्वयन /services/core/java/com/android/server/RescueParty.java में रहता है। बचाव दल बूट और क्रैश घटनाओं के बारे में जानकारी प्राप्त करता है और यदि शुरू होता है:

• System_server 5 मिनट में 5 से अधिक बार पुनरारंभ होता है।
• एक सतत सिस्टम ऐप 30 सेकंड में 5 से अधिक बार क्रैश होता है।

जब इनमें से किसी एक स्थिति का पता चलता है, तो बचाव दल अगले बचाव स्तर तक बढ़ जाता है, उस स्तर से जुड़े कार्य को संसाधित करता है, और डिवाइस को यह देखने के लिए आगे बढ़ने देता है कि क्या वह ठीक हो गया है। प्रत्येक स्तर जो साफ़ या रीसेट करता है उसमें उत्तरोत्तर अधिक आक्रामक होता है। अंतिम स्तर उपयोगकर्ता को डिवाइस को फ़ैक्टरी रीसेट करने के लिए प्रेरित करता है।

रेस्क्यू पार्टी का समर्थन करने के लिए किसी विशेष हार्डवेयर समर्थन की आवश्यकता नहीं है। यदि लागू किया जाता है, तो डिवाइस की पुनर्प्राप्ति प्रणाली को --prompt_and_wipe_data कमांड का जवाब देना होगा और आगे बढ़ने से पहले डिवाइस को उपयोगकर्ताओं के लिए उपयोगकर्ता डेटा के किसी भी विनाश की पुष्टि करने का एक तरीका सामने लाना होगा। पुनर्प्राप्ति प्रणाली को उपयोगकर्ता को अपने डिवाइस को दोबारा बूट करने का प्रयास करने का विकल्प भी देना चाहिए।

चूँकि प्रत्येक बचाव स्तर किसी उपकरण के दोबारा संचालन योग्य होने में 5 मिनट तक का समय लगा सकता है, इसलिए उपकरण निर्माताओं को कस्टम बचाव स्तर नहीं जोड़ना चाहिए। निष्क्रिय डिवाइस के साथ समय बढ़ने से उपयोगकर्ताओं को अपने डिवाइस को स्वयं पुनर्प्राप्त करने के बजाय समर्थन या वारंटी पूछताछ शुरू करने की अधिक संभावना होती है।

मान्यकरण

जब डिवाइस में सक्रिय यूएसबी डेटा कनेक्शन होता है तो सभी बचाव घटनाएं दबा दी जाती हैं क्योंकि यह एक मजबूत संकेत है कि कोई डिवाइस को डीबग कर रहा है।

इस दमन को ओवरराइड करने के लिए, चलाएँ:

adb shell setprop persist.sys.enable_rescue 1

वहां से, आप सिस्टम या यूआई क्रैश लूप ट्रिगर कर सकते हैं।

निम्न-स्तरीय system_server क्रैश लूप ट्रिगर करने के लिए, चलाएँ:

adb shell setprop debug.crash_system 1

मध्य-स्तरीय SystemUI क्रैश लूप को ट्रिगर करने के लिए, चलाएँ:

adb shell setprop debug.crash_sysui 1

दोनों क्रैश लूप बचाव तर्क आरंभ करते हैं। बाद के निरीक्षण और डिबगिंग के लिए सभी बचाव कार्यों को /data/system/uiderrors.txt पर संग्रहीत लगातार पैकेजमैनेजर लॉग में भी लॉग किया जाता है। ये लगातार लॉग "पैकेज चेतावनी संदेश" अनुभाग के अंतर्गत प्रत्येक बग रिपोर्ट में भी शामिल हैं।