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

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

एएनआर और डेडलॉक

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

ऐसे ऐप्लिकेशन की पहचान करना जो काम नहीं कर रहे हैं

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

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

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

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

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

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

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

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

डेडलॉक ढूंढने के लिए, वीएम ट्रेस सेक्शन में थ्रेड 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 के साइकल इस्तेमाल करना शामिल है. (ध्यान रखें कि इकट्ठा की जा रही बग रिपोर्ट से थ्रैशिंग इंडिकेटर पर असर पड़ सकता है.)

एएनआर लॉग से, मेमोरी का ऐसा ही स्नैपशॉट मिल सकता है.

यादगार पल का स्नैपशॉट पाना

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

ब्रॉडकास्ट

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

पिछले ब्रॉडकास्ट देखना

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

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

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

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

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

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

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

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

लॉक का विवाद मॉनिटर करना

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

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

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]

कर्नेल (dmesg) लॉग, समय के अलग-अलग आधार का इस्तेमाल करते हैं. ये बूटलोडर के पूरा होने के बाद से, लॉग आइटम को सेकंड के हिसाब से टैग करते हैं. इस समयावधि को अन्य समयावधियों के साथ रजिस्टर करने के लिए, suspend exit और suspend entry मैसेज खोजें:

<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 और Keep the CPU on लेख पढ़ें.)

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

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

पैकेज

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 से जुड़ी हुई है.

स्कैन

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

  • BluetoothLeScanner के लिए लॉग मैसेज ढूंढें:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • लॉग मैसेज में PID ढूंढें. इस उदाहरण में, "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 पर काम करने वाले डिवाइसों के लिए, सिस्टम बीएलई स्कैन का डेटा इकट्ठा करता है. साथ ही, इन गतिविधियों को शुरू करने वाले ऐप्लिकेशन से जोड़ता है. ज़्यादा जानकारी के लिए, ब्लूटूथ स्मार्ट (एलई) और ब्लूटूथ स्कैन लेख पढ़ें.