यह पृष्ठ Crashlytics का उपयोग करने के बारे में अक्सर पूछे जाने वाले प्रश्नों के लिए समस्या निवारण सहायता और उत्तर प्रदान करता है। यदि आपको वह नहीं मिल रहा है जिसकी आप तलाश कर रहे हैं या अतिरिक्त सहायता की आवश्यकता है, तो Firebase सहायता से संपर्क करें।
सामान्य समस्या निवारण / अक्सर पूछे जाने वाले प्रश्न
यदि आप क्रैश-मुक्त उपयोगकर्ता, ब्रेडक्रंब लॉग और/या वेग अलर्ट नहीं देख रहे हैं, तो हम अनुशंसा करते हैं कि आप Google Analytics के लिए अपने ऐप के कॉन्फ़िगरेशन की जाँच करें।
सुनिश्चित करें कि आपने अपने Firebase प्रोजेक्ट में Google Analytics को सक्षम कर दिया है ।
सुनिश्चित करें कि Firebase कंसोल के एकीकरण > Google Analytics पृष्ठ में Google Analytics के लिए डेटा साझाकरण सक्षम है। ध्यान दें कि डेटा साझाकरण सेटिंग Firebase कंसोल में प्रदर्शित की जाती हैं लेकिन Google Analytics कंसोल में प्रबंधित की जाती हैं।
Firebase Crashlytics SDK के अलावा, सुनिश्चित करें कि आपने अपने ऐप ( iOS+ | Android ) में Google Analytics के लिए Firebase SDK जोड़ा है।
सुनिश्चित करें कि आप अपने सभी Firebase SDK ( iOS+ | Android ) के लिए नवीनतम संस्करण का उपयोग कर रहे हैं।
विशेष रूप से जांचें कि आप Google Analytics के लिए Firebase SDK के कम से कम निम्न संस्करणों का उपयोग कर रहे हैं: iOS+ — v6.3.1+ (macOS और tvOS के लिए v8.9.0+) | Android — v17.2.3+(बीओएम v24.7.1+) ।
आप Firebase कंसोल में अपनी समस्या तालिका में सूचीबद्ध समस्याओं के लिए दो अलग-अलग प्रारूप देख सकते हैं। और आपको अपनी कुछ समस्याओं में "वैरिएंट" नामक सुविधा भी दिखाई दे सकती है. उसकी वजह यहाँ है!
2023 की शुरुआत में, हमने ग्रुपिंग इवेंट के लिए एक बेहतर विश्लेषण इंजन के साथ-साथ एक अपडेटेड डिज़ाइन और नए मुद्दों (जैसे वेरिएंट!) के लिए कुछ उन्नत सुविधाएँ शुरू कीं। सभी विवरणों के लिए हमारे हालिया ब्लॉग पोस्ट को देखें, लेकिन हाइलाइट्स के लिए आप नीचे पढ़ सकते हैं।
Crashlytics आपके ऐप से सभी ईवेंट (जैसे क्रैश, गैर-घातक और ANRs) का विश्लेषण करता है और मुद्दों नामक ईवेंट के समूह बनाता है - किसी समस्या के सभी ईवेंट में विफलता का एक सामान्य बिंदु होता है।
इन मुद्दों में घटनाओं को समूहित करने के लिए, बेहतर विश्लेषण इंजन अब घटना के कई पहलुओं को देखता है, जिसमें स्टैक ट्रेस में फ़्रेम, अपवाद संदेश, त्रुटि कोड और अन्य प्लेटफ़ॉर्म या त्रुटि प्रकार की विशेषताएँ शामिल हैं।
हालाँकि, घटनाओं के इस समूह के भीतर, विफलता की ओर ले जाने वाले स्टैक ट्रेस भिन्न हो सकते हैं। एक अलग स्टैक ट्रेस का मतलब एक अलग मूल कारण हो सकता है। किसी मुद्दे के भीतर इस संभावित अंतर का प्रतिनिधित्व करने के लिए, अब हम मुद्दों के भीतर वेरिएंट बनाते हैं - प्रत्येक संस्करण एक समस्या में घटनाओं का एक उप-समूह होता है जिसमें समान विफलता बिंदु और समान स्टैक ट्रेस होता है। वेरिएंट के साथ, आप किसी समस्या के भीतर सबसे सामान्य स्टैक ट्रेस को डिबग कर सकते हैं और यह निर्धारित कर सकते हैं कि क्या विभिन्न मूल कारण विफलता का कारण बन रहे हैं।
यहां बताया गया है कि आप इन सुधारों के साथ क्या अनुभव करेंगे:
नया रूप दिया गया मेटाडेटा समस्या पंक्ति में प्रदर्शित होता है
अब आपके ऐप में समस्याओं को समझना और उनका चयन करना आसान हो गया है।कम डुप्लिकेट मुद्दे
एक पंक्ति संख्या परिवर्तन के परिणामस्वरूप कोई नई समस्या नहीं होती है।विभिन्न मूल कारणों के साथ जटिल मुद्दों की आसान डिबगिंग
किसी समस्या के सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए वेरिएंट का इस्तेमाल करें.अधिक सार्थक अलर्ट और सिग्नल
एक नया मुद्दा वास्तव में एक नए बग का प्रतिनिधित्व करता है।अधिक शक्तिशाली खोज
प्रत्येक अंक में अधिक खोजने योग्य मेटाडेटा होता है, जैसे अपवाद प्रकार और पैकेज का नाम।
यहां बताया गया है कि ये सुधार कैसे शुरू हो रहे हैं:
जब हमें आपके ऐप से नए ईवेंट मिलते हैं, तो हम जाँच करेंगे कि क्या वे किसी मौजूदा समस्या से मेल खाते हैं।
यदि कोई मिलान नहीं होता है, तो हम स्वचालित रूप से अपने स्मार्ट इवेंट-ग्रुपिंग एल्गोरिद्म को ईवेंट पर लागू कर देंगे और संशोधित मेटाडेटा डिज़ाइन के साथ एक नया मुद्दा बना देंगे।
यह पहला बड़ा अपडेट है जो हम अपने इवेंट ग्रुपिंग में कर रहे हैं। यदि आपके पास प्रतिक्रिया है या कोई समस्या आती है, तो कृपया रिपोर्ट दर्ज करके हमें बताएं।
क्रैश-मुक्त मान उन उपयोगकर्ताओं के प्रतिशत का प्रतिनिधित्व करता है, जो आपके ऐप से जुड़े थे, लेकिन किसी विशिष्ट समय अवधि में क्रैश नहीं हुए थे।
क्रैश-मुक्त उपयोगकर्ताओं के प्रतिशत की गणना करने का सूत्र यहां दिया गया है। इसके इनपुट मान Google Analytics द्वारा प्रदान किए जाते हैं।
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
जब कोई क्रैश होता है, तो Google Analytics एक
app_exceptionइवेंट प्रकार भेजता है और CRASHED_USERS उस ईवेंट प्रकार से जुड़े उपयोगकर्ताओं की संख्या का प्रतिनिधित्व करता है।ALL_USERS उन उपयोगकर्ताओं की कुल संख्या का प्रतिनिधित्व करता है, जो आपके द्वारा Crashlytics डैशबोर्ड के ऊपरी-दाएँ भाग में ड्रॉपडाउन मेनू से चुनी गई समयावधि के दौरान आपके ऐप से जुड़े रहे।
क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत समय के साथ एकत्रीकरण है, औसत नहीं।
उदाहरण के लिए, कल्पना करें कि आपके ऐप के तीन उपयोगकर्ता हैं; हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B और उपयोगकर्ता C कहेंगे। निम्न तालिका दर्शाती है कि कौन से उपयोगकर्ता प्रतिदिन आपके ऐप से जुड़े और उनमें से किस उपयोगकर्ता का उस दिन क्रैश हुआ था:
| सोमवार | मंगलवार | बुधवार | |
|---|---|---|---|
| वे उपयोगकर्ता जो आपके ऐप से जुड़े हैं | ए, बी, सी | ए, बी, सी | ए, बी |
| उपयोगकर्ता जो दुर्घटनाग्रस्त हो गया था | सी | बी | ए |
बुधवार को, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 50% है (2 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
आपके दो उपयोगकर्ता बुधवार को आपके ऐप से जुड़े थे, लेकिन उनमें से केवल एक (उपयोगकर्ता B) का कोई क्रैश नहीं हुआ था।पिछले 2 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 33.3% है (3 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
आपके तीन उपयोगकर्ता पिछले दो दिनों में आपके ऐप से जुड़े, लेकिन उनमें से केवल एक (उपयोगकर्ता C) का कोई क्रैश नहीं हुआ।पिछले 3 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 0% है (3 में से 0 उपयोगकर्ता क्रैश-मुक्त थे)।
आपके तीन उपयोगकर्ता पिछले तीन दिनों में आपके ऐप से जुड़े, लेकिन उनमें से शून्य का कोई क्रैश नहीं हुआ।
नोट्स परियोजना के सदस्यों को प्रश्नों, स्थिति अपडेट आदि के साथ विशिष्ट मुद्दों पर टिप्पणी करने की अनुमति देते हैं।
जब कोई प्रोजेक्ट सदस्य कोई नोट पोस्ट करता है, तो उसे उनके Google खाते के ईमेल के साथ लेबल किया जाता है। यह ईमेल पता, नोट के साथ, उन सभी प्रोजेक्ट सदस्यों के लिए दृश्यमान है, जिनके पास नोट देखने की पहुंच है।
निम्नलिखित नोट्स देखने, लिखने और हटाने के लिए आवश्यक एक्सेस का वर्णन करता है:
निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य मौजूदा नोट्स को देख और हटा सकते हैं और किसी मुद्दे पर नए नोट्स लिख सकते हैं।
- प्रोजेक्ट स्वामी या संपादक , Firebase व्यवस्थापक , गुणवत्ता व्यवस्थापक , या Crashlytics व्यवस्थापक
निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य किसी मुद्दे पर पोस्ट किए गए नोट्स देख सकते हैं, लेकिन वे नोट को हटा या लिख नहीं सकते हैं।
- प्रोजेक्ट व्यूअर , फायरबेस व्यूअर , क्वालिटी व्यूअर या क्रैशलाइटिक्स व्यूअर
एकीकरण
यदि आपका प्रोजेक्ट Google मोबाइल विज्ञापन SDK के साथ Crashlytics का उपयोग करता है, तो संभव है कि क्रैश रिपोर्टर अपवाद संचालकों को पंजीकृत करते समय हस्तक्षेप कर रहे हों। समस्या को ठीक करने के लिए, disableSDKCrashReporting कॉल करके मोबाइल विज्ञापन SDK में क्रैश रिपोर्टिंग बंद करें।
आपके द्वारा Crashlytics को BigQuery से लिंक करने के बाद, आपके द्वारा बनाए गए नए डेटासेट आपके Firebase प्रोजेक्ट के स्थान की परवाह किए बिना स्वचालित रूप से संयुक्त राज्य अमेरिका में स्थित हैं।
मंच का समर्थन
प्रतिगमन मुद्दे
जब आपने समस्या को पहले ही बंद कर दिया था, तो समस्या वापस आ गई थी, लेकिन Crashlytics को एक नई रिपोर्ट मिलती है कि समस्या फिर से हुई है। Crashlytics स्वचालित रूप से इन प्रतिगामी समस्याओं को फिर से खोल देता है ताकि आप उन्हें अपने ऐप के लिए उपयुक्त रूप से संबोधित कर सकें।
यहां एक उदाहरण परिदृश्य दिया गया है जो बताता है कि Crashlytics किसी समस्या को प्रतिगमन के रूप में कैसे वर्गीकृत करता है:
- पहली बार, Crashlytics को Crash "A" के बारे में क्रैश रिपोर्ट मिलती है। Crashlytics उस क्रैश (अंक "A") के लिए संबंधित समस्या खोलता है।
- आप इस बग को जल्दी से ठीक करें, अंक "ए" को बंद करें और फिर अपने ऐप का एक नया संस्करण जारी करें।
- आपके द्वारा समस्या बंद करने के बाद Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है।
- यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी), तो Crashlytics इस मुद्दे को वापस नहीं लेगा। मामला बंद रहेगा।
- यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता नहीं था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने कभी भी किसी क्रैश के लिए कोई क्रैश रिपोर्ट नहीं भेजी थी), तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी .
जब कोई समस्या वापस आती है, तो हम एक रिग्रेशन डिटेक्शन अलर्ट भेजते हैं और समस्या में एक रिग्रेशन सिग्नल जोड़ते हैं ताकि आपको पता चल सके कि Crashlytics ने समस्या को फिर से खोल दिया है। यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।
यदि कोई रिपोर्ट किसी पुराने ऐप संस्करण से है जिसने समस्या को बंद करने के दौरान कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी।
यह स्थिति निम्न स्थिति में हो सकती है: आपने एक बग ठीक कर लिया है और अपने ऐप का एक नया संस्करण जारी कर दिया है, लेकिन आपके पास अभी भी बग फिक्स के बिना पुराने संस्करणों पर उपयोगकर्ता हैं। यदि, संयोग से, उन पुराने संस्करणों में से एक ने कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी जब आपने समस्या को बंद कर दिया था, और उन उपयोगकर्ताओं को बग का सामना करना शुरू हो गया, तो वे क्रैश रिपोर्ट एक प्रतिगमन समस्या को ट्रिगर करेंगे।
यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।