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 कमांड का जवाब देना होगा. साथ ही, डिवाइसों को उपयोगकर्ताओं को यह पुष्टि करने का तरीका देना होगा कि उपयोगकर्ता के डेटा को मिटाने से पहले, वे ऐसा करना चाहते हैं. रिकवरी सिस्टम में, उपयोगकर्ता को अपने डिवाइस को फिर से बूट करने का विकल्प भी मिलना चाहिए.

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

सत्यापन

डिवाइस में यूएसबी डेटा कनेक्शन चालू होने पर, 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

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

  adb shell setprop debug.crash_sysui 1

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