Rescue Party

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

Android 8.0 (एपीआई लेवल 26) और इसके बाद के वर्शन में, एक ऐसी सुविधा शामिल है जो क्रैश लूप में फंसे मुख्य सिस्टम कॉम्पोनेंट का पता चलने पर, उन्हें ठीक करने की प्रोसेस शुरू कर देती है. इस सिग्नल पर, डिवाइस को ठीक करने के लिए Rescue Party सुविधा कई कार्रवाइयां करती है. आखिरी विकल्प के तौर पर, Rescue Party डिवाइस को रिकवरी मोड में रीबूट करता है. साथ ही, उपयोगकर्ता को डिवाइस को फ़ैक्ट्री रीसेट करने के लिए कहता है.

लागू करना

Rescue Party की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इसे /services/core/java/com/android/server/RescueParty.java में लागू किया जाता है. Rescue Party को बूट और क्रैश इवेंट के बारे में जानकारी मिलती है. यह सुविधा तब शुरू होती है, जब:

  • system_server पांच मिनट में पांच से ज़्यादा बार रीस्टार्ट होता है.
  • कोई सिस्टम ऐप्लिकेशन, 30 सेकंड में पांच से ज़्यादा बार क्रैश होता है.

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

Rescue Party के लिए, किसी खास हार्डवेयर की ज़रूरत नहीं होती. अगर इस सुविधा को लागू किया जाता है, तो डिवाइस के रिकवरी सिस्टम को --prompt_and_wipe_data कमांड का जवाब देना होगा. साथ ही, डिवाइसों को उपयोगकर्ताओं को यह पुष्टि करने का तरीका देना होगा कि उपयोगकर्ता के डेटा को मिटाने से पहले, वे ऐसा करना चाहते हैं. रिकवरी सिस्टम में, उपयोगकर्ता को अपने डिवाइस को फिर से बूट करने का विकल्प भी मिलना चाहिए.

हर रेस्क्यू लेवल में, डिवाइस को फिर से चालू करने में पांच मिनट तक लग सकते हैं. इसलिए, डिवाइस बनाने वाली कंपनियों को कस्टम रेस्क्यू लेवल नहीं जोड़ने चाहिए. डिवाइस के ठीक न होने पर, उपयोगकर्ता उसे ठीक करने के बजाय सहायता पाने या वारंटी के बारे में पूछताछ करने की कोशिश करते हैं.

Validation

जब डिवाइस में यूएसबी डेटा कनेक्शन चालू होता है, तब Rescue Party सभी रीबूट इवेंट को बंद कर देता है. ऐसा इसलिए, क्योंकि यह एक मज़बूत सिग्नल है कि कोई व्यक्ति डिवाइस को डीबग कर रहा है.

इस रोक को हटाने के लिए, यह कमांड चलाएं:

adb shell setprop persist.sys.enable_rescue 1

इसके बाद, सिस्टम या यूज़र इंटरफ़ेस (यूआई) के क्रैश लूप को ट्रिगर करें:

  • लो-लेवल system_server क्रैश लूप को ट्रिगर करने के लिए, यह कमांड चलाएं:

    adb shell setprop debug.crash_system 1
adb shell stop
adb shell start

  • सिस्टम यूआई के क्रैश लूप को ट्रिगर करने के लिए, यह कमांड चलाएं:

    adb shell setprop debug.crash_sysui 1

दोनों क्रैश लूप, बचाव की प्रोसेस शुरू करते हैं. Rescue Party, सभी बचाव कार्रवाइयों को PackageManager के परसिस्टेंट लॉग में भी सेव करता है. ये लॉग, /data/system/uiderrors.txt पर सेव होते हैं, ताकि बाद में इनकी जांच की जा सके और गड़बड़ियों को ठीक किया जा सके. बग रिपोर्ट में, पैकेज से जुड़ी चेतावनी के मैसेज सेक्शन में ये परसिस्टेंट लॉग भी शामिल होते हैं.