बग रिपोर्ट पढ़ें

किसी भी प्रकार के विकास में बग एक वास्तविकता है- और समस्याओं की पहचान करने और उन्हें हल करने के लिए बग रिपोर्ट महत्वपूर्ण हैं। एंड्रॉइड के सभी संस्करण एंड्रॉइड डिबग ब्रिज (एडीबी) के साथ बग रिपोर्ट कैप्चर करने का समर्थन करते हैं; एंड्रॉइड संस्करण 4.2 और उच्चतर बग रिपोर्ट लेने और ईमेल, ड्राइव आदि के माध्यम से साझा करने के लिए डेवलपर विकल्प का समर्थन करते हैं।

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

लॉगकैट

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

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

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

लॉग स्तरों में निम्नलिखित शामिल हैं:

  • वी: वर्बोज़
  • डी: डिबग
  • मैं: जानकारी
  • डब्ल्यू: चेतावनी
  • ई: त्रुटि

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

ANR और गतिरोध

बग्रेपोर्ट आपको यह पहचानने में मदद कर सकता है कि एप्लिकेशन नॉट रिस्पॉन्डिंग (एएनआर) त्रुटियों और गतिरोध घटनाओं का कारण क्या है।

अनुत्तरदायी ऐप्स की पहचान करें

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

आप ANR in के लिए logcat लॉग में भी ग्रेप कर सकते हैं, जिसमें एएनआर के समय सीपीयू का उपयोग करने के बारे में अधिक जानकारी शामिल है।

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

आप अक्सर ऐसे स्टैक ट्रेस पा सकते हैं जो ANR से मेल खाते हैं। सुनिश्चित करें कि वीएम ट्रेस पर टाइमस्टैम्प और पीआईडी ​​उस एएनआर से मेल खाते हैं जिसकी आप जांच कर रहे हैं, फिर प्रक्रिया के मुख्य थ्रेड की जांच करें। ध्यान रखें:

  • मुख्य थ्रेड आपको केवल यह बताता है कि थ्रेड ANR के समय क्या कर रहा था, जो ANR के वास्तविक कारण के अनुरूप हो भी सकता है और नहीं भी। (बग रिपोर्ट में स्टैक निर्दोष हो सकता है; कुछ और लंबे समय से अटका हुआ हो सकता है - लेकिन ANR के लिए पर्याप्त लंबा नहीं है - अनस्टक होने से पहले।)
  • स्टैक ट्रेस के एक से अधिक सेट ( VM TRACES JUST NOW और VM TRACES AT LAST ANR ) मौजूद हो सकते हैं। सुनिश्चित करें कि आप सही अनुभाग देख रहे हैं।

गतिरोध खोजें

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

  • रनटाइम रीस्टार्ट में, सिस्टम सर्वर बंद हो जाता है और पुनः आरंभ हो जाता है; उपयोगकर्ता डिवाइस को बूट एनीमेशन पर वापस देखता है।
  • रिबूट में, कर्नेल क्रैश हो गया है; उपयोगकर्ता डिवाइस को Google बूट लोगो पर वापस देखता है।

गतिरोधों का पता लगाने के लिए, थ्रेड ए के पैटर्न के लिए वीएम ट्रेस अनुभागों की जांच करें, जो थ्रेड बी द्वारा रखी गई किसी चीज़ पर प्रतीक्षा कर रहा है, जो बदले में थ्रेड ए द्वारा रखी गई किसी चीज़ पर प्रतीक्षा कर रहा है।

गतिविधियाँ

गतिविधि एक एप्लिकेशन घटक है जो उपयोगकर्ताओं को कुछ करने के लिए स्क्रीन प्रदान करता है जैसे कि नंबर डायल करना, फोटो लेना, ईमेल भेजना आदि। बग रिपोर्ट परिप्रेक्ष्य से, एक गतिविधि एक एकल, केंद्रित चीज़ है जिसे उपयोगकर्ता कर सकता है , जो किसी दुर्घटना के दौरान फोकस में रही गतिविधि का पता लगाना बहुत महत्वपूर्ण बनाता है। गतिविधियाँ (एक्टिविटीमैनेजर के माध्यम से) प्रक्रियाएँ चलाती हैं, इसलिए किसी दी गई गतिविधि के लिए सभी प्रक्रियाओं के रुकने और शुरू होने का पता लगाने से भी समस्या निवारण में मदद मिल सकती है।

केंद्रित गतिविधियाँ देखें

केंद्रित गतिविधियों का इतिहास देखने के लिए, am_focused_activity खोजें।

देखने की प्रक्रिया शुरू होती है

प्रक्रिया प्रारंभ का इतिहास देखने के लिए, Start proc खोजें।

निर्धारित करें कि क्या डिवाइस थ्रैशिंग कर रहा है

यह निर्धारित करने के लिए कि क्या डिवाइस थ्रैशिंग कर रहा है, थोड़े समय में am_proc_died और am_proc_start के आसपास गतिविधि में असामान्य वृद्धि की जांच करें।

याद

चूँकि एंड्रॉइड डिवाइस में अक्सर भौतिक मेमोरी सीमित होती है, इसलिए रैंडम-एक्सेस मेमोरी (RAM) का प्रबंधन करना महत्वपूर्ण है। बग रिपोर्ट में कम मेमोरी के कई संकेतक और साथ ही एक डंपस्टेट होता है जो मेमोरी स्नैपशॉट प्रदान करता है।

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

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

कम मेमोरी भी कार्य स्विचिंग को धीमा कर सकती है और वापसी प्रयासों को विफल कर सकती है (क्योंकि उपयोगकर्ता जिस कार्य पर लौटने का प्रयास कर रहा था वह समाप्त हो गया था)। यदि लॉन्चर बंद हो गया था, तो उपयोगकर्ता द्वारा होम बटन को छूने पर यह पुनरारंभ हो जाता है और लॉग दिखाता है कि लॉन्चर अपनी सामग्री को फिर से लोड करता है।

ऐतिहासिक संकेतक देखें

बाइनरी इवेंट लॉग में am_low_memory प्रविष्टि इंगित करती है कि अंतिम कैश्ड प्रक्रिया समाप्त हो गई है। इसके बाद, सिस्टम सेवाओं को ख़त्म करना शुरू कर देता है।

थ्रैशिंग संकेतक देखें

सिस्टम थ्रैशिंग के अन्य संकेतक (पेजिंग, डायरेक्ट रिक्लेम, आदि) में kswapd , kworker , और mmcqd उपभोग चक्र शामिल हैं। (ध्यान रखें कि एकत्रित की जा रही बगरिपोर्ट थ्रैशिंग संकेतकों को प्रभावित कर सकती है।)

ANR लॉग एक समान मेमोरी स्नैपशॉट प्रदान कर सकते हैं।

एक स्मृति स्नैपशॉट प्राप्त करें

मेमोरी स्नैपशॉट एक डंपस्टेट है जो चल रहे जावा और मूल प्रक्रियाओं को सूचीबद्ध करता है (विवरण के लिए, समग्र मेमोरी आवंटन देखना देखें )। ध्यान रखें कि स्नैपशॉट समय में केवल एक विशिष्ट क्षण की स्थिति बताता है; स्नैपशॉट से पहले सिस्टम बेहतर (या बदतर) स्थिति में रहा होगा।

प्रसारण

एप्लिकेशन वर्तमान एप्लिकेशन के भीतर या किसी अन्य एप्लिकेशन पर ईवेंट भेजने के लिए प्रसारण उत्पन्न करते हैं। प्रसारण रिसीवर विशिष्ट संदेशों (फ़िल्टर के माध्यम से) की सदस्यता लेते हैं, जिससे वे प्रसारण को सुनने और प्रतिक्रिया देने दोनों में सक्षम होते हैं। बग रिपोर्ट में भेजे गए प्रसारण और न भेजे गए प्रसारण के बारे में जानकारी होती है, साथ ही किसी विशिष्ट प्रसारण को सुनने वाले सभी प्राप्तकर्ताओं की डंपसिस भी होती है।

ऐतिहासिक प्रसारण देखें

ऐतिहासिक प्रसारण वे हैं जो पहले ही भेजे जा चुके हैं, उल्टे कालानुक्रमिक क्रम में सूचीबद्ध हैं।

सारांश अनुभाग पिछले 300 अग्रभूमि प्रसारणों और पिछले 300 पृष्ठभूमि प्रसारणों का अवलोकन है।

विवरण अनुभाग में पिछले 50 अग्रभूमि प्रसारणों और पिछले 50 पृष्ठभूमि प्रसारणों के साथ-साथ प्रत्येक प्रसारण के रिसीवर की पूरी जानकारी शामिल है। रिसीवर जिनके पास है:

  • BroadcastFilter प्रविष्टि रनटाइम पर पंजीकृत की जाती है और केवल पहले से चल रही प्रक्रियाओं को भेजी जाती है।
  • ResolveInfo प्रविष्टियाँ मैनिफ़ेस्ट प्रविष्टियों के माध्यम से पंजीकृत की जाती हैं। एक्टिविटीमैनेजर प्रत्येक 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 स्टोर अपडेट डाउनलोड हो रहे हों तो पृष्ठभूमि में संकलन हो सकता है। इस मामले में, Google Play स्टोर ऐप ( finsky ) और installd संदेश dex2oat संदेशों से पहले दिखाई देते हैं।

संकलन तब पृष्ठभूमि में भी हो सकता है जब कोई एप्लिकेशन एक डेक्स फ़ाइल लोड कर रहा हो जो अभी तक संकलित नहीं हुई है। इस स्थिति में, आपको 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 ) लॉग एक अलग समय आधार का उपयोग करते हैं, बूटलोडर पूरा होने के बाद सेकंड के साथ लॉग आइटम टैग करते हैं। इस टाइमस्केल को अन्य टाइमस्केल में पंजीकृत करने के लिए, सस्पेंड एग्जिट और सस्पेंड एंट्री संदेशों को खोजें:

<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 :

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 और CPU को चालू रखें देखें।)

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

पावर स्थिति को देखने में अधिक सहायता के लिए, बैटरी हिस्टोरियन का उपयोग करें, जो एंड्रॉइड बग्रेपोर्ट फ़ाइलों का उपयोग करके बैटरी उपभोक्ताओं का विश्लेषण करने के लिए एक Google ओपन सोर्स टूल है।

संकुल

DUMP OF SERVICE package अनुभाग में एप्लिकेशन संस्करण (और अन्य उपयोगी जानकारी) शामिल हैं।

प्रक्रियाओं

बग रिपोर्ट में प्रक्रियाओं के लिए भारी मात्रा में डेटा होता है, जिसमें प्रारंभ और समाप्ति समय, रनटाइम लंबाई, संबंधित सेवाएं, oom_adj स्कोर आदि शामिल हैं। एंड्रॉइड प्रक्रियाओं को कैसे प्रबंधित करता है, इसके विवरण के लिए, प्रोसेस और थ्रेड्स देखें।

प्रक्रिया रनटाइम निर्धारित करें

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

कारण एक प्रक्रिया चल रही है

dumpsys activity processes अनुभाग oom_adj स्कोर द्वारा आदेशित वर्तमान में चल रही सभी प्रक्रियाओं को सूचीबद्ध करता है (एंड्रॉइड प्रक्रिया को oom_adj मान निर्दिष्ट करके प्रक्रिया महत्व को इंगित करता है, जिसे एक्टिविटी मैनेजर द्वारा गतिशील रूप से अपडेट किया जा सकता है)। आउटपुट मेमोरी स्नैपशॉट के समान है लेकिन इसमें प्रक्रिया चलने के कारण के बारे में अतिरिक्त जानकारी शामिल है। नीचे दिए गए उदाहरण में, बोल्ड की गई प्रविष्टियाँ इंगित करती हैं कि 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।

नोट : एंड्रॉइड 7.0 चलाने वाले उपकरणों के लिए, सिस्टम BLE स्कैन के लिए डेटा एकत्र करता है और इन गतिविधियों को आरंभ करने वाले एप्लिकेशन के साथ जोड़ता है। विवरण के लिए, लो एनर्जी (एलई) और ब्लूटूथ स्कैन देखें।