कैश मेमोरी में सेव किए गए ऐप्लिकेशन को फ़्रीज़ करने की सुविधा

Android 11 (एपीआई लेवल 30) या इसके बाद के वर्शन में, कैश मेमोरी में सेव किए गए ऐप्लिकेशन को फ़्रीज़ करने की सुविधा काम करती है. इस सुविधा की मदद से, कैश मेमोरी में सेव की गई प्रोसेस को बंद किया जा सकता है. साथ ही, इससे ऐसे ऐप्लिकेशन के रिसोर्स के इस्तेमाल को कम किया जा सकता है जो कैश मेमोरी में सेव होने के दौरान काम करने की कोशिश करते हैं.

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

Android, कैश मेमोरी में सेव किए गए ऐप्लिकेशन को फ़्रीज़ कर देता है. इसके लिए, वह उनकी प्रोसेस को फ़्रीज़ किए गए cgroup में माइग्रेट करता है. इससे, कैश मेमोरी में सेव किए गए ऐप्लिकेशन के चालू होने पर, सीपीयू की खपत कम होती है. सिस्टम कॉन्फ़िगरेशन फ़्लैग या डेवलपर विकल्प का इस्तेमाल करके, ऐप्लिकेशन फ़्रीज़ करने की सुविधा चालू की जा सकती है.

Android 14 (एपीआई लेवल 34) और इसके बाद के वर्शन में, कैश मेमोरी में सेव किए गए ऐप्लिकेशन को फ़्रीज़ करने की सुविधा में ये बेहतर सुविधाएं शामिल हैं:

• कैश मेमोरी में सेव किए गए ऐप्लिकेशन की प्रोसेस, कैश मेमोरी में सेव होने के 10 सेकंड बाद बंद हो जाती हैं.
• लाइफ़साइकल इवेंट के दौरान, सिस्टम फ़्रीज़ की गई ऐप्लिकेशन प्रोसेस को तुरंत अनफ़्रीज़ कर देता है. इन इवेंट में, इंटेंट पाना, जॉब सर्विस शुरू करना या उपयोगकर्ता के गतिविधि फिर से शुरू करना शामिल है.

ActivityManagerService ऐप्लिकेशन की सभी प्रोसेस को मैनेज करता है और ऐप्लिकेशन के लाइफ़साइकल से जुड़े फ़ैसले लेता है. ऐप्लिकेशन की प्रोसेस को फ़्रीज़ करने की ज़िम्मेदारी CachedAppOptimizer की है.

जब किसी ऐप्लिकेशन की प्रोसेस फ़्रीज़ हो जाती है, तो उसके सभी थ्रेड निलंबित हो जाते हैं. साथ ही, जब तक उन्हें अनफ़्रीज़ नहीं किया जाता, तब तक वे सीपीयू का इस्तेमाल नहीं कर सकते. इस वजह से, ऐप्लिकेशन गार्बेज कलेक्शन (जीसी) नहीं कर पाता और मेमोरी ट्रिम इवेंट का जवाब नहीं दे पाता. ज़्यादा जानकारी के लिए, ComponentCallbacks2.onTrimMemory(int) देखें. इसके लिए, Android 14 से ये बदलाव किए गए हैं:

• Activity इंस्टेंस वाले ऐप्लिकेशन को, बैकग्राउंड में जाने के तुरंत बाद TRIM_MEMORY_UI_HIDDEN की सूचना दी जाती है. ऐसे ऐप्लिकेशन जो यूज़र इंटरफ़ेस (यूआई) के बिना लाइफ़साइकल में बने रहते हैं उन्हें TRIM_MEMORY_BACKGROUND मिल सकता है. जैसे, फ़ोरग्राउंड सेवा वाले ऐप्लिकेशन. ट्रिम किए गए अन्य इवेंट डिलीवर नहीं किए जाते, क्योंकि जब ऐप्लिकेशन इन इवेंट के लिए ज़रूरी शर्तें पूरी करते हैं, तो उन्हें फ़्रीज़ कर दिया जाता है.
• कैश किए गए स्टेटस में जाने के कुछ समय बाद, सिस्टम ऐप्लिकेशन रनटाइम से GC करने का अनुरोध कर सकता है, ताकि फ़्रीज़ होने की स्थिति में तैयारी की जा सके.
• जब किसी ऐप्लिकेशन की प्रोसेस फ़्रीज़ हो जाती है, तो मेमोरी कंपैक्शन के अतिरिक्त चरण हो सकते हैं. जैसे, डर्टी पेजों को बैकिंग स्टोरेज में लिखना और गुमनाम पेजों को ZRAM में स्वैप करना.
• अगर किसी ऐप्लिकेशन की सभी प्रोसेस फ़्रीज़ हो जाती हैं, तो सिस्टम उस ऐप्लिकेशन के चालू टीसीपी सॉकेट को बंद कर देता है. इससे सॉकेट का सर्वर साइड, टीसीपी कीपअलाइव पिंग नहीं भेज पाता. इससे डिवाइस का मॉडेम चालू नहीं होता.

जब किसी ऐप्लिकेशन की प्रोसेस की स्थिति, कैश मेमोरी में सेव किए गए डेटा से बदलकर ज़्यादा ज़रूरी स्थिति में पहुंच जाती है, तब कैश मेमोरी में सेव की गई ऐप्लिकेशन प्रोसेस को अनफ़्रीज़ कर दिया जाता है. Android 14 और इसके बाद के वर्शन में, अनफ़्रीज़ इवेंट कम करने के लिए सिस्टम, कॉन्टेक्स्ट-रजिस्टर्ड ब्रॉडकास्ट को तब तक कतार में रखता है, जब तक ऐप्लिकेशन कैश मेमोरी में सेव रहता है. कॉन्टेक्स्ट के हिसाब से रजिस्टर किए गए ब्रॉडकास्ट, ऐसे रिसीवर होते हैं जिन्हें कोई ऐप्लिकेशन, Context.registerReceiver को कॉल करके डाइनैमिक तौर पर रजिस्टर करता है. सिस्टम, इन ब्रॉडकास्ट को सिर्फ़ तब डिलीवर करता है, जब ऐप्लिकेशन को अनफ़्रीज़ कर दिया जाता है. इसके उलट, सिस्टम मेनिफ़ेस्ट में बताए गए ब्रॉडकास्ट को कतार में नहीं रखता है. मेनिफ़ेस्ट में एलान की गई ब्रॉडकास्ट, ऐसे रिसीवर होते हैं जिनका एलान <receiver> एलिमेंट का इस्तेमाल करके, AndroidManifest.xml में स्टैटिक तौर पर किया जाता है. सिस्टम, कैश मेमोरी में सेव किए गए ऐप्लिकेशन को तुरंत अनफ़्रीज़ कर देता है, ताकि मेनिफ़ेस्ट में बताए गए ब्रॉडकास्ट डिलीवर किए जा सकें.

सिस्टम के काम करने की स्थिति पर असर

अगर MAX_CACHED_PROCESSES से ज़्यादा ऐप्लिकेशन प्रोसेस कैश की गई हैं, तो Android, सबसे कम इस्तेमाल की गई कैश की गई ऐप्लिकेशन प्रोसेस को बंद कर देता है. Android 14 या इसके बाद के वर्शन पर काम करने वाले डिवाइसों पर, MAX_CACHED_PROCESSES में काफ़ी बढ़ोतरी की गई है. इससे डिवाइस, रैम में ज़्यादा ऐप्लिकेशन प्रोसेस को कैश मेमोरी में सेव कर पाते हैं.

रैम में ज़्यादा ऐप्लिकेशन कैश मेमोरी में सेव रखने से, कोल्ड स्टार्ट में 30% तक की कमी आती है. हालांकि, यह कमी डिवाइस की कुल रैम के हिसाब से कम या ज़्यादा हो सकती है. साथ ही, कैश मेमोरी में सेव किए गए ऐप्लिकेशन से सीपीयू का इस्तेमाल कम होता है. इससे बैटरी की बचत होती है.

फ़्रीज़र के लिए छूट

कुछ स्थितियों में, ऐप्लिकेशन की प्रोसेस कैश मेमोरी में सेव हो सकती है, लेकिन वह फ़्रीज़ नहीं होती. ये छूट, लागू करने से जुड़ी जानकारी हैं. साथ ही, आने वाले समय में Android के वर्शन में बदलाव हो सकता है:

• फ़ाइल लॉक: अगर कैश मेमोरी में सेव की गई कोई प्रोसेस, फ़ाइल लॉक रखती है और इससे कैश मेमोरी में सेव नहीं की गई अन्य प्रोसेस ब्लॉक हो जाती हैं, तो लॉक रखने वाली प्रोसेस फ़्रीज़ नहीं होती.
• BIND_WAIVE_PRIORITY बाइंडिंग: Context.BIND_WAIVE_PRIORITY का इस्तेमाल करके बनाई गई, इनकमिंग बाइंडिंग वाली ऐप्लिकेशन प्रोसेस, कैश मेमोरी में सेव की गई स्थिति में जा सकती हैं. हालांकि, जब तक कनेक्ट की गई सभी क्लाइंट प्रोसेस भी कैश मेमोरी में सेव नहीं हो जातीं, तब तक ये प्रोसेस फ़्रीज़ नहीं होतीं. यह छूट, मल्टी-प्रोसेस ऐप्लिकेशन के लिए उपलब्ध है. जैसे, कस्टम टैब का इस्तेमाल करने वाले वेब ब्राउज़र.

ऐप्लिकेशन फ़्रीज़ करने की सुविधा लागू करना

कैश किए गए ऐप्लिकेशन फ़्रीज़र, कर्नल cgroup v2 फ़्रीज़र का इस्तेमाल करता है. यह सुविधा, उन डिवाइसों पर चालू की जा सकती है जिनमें इसके साथ काम करने वाला कर्नल मौजूद है. डेवलपर के लिए उपलब्ध विकल्प कैश किए गए ऐप्लिकेशन के लिए, एक्ज़ीक्यूशन को निलंबित करें को चालू करें या डिवाइस के कॉन्फ़िगरेशन फ़्लैग activity_manager_native_boot use_freezer को true पर सेट करें. उदाहरण के लिए:

adb shell device_config put activity_manager_native_boot use_freezer true && adb reboot

use_freezer फ़्लैग को false पर सेट करने या डेवलपर के लिए सेटिंग और टूल बंद करने पर, फ़्रीज़र बंद हो जाता है. उदाहरण के लिए:

adb shell device_config put activity_manager_native_boot use_freezer false && adb reboot

सॉफ़्टवेयर रिलीज़ या अपडेट में डिवाइस के कॉन्फ़िगरेशन को बदलकर, इस सेटिंग को टॉगल किया जा सकता है.

MAX_CACHED_PROCESSES को बदलने के लिए, उदाहरण के लिए, टेस्टिंग के लिए वैल्यू को 1024 पर सेट करने के लिए:

adb shell device_config put activity_manager max_cached_processes 1024
adb shell device_config set_sync_disabled_for_tests persistent

MAX_CACHED_PROCESSES को पहले जैसा करने के लिए:

adb shell device_config delete activity_manager max_cached_processes
adb shell device_config set_sync_disabled_for_tests none

Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन में, Android आधिकारिक तौर पर सार्वजनिक एपीआई उपलब्ध कराता है. जैसे, IBinder.FrozenStateChangeCallback और IBinder.addFrozenStateChangeCallback. इनकी मदद से यह देखा जा सकता है कि रिमोट प्रोसेस कब फ़्रीज़ या अनफ़्रीज़ होती हैं. ऐसे कॉम्पोनेंट जो उन ऐप्लिकेशन के साथ इंटरैक्ट करते हैं जिन्हें कैश मेमोरी में सेव किया जा सकता है, वे इन एपीआई का इस्तेमाल करके रिमोट प्रोसेस की फ़्रीज़ की गई स्थिति को ट्रैक कर सकते हैं.

डिवाइस और कर्नल से जुड़ी ज़रूरी शर्तें

कैश किए गए ऐप्लिकेशन को फ़्रीज़ करने की सुविधा के लिए, कर्नल cgroup v2 की सुविधा ज़रूरी है. इसके अलावा, IBinder.FrozenStateChangeCallback का इस्तेमाल करके, फ़्रीज़ स्टेट में बदलाव होने की सूचनाएं पाने के लिए, कर्नेल बाइंडर ड्राइवर की सुविधा ज़रूरी होती है. यह सुविधा, Android 14 (एपीआई लेवल 34) और इसके बाद के वर्शन में, Android Common Kernels (ACK) और Generic Kernel Images (GKI) में स्टैंडर्ड तौर पर उपलब्ध होती है.

यह पुष्टि की जा सकती है कि कोई डिवाइस इन सुविधाओं के साथ काम करता है या नहीं. इसके लिए, स्टैंडर्ड adb कमांड का इस्तेमाल करें. जैसे:

• देखें कि डिवाइस पर फ़्रीज़र की सुविधा चालू है या नहीं (उपयोगकर्ता या डीबग बिल्ड के लिए):

  adb shell device_config get activity_manager_native_boot use_freezer

  इसके अलावा, यह भी पुष्टि करें कि सिस्टम, प्रोसेस को फ़्रीज़ कर रहा है या नहीं:

  adb shell dumpsys activity | grep -A 20 "Apps frozen:"

• किसी भी डिवाइस के लिए, cgroup v2 फ़्रीज़र कंट्रोलर की सुविधा की उपलब्धता की जांच करें:

  पुष्टि करें कि freezer, उपलब्ध cgroup v2 कंट्रोलर में शामिल है:

  adb shell cat /sys/fs/cgroup/cgroup.controllers

  इसके अलावा, रूट किए गए डिवाइस या userdebug बिल्ड पर, पुष्टि करें कि cgroup v2 फ़्रीज़र नोड, चाइल्ड cgroup में माउंट किया गया है:

  adb root && adb shell ls /sys/fs/cgroup/uid_0/cgroup.freeze

  अगर यह फ़ाइल मौजूद है, तो इसका मतलब है कि कर्नल, cgroup v2 फ़्रीज़र के साथ काम करता है.

• देखें कि डिवाइस के फ़्रीज़ होने की स्थिति में बदलाव होने पर सूचना पाने की सुविधा उपलब्ध है या नहीं (किसी भी डिवाइस के लिए):

  Android 14 और इसके बाद के वर्शन पर काम करने वाले डिवाइसों पर, IBinder.addFrozenStateChangeCallback, कॉलबैक को रजिस्टर करता है. हालांकि, इसके लिए ज़रूरी है कि डिवाइसों में, GKI के साथ काम करने वाले बाइंडर ड्राइवर हों. अगर कर्नेल बाइंडर ड्राइवर, फ़्रीज़ करने की सूचनाएं देने की सुविधा के साथ काम नहीं करता है, तो यह तरीका UnsupportedOperationException दिखाता है.

कस्टम सुविधाओं को मैनेज करना

कैश मेमोरी में सेव होने पर, ऐप्लिकेशन की प्रोसेस से कोई काम नहीं किया जाता. हालांकि, कुछ ऐप्लिकेशन में कस्टम सुविधाएं हो सकती हैं. ये सुविधाएं, ऐसी प्रोसेस के ज़रिए काम करती हैं जो कैश मेमोरी में सेव होने के दौरान भी चलती हैं. अगर ऐसे ऐप्लिकेशन चलाने वाले डिवाइस पर ऐप्लिकेशन फ़्रीज़र की सुविधा चालू है, तो कैश मेमोरी में सेव की गई प्रोसेस फ़्रीज़ हो जाती हैं. इससे कस्टम सुविधाएं काम नहीं कर पाती हैं.

इसके बजाय, प्रोसेस के काम शुरू करने से पहले, प्रोसेस के स्टेटस को noncached में बदला जा सकता है. इस बदलाव से, ऐप्लिकेशन चालू रहते हैं. ऐक्टिव स्टेटस के उदाहरणों में, बाउंड फ़ोरग्राउंड सेवा या फ़ोरग्राउंड स्टेटस शामिल है.

आम तौर पर होने वाली गड़बड़ियां

ऐप्लिकेशन की प्रोसेस फ़्रीज़ होने पर, प्रोसेस के बीच ठीक से कम्यूनिकेट न हो पाने (आईपीसी) या टास्क शेड्यूल करने की वजह से, ऐप्लिकेशन बंद हो सकते हैं या उनमें अचानक समस्या आ सकती है.

फ़्रीज़ की गई प्रोसेस के लिए, सिंक्रोनस बाइंडर ट्रांज़ैक्शन

जब क्लाइंट ऐप्लिकेशन प्रोसेस, फ़्रीज़ की गई सर्वर ऐप्लिकेशन प्रोसेस को सिंक्रोनस बाइंडर लेन-देन भेजती है, तो सिस्टम तुरंत सर्वर ऐप्लिकेशन प्रोसेस को बंद कर देता है. इससे क्लाइंट थ्रेड को, फ़्रीज़ किए गए सर्वर से जवाब मिलने तक हमेशा के लिए ब्लॉक होने से रोका जाता है. इसके बाद, क्लाइंट थ्रेड को RemoteException मिलता है और रजिस्टर किए गए सभी लिसनर ट्रिगर हो जाते हैं. ज़्यादा जानकारी के लिए, IBinder.linkToDeath देखें.

समस्या की मुख्य वजह: आम तौर पर, यह गड़बड़ी क्लाइंट ऐप्लिकेशन में मौजूद किसी बग की वजह से होती है. जब कोई क्लाइंट किसी सेवा से जुड़ता है, तो सर्वर प्रोसेस क्लाइंट से जुड़ जाती है. साथ ही, क्लाइंट के जुड़ने से पहले, सर्वर प्रोसेस को कैश मेमोरी में सेव होने से रोका जाता है. ज़्यादा जानकारी के लिए, Context.bindService देखें. हालांकि, क्लाइंट के Context.unbindService को कॉल करने के बाद, सर्वर प्रोसेस को कैश मेमोरी में सेव किया जा सकता है और उसे फ़्रीज़ किया जा सकता है. अनबाइंड करने के बाद भी, अगर क्लाइंट कैश मेमोरी में सेव किए गए IBinder रेफ़रंस का इस्तेमाल करता है, तो इससे फ़्रीज़ की गई प्रोसेस से कम्यूनिकेट करने का जोखिम होता है.

इस समस्या से बचने के लिए, पक्का करें कि क्लाइंट ऐप्लिकेशन, Context.unbindService को कॉल करने के तुरंत बाद IBinder रेफ़रंस हटा दें.

क्लाइंट प्रोसेस के लिए रिमोट कॉलबैक मैनेज करना

क्लाइंट प्रोसेस के लिए लंबे समय तक बाइंडर कॉलबैक बनाए रखने वाली सेवाएं और सिस्टम कॉम्पोनेंट, क्लाइंट की फ़्रीज़ की गई स्थिति को ट्रैक करके, सिंक्रोनस फ़ेलियर और एसिंक्रोनस बफ़र ओवरफ़्लो को रोक सकते हैं:

• स्टेट में बदलाव होने पर सूचना पाने के लिए रजिस्टर करें: क्लाइंट प्रोसेस के फ़्रीज़र में जाने या उससे बाहर निकलने पर सूचनाएं पाने के लिए, आने वाले क्लाइंट बाइंडर टोकन पर IBinder.addFrozenStateChangeCallback का इस्तेमाल करें.
• फ़्रीज़ होने पर डिस्पैच को रोकें: जब कोई क्लाइंट STATE_FROZEN में प्रवेश करता है, तो उस क्लाइंट को कॉलबैक या स्थिति के अपडेट भेजने को रोकें.
• अनफ़्रीज़ होने पर, फिर से शुरू करें और डिलीवर करें: जब क्लाइंट STATE_UNFROZEN पर स्विच करता है, तब कॉल बैक भेजने की सुविधा फिर से शुरू करें. साथ ही, बैच किए गए या एक साथ भेजे गए ज़रूरी अपडेट डिलीवर करें.
• RemoteCallbackList का इस्तेमाल करें: RemoteCallbackList का इस्तेमाल करने वाली सिस्टम सेवाएं, कॉल करने वाले के लिए फ़्रीज़ की गई नीतियां कॉन्फ़िगर कर सकती हैं. इससे, मैन्युअल ट्रैकिंग लॉजिक को बनाए रखने के बिना, कॉलबैक भेजने की सुविधा अपने-आप रुक जाएगी और फिर से शुरू हो जाएगी. ज़्यादा जानकारी के लिए, सिस्टम सेवाओं के लिए बाइंडर फ़्रीज़र से जुड़े सुझाव लेख पढ़ें.

एसिंक्रोनस बाइंडर लेन-देन बफ़र ओवरफ़्लो

जब सर्वर ऐप्लिकेशन प्रोसेस को फ़्रीज़ किए जाने के दौरान, एसिंक्रोनस (oneway) बाइंडर लेन-देन मिलते हैं, तो लेन-देन को हर प्रोसेस के हिसाब से बफ़र किया जाता है. अगर फ़्रीज़ होने के दौरान सर्वर को बहुत ज़्यादा एसिंक्रोनस लेन-देन मिलते हैं, तो बफ़र ओवरफ़्लो हो जाता है. इसके बाद, सिस्टम सर्वर ऐप्लिकेशन प्रोसेस को बंद कर देता है.

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

खाता अनफ़्रीज़ होने पर, शेड्यूल किए गए टास्क को बार-बार पूरा करना

अगर कोई ऐप्लिकेशन बार-बार एक ही टास्क करता है, तो प्रोसेस के रुकने के दौरान उसे निलंबित कर दिया जाता है. ज़्यादा जानकारी के लिए, ScheduledThreadPoolExecutor.scheduleAtFixedRate या Timer.scheduleAtFixedRate देखें. जब प्रोसेस फिर से शुरू होती है, तो छूटे हुए सभी टास्क एक के बाद एक तुरंत पूरे हो सकते हैं.

ऐप्लिकेशन के अनफ़्रीज़ होने पर, एक साथ कई टास्क शुरू होने से रोकने के लिए, बैकग्राउंड टास्क के लिए scheduleAtFixedRate के बजाय scheduleWithFixedDelay का इस्तेमाल करें. WorkManager का इस्तेमाल भी किया जा सकता है.

ऐप्लिकेशन फ़्रीज़र की जांच करना और उससे जुड़ी समस्याओं को हल करना

यह पुष्टि करने के लिए कि ऐप्लिकेशन फ़्रीज़ करने की सुविधा सही तरीके से काम कर रही है या फ़्रीज़ करने की सुविधा से जुड़ी समस्याओं को हल करने के लिए, इन डाइग्नोस्टिक टूल और कमांड का इस्तेमाल करें:

गतिविधि मैनेजर के लिए उपलब्ध निर्देश

किसी प्रोसेस के लिए, फ़्रीज़ करने और कंप्रेस करने की सुविधा को मैन्युअल तरीके से कंट्रोल करने के लिए, adb shell am कमांड का इस्तेमाल किया जा सकता है:

• किसी प्रोसेस को फ़्रीज़ करने के लिए:

  adb shell am freeze <process>

• किसी प्रोसेस को अनफ़्रीज़ करने के लिए:

  adb shell am unfreeze <process>

• किसी प्रोसेस पर मेमोरी को पूरी तरह से कंप्रेस करने के लिए, यह कमांड चलाएं:

  adb shell am compact full <process>

Logcat की जांच करना

फ़्रीज़र में किसी प्रोसेस के माइग्रेट होने या उससे बाहर निकलने पर, हर बार फ़्रीज़ और अनफ़्रीज़ की गई एंट्री देखने के लिए, logcat देखें:

adb logcat | grep -i "\(freezing\|froze\)"

'अनफ़्रीज़ करने की वजह' लॉग, UnfreezeReason प्रोटोकॉल बफ़र enum से गिनती की गई वैल्यू दिखाता है.

Dumpsys की जांच

dumpsys activity का इस्तेमाल करके, फ़्रीज़ की गई प्रोसेस की सूची देखें:

adb shell dumpsys activity | grep -A 20 "Apps frozen:"

देखें कि /sys/fs/cgroup/uid_0/cgroup.freeze फ़ाइल मौजूद है या नहीं.

ApplicationExitInfo

किसी प्रोसेस को पहले बंद किए जाने की वजह जानने के लिए, ActivityManager.getHistoricalProcessExitReasons देखें. अगर फ़्रीज़ करने से जुड़ी किसी समस्या की वजह से, ऐप्लिकेशन की प्रोसेस बंद कर दी गई थी, तो बाहर निकलने की वजह ApplicationExitInfo.REASON_FREEZER पर सेट हो जाती है. जैसे, फ़्रीज़ किए गए ऐप्लिकेशन को सिंक्रोनस बाइंडर ट्रांज़ैक्शन मिला.

Perfetto ट्रेसिंग

फ़्रीज़र से जुड़े इवेंट, Perfetto ट्रेस में system_server प्रोसेस के तहत Freezer नाम के ट्रैक पर भेजे जाते हैं:

• Freeze और Unfreeze स्लाइस से पता चलता है कि प्रोसेस की स्थिति कब बदलती है.
• updateAppFreezeStateLSP इवेंट तब दिखते हैं, जब सिस्टम सर्वर, प्रोसेस के एट्रिब्यूट की फिर से जांच करता है, ताकि फ़्रीज़ करने या अनफ़्रीज़ करने के फ़ैसले लिए जा सकें.

इन इवेंट की जांच सीधे Perfetto के यूज़र इंटरफ़ेस (यूआई) में की जा सकती है. इसके अलावा, PerfettoSQL का इस्तेमाल करके इनका विश्लेषण किया जा सकता है:

INCLUDE PERFETTO MODULE slices.with_context;
SELECT *
FROM process_slice
WHERE process_name = "system_server"
AND track_name = "Freezer"
AND (name LIKE "Freeze %" OR name LIKE "Unfreeze %");

PerfettoSQL की स्टैंडर्ड लाइब्रेरी में, फ़्रीज़र इवेंट की खास जानकारी भी android_freezer_events टेबल में दी जाती है.