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