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