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

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

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

लोगकैट

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

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

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

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

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

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

ANR और गतिरोध

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

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

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

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

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

आप अक्सर स्टैक ट्रैस ढूंढ सकते हैं जो किसी ANR के संगत होते हैं। सुनिश्चित करें कि VM ट्रेस पर टाइमस्टैम्प और PID उस ANR से मेल खाते हैं जिसकी आप जाँच कर रहे हैं, फिर प्रक्रिया के मुख्य थ्रेड की जाँच करें। ध्यान रखें:

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

गतिरोध ढूँढना

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

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

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

गतिविधियां

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

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

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

देखने की प्रक्रिया शुरू

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

क्या डिवाइस थ्रैशिंग कर रहा है?

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

स्मृति

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

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

कम मेमोरी सिस्टम को थ्रैश करने का कारण बन सकती है क्योंकि यह कुछ प्रक्रियाओं को फ्री मेमोरी में मार देती है लेकिन अन्य प्रक्रियाओं को शुरू करना जारी रखती है। कम स्मृति के प्रमाण को देखने के लिए, बाइनरी इवेंट लॉग में 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 को सुनने वाले सभी रिसीवरों को प्रदर्शित करता है।

मॉनिटर विवाद

मॉनिटर विवाद लॉगिंग कभी-कभी वास्तविक मॉनिटर विवाद को इंगित कर सकता है, लेकिन अक्सर यह इंगित करता है कि सिस्टम इतना भरा हुआ है कि सब कुछ धीमा हो गया है। आप सिस्टम या इवेंट लॉग में 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 स्टोर अपडेट डाउनलोड हो रहे हों, तब पृष्ठभूमि में संकलन हो सकता है। इस मामले में, Google Play store ऐप ( 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

क्योंकि कर्नेल लॉग में सस्पेंड के दौरान समय शामिल नहीं हो सकता है, इसलिए आपको लॉग को सस्पेंड एंट्री और एग्जिट मैसेज के बीच रजिस्टर करना चाहिए। इसके अतिरिक्त, कर्नेल लॉग 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 स्कोर आदि शामिल हैं। Android प्रक्रियाओं को कैसे प्रबंधित करता है, इस पर विवरण के लिए, प्रक्रियाओं और थ्रेड्स देखें।

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

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

एक प्रक्रिया क्यों चल रही है?

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

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

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

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