गड़बड़ी की रिपोर्ट पढ़ना

किसी भी तरह के डेवलपमेंट में गड़बड़ियां होना आम बात है. साथ ही, गड़बड़ी की रिपोर्ट, समस्याओं की पहचान करने और उन्हें ठीक करने के लिए ज़रूरी हैं. Android के सभी वर्शन में, Android डीबग ब्रिज (adb) की मदद से गड़बड़ी की रिपोर्ट कैप्चर की जा सकती है. Android के 4.2 और इसके बाद के वर्शन में, डेवलपर के विकल्प की मदद से गड़बड़ी की रिपोर्ट ली जा सकती है और उन्हें ईमेल, Drive वगैरह के ज़रिए शेयर किया जा सकता है.

Android की गड़बड़ी की रिपोर्ट में, टेक्स्ट (.txt) फ़ॉर्मैट में dumpsys, dumpstate, और logcat डेटा होता है. इससे, किसी खास कॉन्टेंट को आसानी से खोजा जा सकता है. नीचे दिए गए सेक्शन में, गड़बड़ी की शिकायत के कॉम्पोनेंट के बारे में बताया गया है. साथ ही, आम समस्याओं के बारे में जानकारी दी गई है. इनमें, उन गड़बड़ियों से जुड़े लॉग ढूंढने के लिए, काम की सलाह और grep कमांड भी दिए गए हैं. ज़्यादातर सेक्शन में grep कमांड और आउटपुट और/या dumpsys आउटपुट के उदाहरण भी शामिल होते हैं.

Logcat

logcat लॉग, logcat की सभी जानकारी का स्ट्रिंग-आधारित डंप होता है. सिस्टम का हिस्सा, फ़्रेमवर्क के लिए रिज़र्व है. साथ ही, मुख्य सेक्शन के मुकाबले इसका इतिहास ज़्यादा पुराना है. इसमें बाकी सभी चीज़ें शामिल हैं. आम तौर पर, हर लाइन timestamp UID PID TID log-level से शुरू होती है. हालांकि, हो सकता है कि Android के पुराने वर्शन में UID शामिल न हो.

इवेंट लॉग देखना

इस लॉग में, बाइनरी फ़ॉर्मैट में लॉग मैसेज की स्ट्रिंग होती है. यह logcat लॉग की तुलना में कम जानकारी देता है. हालांकि, इसे पढ़ना थोड़ा मुश्किल होता है. इवेंट लॉग देखते समय, इस सेक्शन में किसी खास प्रोसेस आईडी (पीआईडी) को खोजा जा सकता है. इससे यह पता चलता है कि कोई प्रोसेस क्या कर रही है. इसका बुनियादी फ़ॉर्मैट यह है: timestamp PID TID log-level log-tag tag-values.

लॉग लेवल में ये शामिल हैं:

  • V: वर्बोस
  • D: डीबग
  • I: जानकारी
  • W: चेतावनी
  • E: गड़बड़ी

 

काम के अन्य इवेंट लॉग टैग के लिए, /services/core/java/com/android/server/EventLogTags.logtags देखें.

ANR और डेडलॉक

गड़बड़ी की रिपोर्ट से, आपको यह पता लगाने में मदद मिल सकती है कि ऐप्लिकेशन काम नहीं कर रहा है (ANR) गड़बड़ियों और डेडलॉक इवेंट की वजह क्या है.

काम न करने वाले ऐप्लिकेशन की पहचान करना

जब कोई ऐप्लिकेशन तय समय के अंदर जवाब नहीं देता है, तो आम तौर पर ब्लॉक की गई या व्यस्त मुख्य थ्रेड की वजह से, सिस्टम प्रोसेस को बंद कर देता है और स्टैक को /data/anr में डाल देता है. एएनआर की वजह जानने के लिए, बाइनरी इवेंट लॉग में am_anr के लिए grep करें.

logcat लॉग में ANR in के लिए grep भी किया जा सकता है. इसमें, ANR के समय सीपीयू का इस्तेमाल करने वाले ऐप्लिकेशन के बारे में ज़्यादा जानकारी होती है.

स्टैक ट्रेस ढूंढना

आपको अक्सर ऐसे स्टैक ट्रेस मिल सकते हैं जो एएनआर से जुड़े होते हैं. पक्का करें कि वीएम ट्रेस पर मौजूद टाइमस्टैंप और पीआईडी, उस ANR से मेल खाते हों जिसकी जांच की जा रही है. इसके बाद, प्रोसेस की मुख्य थ्रेड की जांच करें. ध्यान रखें:

  • मुख्य थ्रेड से सिर्फ़ यह पता चलता है कि एएनआर के समय थ्रेड क्या कर रहा था. यह एएनआर की असल वजह हो सकती है या नहीं. (गड़बड़ी की रिपोर्ट में मौजूद स्टैक में कोई गड़बड़ी नहीं हो सकती. हो सकता है कि कोई और चीज़ लंबे समय से फ़्रीज़ हो गई हो, लेकिन ANR होने के लिए ज़रूरत के मुताबिक लंबे समय तक फ़्रीज़ न हुई हो.)
  • स्टैक ट्रेस (VM TRACES JUST NOW और VM TRACES AT LAST ANR) के एक से ज़्यादा सेट मौजूद हो सकते हैं. पक्का करें कि आपको सही सेक्शन दिख रहा हो.

डेडलॉक ढूंढना

डेडलॉक अक्सर सबसे पहले ANR के तौर पर दिखते हैं, क्योंकि थ्रेड फ़्रीज़ हो जाते हैं. अगर डिडलॉक, सिस्टम सर्वर पर असर डालता है, तो वॉचडॉग उसे बंद कर देगा. इससे लॉग में इस तरह की एंट्री दिखेगी: WATCHDOG KILLING SYSTEM PROCESS. उपयोगकर्ता के हिसाब से, डिवाइस फिर से चालू हो जाता है. हालांकि, तकनीकी तौर पर यह असल रीबूट के बजाय, रनटाइम रीस्टार्ट होता है.

  • रनटाइम के दौरान रीस्टार्ट होने पर, सिस्टम सर्वर बंद हो जाता है और फिर से शुरू हो जाता है. साथ ही, उपयोगकर्ता को डिवाइस पर बूट ऐनिमेशन दिखता है.
  • रिबूट के दौरान, कर्नेल क्रैश हो गया है. उपयोगकर्ता को डिवाइस पर, Google बूट लोगो दिखता है.

डेडलॉक ढूंढने के लिए, VM ट्रेस सेक्शन में, थ्रेड A के पैटर्न की जांच करें, जो थ्रेड B के पास मौजूद किसी चीज़ का इंतज़ार कर रहा हो. साथ ही, थ्रेड B भी थ्रेड A के पास मौजूद किसी चीज़ का इंतज़ार कर रहा हो.

गतिविधियां

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

फ़ोकस की गई गतिविधियां देखना

फ़ोकस की गई गतिविधियों का इतिहास देखने के लिए, am_focused_activity खोजें.

व्यू की प्रोसेस शुरू हो जाती है

प्रोसेस शुरू होने का इतिहास देखने के लिए, Start proc खोजें.

यह पता लगाना कि डिवाइस पर ट्रैशिंग हो रही है या नहीं

यह पता लगाने के लिए कि डिवाइस पर थ्रेशिंग हो रही है या नहीं, am_proc_died और am_proc_start के आस-पास, कम समय में गतिविधि में असामान्य बढ़ोतरी देखें.

मेमोरी

Android डिवाइसों में अक्सर फ़िज़िकल मेमोरी कम होती है. इसलिए, रैंडम-ऐक्सेस मेमोरी (रैम) को मैनेज करना ज़रूरी है. गड़बड़ी की रिपोर्ट में, कम मेमोरी के कई इंडिकेटर होते हैं. साथ ही, इसमें मेमोरी का स्नैपशॉट देने वाला डंपस्टेट भी होता है.

कम मेमोरी की पहचान करना

कम मेमोरी की वजह से, सिस्टम में रुकावट आ सकती है. ऐसा इसलिए होता है, क्योंकि मेमोरी खाली करने के लिए कुछ प्रोसेस बंद कर दी जाती हैं, लेकिन अन्य प्रोसेस शुरू होती रहती हैं. कम मेमोरी की पुष्टि करने वाला सबूत देखने के लिए, बाइनरी इवेंट लॉग में am_proc_died और am_proc_start एंट्री की संख्या देखें.

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

पुराने इंडिकेटर देखना

बाइनरी इवेंट लॉग में am_low_memory एंट्री से पता चलता है कि कैश मेमोरी में सेव की गई आखिरी प्रोसेस बंद हो गई है. इसके बाद, सिस्टम सेवाओं को बंद करना शुरू कर देता है.

थ्रैशिंग इंडिकेटर देखना

सिस्टम थ्रैशिंग (पेजिंग, डायरेक्ट रीक्लेम वगैरह) के अन्य इंडिकेटर में, kswapd, kworker, और mmcqd का इस्तेमाल करने वाले साइकल शामिल हैं. (ध्यान रखें कि इकट्ठा की जा रही गड़बड़ी की रिपोर्ट से, ट्रैशिंग के सूचक पर असर पड़ सकता है.)

ANR लॉग से भी मेमोरी का मिलता-जुलता स्नैपशॉट मिल सकता है.

यादगार लम्हों का स्नैपशॉट पाना

मेमोरी स्नैपशॉट एक डंपस्टेट है, जिसमें चल रही Java और नेटिव प्रोसेस की सूची होती है. ज़्यादा जानकारी के लिए, पूरी मेमोरी के ऐलोकेशन देखना लेख पढ़ें. ध्यान रखें कि स्नैपशॉट किसी खास समय पर सिर्फ़ सिस्टम की स्थिति दिखाता है. हो सकता है कि स्नैपशॉट लेने से पहले सिस्टम की स्थिति बेहतर (या खराब) रही हो.

ब्रॉडकास्ट

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

पुराने ब्रॉडकास्ट देखना

पुराने ब्रॉडकास्ट वे होते हैं जिन्हें पहले ही भेजा जा चुका है. इन्हें कालानुक्रम के उलटे क्रम में दिखाया जाता है.

खास जानकारी सेक्शन में, पिछले 300 फ़ोरग्राउंड ब्रॉडकास्ट और पिछले 300 बैकग्राउंड ब्रॉडकास्ट की खास जानकारी मिलती है.

जानकारी सेक्शन में, पिछले 50 फ़ोरग्राउंड ब्रॉडकास्ट और पिछले 50 बैकग्राउंड ब्रॉडकास्ट की पूरी जानकारी होती है. साथ ही, हर ब्रॉडकास्ट के लिए रिसीवर की जानकारी भी होती है. ईमेल पाने वाले ऐसे लोग जिनके पास:

  • BroadcastFilter एंट्री, रनटाइम के दौरान रजिस्टर की जाती हैं और इन्हें सिर्फ़ पहले से चल रही प्रोसेस पर भेजा जाता है.
  • ResolveInfo एंट्री, मेनिफ़ेस्ट एंट्री के ज़रिए रजिस्टर की जाती हैं. अगर ResolveInfo पहले से नहीं चल रहा है, तो ActivityManager हर ResolveInfo के लिए प्रोसेस शुरू करता है.

चालू ब्रॉडकास्ट देखना

'मौजूदा ब्रॉडकास्ट' वे ब्रॉडकास्ट होते हैं जिन्हें अभी तक भेजा नहीं गया है. सूची में बड़ी संख्या का मतलब है कि सिस्टम, ब्रॉडकास्ट को तेज़ी से डिस्पैच नहीं कर सकता.

ब्रॉडकास्ट सुनने वाले लोगों की संख्या देखना

ब्रॉडकास्ट सुनने वाले रिसीवर की सूची देखने के लिए, dumpsys activity broadcasts में रिसीवर रिज़ॉल्वर टेबल देखें. नीचे दिए गए उदाहरण में, USER_PRESENT को सुनने वाले सभी रिसीवर दिखाए गए हैं.

लॉक के लिए होने वाले विवाद को मॉनिटर करना

मॉनिटर कॉन्टेंटेशन लॉगिंग से कभी-कभी, मॉनिटर कॉन्टेंटेशन के बारे में पता चल सकता है. हालांकि, ज़्यादातर मामलों में इससे पता चलता है कि सिस्टम इतना लोड है कि सब कुछ धीमा हो गया है. आपको सिस्टम या इवेंट लॉग में, ART के ज़रिए लॉग किए गए लंबे मॉनिटर इवेंट दिख सकते हैं.

सिस्टम लॉग में:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

इवेंट लॉग में:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

बैकग्राउंड में कॉन्टेंट कंपाइल करना

कंपाइलेशन की प्रोसेस महंगी हो सकती है और डिवाइस को लोड कर सकती है.

Google Play Store के अपडेट डाउनलोड होने के दौरान, बैकग्राउंड में कंपाइलेशन हो सकता है. इस मामले में, Google Play Store ऐप्लिकेशन (finsky) और installd से मिले मैसेज, dex2oat से मिले मैसेज से पहले दिखते हैं.

जब कोई ऐप्लिकेशन ऐसी DEX फ़ाइल लोड कर रहा हो जिसे अब तक कंपाइल नहीं किया गया है, तब भी बैकग्राउंड में कंपाइलेशन हो सकता है. इस मामले में, आपको finsky या installd लॉगिंग नहीं दिखेगी.

नैरेटिव

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

टाइमलाइन सिंक करना

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

सिस्टम और इवेंट लॉग के टाइमस्टैंप, उपयोगकर्ता के टाइमज़ोन में होते हैं. ज़्यादातर अन्य टाइमस्टैंप भी इसी टाइमज़ोन में होते हैं. उदाहरण के लिए, जब उपयोगकर्ता होम बटन पर टैप करता है, तो सिस्टम लॉग रिपोर्ट करता है:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

एक ही कार्रवाई के लिए, इवेंट लॉग ये रिपोर्ट करता है:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Kernel (dmesg) लॉग, समय के लिए अलग बेस का इस्तेमाल करते हैं. ये लॉग आइटम को, बूटलोडर के पूरा होने के बाद सेकंड के हिसाब से टैग करते हैं. इस टाइमस्केल को अन्य टाइमस्केल में रजिस्टर करने के लिए, सदस्यता छोड़ने पर रोक लगाएं और सदस्यता लेने पर रोक लगाएं मैसेज खोजें:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

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

गड़बड़ी की रिपोर्ट भेजने का समय

यह पता लगाने के लिए कि गड़बड़ी की रिपोर्ट कब ली गई थी, सबसे पहले dumpstate: begin के लिए सिस्टम लॉग (Logcat) देखें:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

इसके बाद, Starting service 'bugreport' मैसेज के लिए, कर्नेल लॉग (dmesg) के टाइमस्टैंप देखें:

<5>[207064.285315] init: Starting service 'bugreport'...

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

ताकत

इवेंट लॉग में स्क्रीन की पावर का स्टेटस होता है. इसमें 0 का मतलब स्क्रीन बंद है, 1 का मतलब स्क्रीन चालू है, और 2 का मतलब है कि कीगार्ड चालू है.

गड़बड़ी की रिपोर्ट में, वेक लॉक के आंकड़े भी शामिल होते हैं. ऐप्लिकेशन डेवलपर, वेक लॉक का इस्तेमाल यह बताने के लिए करते हैं कि उनके ऐप्लिकेशन को डिवाइस के चालू रहने की ज़रूरत है. (वेक लॉक के बारे में ज़्यादा जानने के लिए, PowerManager.WakeLock और सीपीयू को चालू रखें लेख पढ़ें.)

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

बैटरी की स्थिति को विज़ुअलाइज़ करने में ज़्यादा मदद पाने के लिए, Battery Historian का इस्तेमाल करें. यह Google का ओपन सोर्स टूल है. इसका इस्तेमाल करके, Android की गड़बड़ी की जानकारी देने वाली फ़ाइलों का इस्तेमाल करके, बैटरी खर्च करने वाले ऐप्लिकेशन का विश्लेषण किया जाता है.

पैकेज

DUMP OF SERVICE package सेक्शन में ऐप्लिकेशन के वर्शन (और अन्य काम की जानकारी) शामिल होती है.

प्रक्रियाएं

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

प्रोसेस का रनटाइम तय करना

procstats सेक्शन में, प्रोसेस और उनसे जुड़ी सेवाओं के चलने का पूरा आंकड़ा होता है. AGGREGATED OVER खोजें और पिछले तीन या 24 घंटों का डेटा देखें. इससे आपको तुरंत और आसानी से समझ आने वाली खास जानकारी मिलेगी. इसके बाद, Summary: खोजें और प्रोसेस की सूची देखें. इससे आपको यह जानकारी मिलेगी कि वे प्रोसेस अलग-अलग प्राथमिकता के हिसाब से कितनी देर तक चली हैं और उनके रैम इस्तेमाल की जानकारी, कम से कम-औसत-ज़्यादा से ज़्यादा पीएसएस/कम से कम-औसत-ज़्यादा यूएसएस के फ़ॉर्मैट में दिखेगी.

प्रोसेस चलने की वजहें

dumpsys activity processes सेक्शन में, फ़िलहाल चल रही सभी प्रोसेस की सूची होती है. इन प्रोसेस को oom_adj स्कोर के हिसाब से क्रम में लगाया जाता है. Android, प्रोसेस को oom_adj वैल्यू असाइन करके, प्रोसेस की अहमियत के बारे में बताता है. इस वैल्यू को ActivityManager डाइनैमिक तौर पर अपडेट कर सकता है. यह आउटपुट, मेमोरी स्नैपशॉट से मिलता-जुलता है. हालांकि, इसमें प्रोसेस के चलने की वजह के बारे में अतिरिक्त जानकारी शामिल होती है. नीचे दिए गए उदाहरण में, बोल्ड की गई एंट्री से पता चलता है कि gms.persistent प्रोसेस, vis (दिखने वाली) प्राथमिकता पर चल रही है, क्योंकि सिस्टम प्रोसेस अपनी NetworkLocationService से बंधी होती है.

स्कैन

ज़्यादा ब्लूटूथ कम ऊर्जा (BLE) स्कैन करने वाले ऐप्लिकेशन की पहचान करने के लिए, यह तरीका अपनाएं:

  • BluetoothLeScanner के लिए लॉग मैसेज ढूंढने के लिए:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • लॉग मैसेज में पीआईडी ढूंढें. इस उदाहरण में, "24840" और "24851", पीआईडी (प्रोसेस आईडी) और टीआईडी (थ्रेड आईडी) हैं.
  • पीआईडी से जुड़ा ऐप्लिकेशन ढूंढें:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    इस उदाहरण में, पैकेज का नाम com.badapp है.

  • समस्या पैदा करने वाले ऐप्लिकेशन की पहचान करने के लिए, Google Play पर पैकेज का नाम देखें: https://play.google.com/store/apps/details?id=com.badapp.

ध्यान दें: Android 7.0 पर काम करने वाले डिवाइसों के लिए, सिस्टम बीएलई स्कैन का डेटा इकट्ठा करता है और इन गतिविधियों को, शुरू करने वाले ऐप्लिकेशन से जोड़ता है. ज़्यादा जानकारी के लिए, कम ऊर्जा (LE) और ब्लूटूथ स्कैन देखें.