कई उपयोगकर्ता काफ़ी हद तक अपने फ़ोन पर निर्भर रहते हैं. उन्हें ऐसे डिवाइस की ज़रूरत होती है जो ठीक से काम करता हो समय. हालांकि, कभी-कभी डिवाइस फिर से चालू होने के लूप में चले जाते हैं. इस वजह से उपयोगकर्ता ऐसा नहीं करते सहायता टिकट या वारंटी के बारे में सवाल पूछें. इसके लिए यह प्रोसेस परेशान करती है और मोबाइल और इंटरनेट सेवा देने वाली कंपनियों के लिहाज़ से महंगा.
Android 8.0 में एक ऐसी सुविधा शामिल है जो "रेस्क्यू पार्टी" भेजती है जब उसे पता चलता है कोर सिस्टम के कॉम्पोनेंट क्रैश लूप में अटक गए हैं. इसके बाद, रेस्क्यू पार्टी आगे बढ़ती है डिवाइस को वापस पाने के लिए कार्रवाइयों की सीरीज़. आखिरी उपाय के तौर पर, रेस्क्यू पार्टी डिवाइस को रिकवरी मोड में फिर से चालू करता है और उपयोगकर्ता को फ़ैक्ट्री चलाने का प्रॉम्प्ट भेजता है रीसेट करें.
इन बचाव सुविधाओं की ज़रूरत Android कम्पैटिबिलिटी डेफ़िनिशन दस्तावेज़ (कंपैटबिलिटी डेफ़िनिशन दस्तावेज़). हालांकि, यह सहायता मामलों को कम करने में अब भी मददगार साबित हो सकता है.
लागू करना
Rescue Party की सुविधा Android 8.0 में, डिफ़ॉल्ट रूप से चालू रहती है. यह सुविधा इसमें मौजूद रहती है
/services/core/java/com/android/server/RescueParty.java.
Rescue पार्टी को बूट और क्रैश इवेंट के बारे में जानकारी मिलती है और वह तब शुरू होती है, जब:
- सिस्टम_सर्वर 5 मिनट में पांच से ज़्यादा बार रीस्टार्ट होता है.
- परसिस्टेंट सिस्टम ऐप्लिकेशन, 30 सेकंड में पांच से ज़्यादा बार क्रैश होता है.
ऐसे किसी भी मामले का पता चलने पर, रेस्क्यू पार्टी अगला पक्ष आगे बढ़ जाती है रेस्क्यू लेवल, उस लेवल से जुड़े टास्क को प्रोसेस करता है, और डिवाइस को और देखें कि वह ठीक होता है या नहीं. गेम का हर लेवल, पहले के मुकाबले ज़्यादा इससे क्या ख़ाली या रीसेट होता है. आखिरी लेवल पर, उपयोगकर्ता को फ़ैक्ट्री रीसेट करने के लिए कहा जाता है. डिवाइस.
रेस्क्यू पार्टी की सहायता के लिए किसी खास हार्डवेयर सहायता की ज़रूरत नहीं है. अगर लागू किया जाता है,
रिकवरी सिस्टम को
--prompt_and_wipe_data निर्देश और डिवाइसों को यह ज़रूरी है
उपयोगकर्ताओं को ऐसा तरीका उपलब्ध कराना होगा जिससे वे उपयोगकर्ता का डेटा मिटाए जाने से पहले, उसकी पुष्टि कर सकें
आगे बढ़ें. रिकवरी सिस्टम में उपयोगकर्ता को
डिवाइस को फिर से चालू करने की कोशिश कर रहा है.
ऐसा इसलिए, क्योंकि किसी डिवाइस के काम करने से पहले, बचाव का हर लेवल पांच मिनट तक का हो सकता है याद रखें, डिवाइस बनाने वाली कंपनियों को कस्टम रेस्क्यू लेवल नहीं जोड़ने चाहिए. बढ़ा हुआ समय इस्तेमाल न किए जाने वाले डिवाइस का इस्तेमाल करने से, लोगों के लिए सहायता शुरू करने की संभावना बढ़ जाती है या अपने डिवाइस को खुद वापस पाने के बजाय, वारंटी से जुड़े मामलों की जांच करने का मौका मिलता है.
पुष्टि करें
जब डिवाइस में कोई चालू यूएसबी डेटा होता है, तो बचाव से जुड़े सभी इवेंट रोक दिए जाते हैं कनेक्शन बनाया जा रहा है, क्योंकि इससे पता चलता है कि कोई व्यक्ति डिवाइस को डीबग कर रहा है.
इस सेटिंग को बदलने के लिए, इसे चलाएं:
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
दोनों क्रैश लूप, रेस्क्यू लॉजिक शुरू करते हैं. बचाव से जुड़े सभी काम भी चल रहे हैं
पर सेव किए गए लगातार PackageManager लॉग में लॉग किया जाता है
बाद में जांच और डीबग करने के लिए /data/system/uiderrors.txt.
इन स्थायी लॉग को "पैकेज
चेतावनी मैसेज" सेक्शन में जाएं.