यह पृष्ठ क्रैशलिटिक्स का उपयोग करने के बारे में समस्या निवारण सहायता और अक्सर पूछे जाने वाले प्रश्नों के उत्तर प्रदान करता है। यदि आप जो खोज रहे हैं वह आपको नहीं मिल रहा है या आपको अतिरिक्त सहायता की आवश्यकता है, तो फायरबेस सहायता से संपर्क करें।
सामान्य समस्या निवारण/अक्सर पूछे जाने वाले प्रश्न
यदि आपको क्रैश-मुक्त उपयोगकर्ता, ब्रेडक्रंब लॉग और/या वेग अलर्ट नहीं दिख रहे हैं, तो हम 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 की शुरुआत में, हमने घटनाओं को समूहीकृत करने के लिए एक बेहतर विश्लेषण इंजन के साथ-साथ एक अद्यतन डिज़ाइन और नए मुद्दों (जैसे वेरिएंट!) के लिए कुछ उन्नत सुविधाएँ शुरू कीं। सभी विवरणों के लिए हमारा हालिया ब्लॉग पोस्ट देखें, लेकिन हाइलाइट्स के लिए आप नीचे पढ़ सकते हैं।
क्रैशलाईटिक्स आपके ऐप से सभी घटनाओं का विश्लेषण करता है (जैसे क्रैश, गैर-घातक और एएनआर) और घटनाओं के समूह बनाता है जिन्हें मुद्दे कहा जाता है - किसी मुद्दे की सभी घटनाओं में विफलता का एक सामान्य बिंदु होता है।
इन मुद्दों में घटनाओं को समूहीकृत करने के लिए, बेहतर विश्लेषण इंजन अब घटना के कई पहलुओं को देखता है, जिसमें स्टैक ट्रेस में फ़्रेम, अपवाद संदेश, त्रुटि कोड और अन्य प्लेटफ़ॉर्म या त्रुटि प्रकार की विशेषताएं शामिल हैं।
हालाँकि, घटनाओं के इस समूह के भीतर, विफलता की ओर ले जाने वाले स्टैक ट्रेस भिन्न हो सकते हैं। एक अलग स्टैक ट्रेस का मतलब एक अलग मूल कारण हो सकता है। किसी मुद्दे के भीतर इस संभावित अंतर को दर्शाने के लिए, अब हम मुद्दों के भीतर वेरिएंट बनाते हैं - प्रत्येक वेरिएंट किसी मुद्दे में घटनाओं का एक उप-समूह है जिसमें समान विफलता बिंदु और समान स्टैक ट्रेस होता है। वेरिएंट के साथ, आप किसी समस्या के सबसे सामान्य स्टैक ट्रेस को डीबग कर सकते हैं और यह निर्धारित कर सकते हैं कि क्या विभिन्न मूल कारण विफलता का कारण बन रहे हैं।
यहां बताया गया है कि आप इन सुधारों के साथ क्या अनुभव करेंगे:
समस्या पंक्ति के भीतर प्रदर्शित संशोधित मेटाडेटा
अब आपके ऐप में मुद्दों को समझना और उनका परीक्षण करना आसान हो गया है।कम डुप्लिकेट समस्याएँ
पंक्ति संख्या बदलने से कोई नई समस्या उत्पन्न नहीं होती.विभिन्न मूल कारणों के साथ जटिल मुद्दों का आसान डिबगिंग
किसी समस्या के सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए वेरिएंट का उपयोग करें।अधिक सार्थक चेतावनियाँ और संकेत
एक नया मुद्दा वास्तव में एक नए बग का प्रतिनिधित्व करता है।अधिक शक्तिशाली खोज
प्रत्येक अंक में अधिक खोजने योग्य मेटाडेटा होता है, जैसे अपवाद प्रकार और पैकेज नाम।
यहां बताया गया है कि ये सुधार कैसे हो रहे हैं:
जब हमें आपके ऐप से नए इवेंट मिलेंगे, तो हम जांच करेंगे कि क्या वे मौजूदा मुद्दे से मेल खाते हैं।
यदि कोई मेल नहीं है, तो हम स्वचालित रूप से इवेंट में हमारे स्मार्ट इवेंट-ग्रुपिंग एल्गोरिदम को लागू करेंगे और संशोधित मेटाडेटा डिज़ाइन के साथ एक नया मुद्दा बनाएंगे।
यह पहला बड़ा अपडेट है जो हम अपने इवेंट ग्रुपिंग में कर रहे हैं। यदि आपके पास कोई प्रतिक्रिया है या कोई समस्या आती है, तो कृपया रिपोर्ट दर्ज करके हमें बताएं।
क्रैशलिटिक्स एंड्रॉइड 11 और उच्चतर चलाने वाले उपकरणों से एंड्रॉइड ऐप्स के लिए एएनआर रिपोर्टिंग का समर्थन करता है। अंतर्निहित एपीआई जिसका उपयोग हम ANR ( getHistoricalProcessExitReasons ) एकत्र करने के लिए करते हैं, SIGQUIT या वॉचडॉग-आधारित दृष्टिकोण से अधिक विश्वसनीय है। यह API केवल Android 11+ डिवाइस पर उपलब्ध है।
यदि आपके कुछ ANR में BuildId गायब है, तो निम्नानुसार समस्या निवारण करें:
सुनिश्चित करें कि आप अप-टू-डेट क्रैशलिटिक्स एंड्रॉइड एसडीके और क्रैशलिटिक्स ग्रैडल प्लगइन संस्करण का उपयोग कर रहे हैं।
यदि आपके पास Android 11 के लिए
BuildIdऔर कुछ Android 12 ANR नहीं हैं, तो संभव है कि आप पुराने SDK, Gradle प्लगइन या दोनों का उपयोग कर रहे हैं। इन ANRs के लिएBuildIdको ठीक से एकत्र करने के लिए, आपको निम्नलिखित संस्करणों का उपयोग करने की आवश्यकता है:- क्रैशलिटिक्स एंड्रॉइड एसडीके v18.3.5+ (फायरबेस बीओएम v31.2.2+)
- क्रैशलिटिक्स ग्रैडल प्लगइन v2.9.4+
जांचें कि क्या आप अपनी साझा लाइब्रेरी के लिए गैर-मानक स्थान का उपयोग कर रहे हैं।
यदि आप अपने ऐप की साझा लाइब्रेरी के लिए केवल
BuildIdमिस कर रहे हैं, तो संभव है कि आप साझा लाइब्रेरी के लिए मानक, डिफ़ॉल्ट स्थान का उपयोग नहीं कर रहे हैं। यदि यह मामला है, तो क्रैशलाइटिक्स संबंधितBuildIdपता लगाने में सक्षम नहीं हो सकता है। हम अनुशंसा करते हैं कि आप साझा पुस्तकालयों के लिए मानक स्थान का उपयोग करने पर विचार करें।सुनिश्चित करें कि आप निर्माण प्रक्रिया के दौरान
BuildIdको अलग नहीं कर रहे हैं।ध्यान दें कि निम्नलिखित समस्या निवारण युक्तियाँ ANR और नेटिव क्रैश दोनों पर लागू होती हैं।
अपने बायनेरिज़ पर
readelf -nचलाकर जांचें किBuildIdमौजूद है या नहीं। यदिBuildIdअनुपस्थित हैं, तो अपने बिल्ड सिस्टम के लिए फ़्लैग में-Wl,--build-idजोड़ें।जांचें कि आप अपने एपीके आकार को कम करने के प्रयास में अनजाने में
BuildIdको हटा नहीं रहे हैं।यदि आप किसी लाइब्रेरी के स्ट्रिप्ड और अनस्ट्रिप्ड संस्करण रखते हैं, तो अपने कोड में सही संस्करण को इंगित करना सुनिश्चित करें।
Google Play और Crashlytics के बीच ANR की गिनती में बेमेल हो सकता है। एएनआर डेटा एकत्र करने और रिपोर्ट करने के तंत्र में अंतर के कारण यह अपेक्षित है। क्रैशलिटिक्स ऐप के अगली बार शुरू होने पर ANR रिपोर्ट करता है, जबकि Android Vitals ANR होने के बाद ANR डेटा भेजता है।
इसके अतिरिक्त, क्रैशलाईटिक्स केवल एंड्रॉइड 11+ चलाने वाले उपकरणों पर होने वाले एएनआर प्रदर्शित करता है, जबकि Google Play की तुलना में यह Google Play सेवाओं और स्वीकृत डेटा संग्रह सहमति वाले उपकरणों से एएनआर प्रदर्शित करता है।
एलएलवीएम और जीएनयू टूलचेन में आपके ऐप के बायनेरिज़ के रीड-ओनली सेगमेंट के लिए अलग-अलग डिफ़ॉल्ट और उपचार हैं, जो फायरबेस कंसोल में असंगत स्टैक ट्रेस उत्पन्न कर सकते हैं। इसे कम करने के लिए, अपनी निर्माण प्रक्रिया में निम्नलिखित लिंकर फ़्लैग जोड़ें:
यदि आप एलएलवीएम टूलचेन से
lldलिंकर का उपयोग कर रहे हैं, तो जोड़ें:-Wl,--no-rosegmentयदि आप GNU टूलचेन से
ld.goldलिंकर का उपयोग कर रहे हैं, तो जोड़ें:-Wl,--rosegment
यदि आप अभी भी स्टैक ट्रेस विसंगतियां देख रहे हैं (या यदि कोई भी ध्वज आपके टूलचेन से प्रासंगिक नहीं है), तो इसके बजाय अपनी निर्माण प्रक्रिया में निम्नलिखित जोड़ने का प्रयास करें:
-fno-omit-frame-pointer
क्रैशलिटिक्स प्लगइन एक अनुकूलित ब्रेकपैड प्रतीक फ़ाइल जनरेटर को बंडल करता है। यदि आप ब्रेकपैड प्रतीक फ़ाइलों को उत्पन्न करने के लिए अपनी स्वयं की बाइनरी का उपयोग करना पसंद करते हैं (उदाहरण के लिए, यदि आप स्रोत से अपनी बिल्ड श्रृंखला में सभी मूल निष्पादन योग्य बनाना पसंद करते हैं), तो निष्पादन योग्य के पथ को निर्दिष्ट करने के लिए वैकल्पिक symbolGeneratorBinary एक्सटेंशन प्रॉपर्टी का उपयोग करें।
आप दो तरीकों में से एक में ब्रेकपैड सिंबल फ़ाइल जेनरेटर बाइनरी का पथ निर्दिष्ट कर सकते हैं:
विकल्प 1 : अपनी
build.gradleफ़ाइल मेंfirebaseCrashlyticsएक्सटेंशन के माध्यम से पथ निर्दिष्ट करेंअपनी ऐप-स्तरीय
build.gradleफ़ाइल में निम्नलिखित जोड़ें:android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }विकल्प 2 : अपनी ग्रैडल प्रॉपर्टी फ़ाइल में प्रॉपर्टी लाइन के माध्यम से पथ निर्दिष्ट करें
निष्पादन योग्य का पथ निर्दिष्ट करने के लिए आप
com.google.firebase.crashlytics.symbolGeneratorBinaryप्रॉपर्टी का उपयोग कर सकते हैं।आप अपनी ग्रैडल प्रॉपर्टीज़ फ़ाइल को मैन्युअल रूप से अपडेट कर सकते हैं या कमांड लाइन के माध्यम से फ़ाइल को अपडेट कर सकते हैं। उदाहरण के लिए, कमांड लाइन के माध्यम से पथ निर्दिष्ट करने के लिए, निम्न जैसे कमांड का उपयोग करें:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
यदि आपको निम्नलिखित अपवाद दिखाई देता है, तो संभव है कि आप डेक्सगार्ड के एक संस्करण का उपयोग कर रहे हैं जो फायरबेस क्रैशलाईटिक्स एसडीके के साथ असंगत है:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
यह अपवाद आपके ऐप को क्रैश नहीं करता है बल्कि उसे क्रैश रिपोर्ट भेजने से रोकता है। इसे ठीक करने के लिए:
सुनिश्चित करें कि आप नवीनतम DexGuard 8.x रिलीज़ का उपयोग कर रहे हैं। नवीनतम संस्करण में वे नियम शामिल हैं जो फायरबेस क्रैशलाइटिक्स एसडीके के लिए आवश्यक हैं।
यदि आप अपना DexGuard संस्करण नहीं बदलना चाहते हैं, तो अपने अस्पष्टीकरण नियमों (अपनी DexGuard कॉन्फ़िग फ़ाइल में) में निम्नलिखित पंक्ति जोड़ने का प्रयास करें:
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
जब कोई ऐप एक ऑबफस्केटर का उपयोग करता है जो फ़ाइल एक्सटेंशन को उजागर नहीं करता है, तो क्रैशलाइटिक्स प्रत्येक समस्या को डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ उत्पन्न करता है।
ताकि Crashlytics सही फ़ाइल एक्सटेंशन के साथ समस्याएँ उत्पन्न कर सके, सुनिश्चित करें कि आपका ऐप निम्नलिखित सेटअप का उपयोग करता है:
- एंड्रॉइड ग्रैडल 4.2.0 या उच्चतर का उपयोग करता है
- ओफ़्स्क्यूशन चालू होने पर R8 का उपयोग करता है। अपने ऐप को R8 पर अपडेट करने के लिए, इस दस्तावेज़ का पालन करें।
ध्यान दें कि ऊपर वर्णित सेटअप को अपडेट करने के बाद, आपको नए .kt मुद्दे दिखाई देने शुरू हो सकते हैं जो मौजूदा .java मुद्दों के डुप्लिकेट हैं। उस परिस्थिति के बारे में अधिक जानने के लिए FAQ देखें।
दिसंबर 2021 के मध्य से शुरू होकर, क्रैशलिटिक्स ने कोटलिन का उपयोग करने वाले अनुप्रयोगों के लिए समर्थन में सुधार किया।
हाल तक, उपलब्ध ओफ़्फ़स्केटर्स फ़ाइल एक्सटेंशन को उजागर नहीं करते थे, इसलिए क्रैशलाईटिक्स ने प्रत्येक समस्या को डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ उत्पन्न किया। हालाँकि, Android Gradle 4.2.0 के अनुसार, R8 फ़ाइल एक्सटेंशन का समर्थन करता है।
इस अद्यतन के साथ, क्रैशलाइटिक्स अब यह निर्धारित कर सकता है कि ऐप के भीतर उपयोग की जाने वाली प्रत्येक कक्षा कोटलिन में लिखी गई है या नहीं और समस्या हस्ताक्षर में सही फ़ाइल नाम शामिल कर सकती है। यदि आपके ऐप में निम्नलिखित सेटअप है, तो क्रैश को अब .kt फ़ाइलों (जैसा उपयुक्त हो) के लिए सही ढंग से जिम्मेदार ठहराया जाता है:
- आपका ऐप Android Gradle 4.2.0 या उच्चतर का उपयोग करता है।
- आपका ऐप ऑबफस्केशन चालू होने पर R8 का उपयोग करता है।
चूंकि नए क्रैश में अब उनके समस्या हस्ताक्षरों में सही फ़ाइल एक्सटेंशन शामिल है, आप नए .kt मुद्दे देख सकते हैं जो वास्तव में मौजूदा .java -लेबल मुद्दों के डुप्लिकेट हैं। फायरबेस कंसोल में, हम यह पहचानने और आपसे संवाद करने का प्रयास करते हैं कि क्या कोई नया .kt मुद्दा मौजूदा .java -लेबल वाले मुद्दे का संभावित डुप्लिकेट है।
क्रैश-फ़्री मान उन उपयोगकर्ताओं के प्रतिशत को दर्शाता है जो आपके ऐप से जुड़े थे लेकिन एक विशिष्ट समय अवधि में क्रैश नहीं हुए थे।
यहां क्रैश-मुक्त उपयोगकर्ताओं के प्रतिशत की गणना करने का सूत्र दिया गया है। इसके इनपुट मान 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 से लिंक करने के बाद, आपके द्वारा बनाए गए नए डेटासेट स्वचालित रूप से संयुक्त राज्य अमेरिका में स्थित हो जाते हैं, चाहे आपके फायरबेस प्रोजेक्ट का स्थान कुछ भी हो।
मंच का समर्थन
फायरबेस क्रैशलिटिक्स एनडीके ARMv5 (armeabi) का समर्थन नहीं करता है। इस ABI के लिए समर्थन NDK r17 से हटा दिया गया था।
पीछे छूट गए मुद्दे
जब आपने पहले समस्या को बंद कर दिया था तो एक समस्या वापस आ गई थी, लेकिन क्रैशलाईटिक्स को एक नई रिपोर्ट मिलती है कि समस्या फिर से उत्पन्न हो गई है। क्रैशलिटिक्स स्वचालित रूप से इन वापस आए मुद्दों को फिर से खोलता है ताकि आप उन्हें अपने ऐप के लिए उपयुक्त रूप में संबोधित कर सकें।
यहां एक उदाहरण परिदृश्य है जो बताता है कि कैसे क्रैशलाइटिक्स किसी समस्या को प्रतिगमन के रूप में वर्गीकृत करता है:
- पहली बार, क्रैशलाइटिक्स को क्रैश "ए" के बारे में क्रैश रिपोर्ट प्राप्त हुई। क्रैशलाइटिक्स उस क्रैश के लिए एक संबंधित अंक खोलता है (अंक "ए")।
- आप इस बग को शीघ्रता से ठीक करें, अंक "ए" को बंद करें, और फिर अपने ऐप का एक नया संस्करण जारी करें।
- आपके द्वारा समस्या बंद करने के बाद क्रैशलिटिक्स को अंक "ए" के बारे में एक और रिपोर्ट मिलती है।
- यदि रिपोर्ट किसी ऐप संस्करण से है जिसके बारे में क्रैशलिटिक्स को तब पता था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी), तो क्रैशलाइटिक्स इस मुद्दे को वापस नहीं मानेगा। मामला बंद रहेगा.
- यदि रिपोर्ट किसी ऐप संस्करण से है जिसके बारे में क्रैशलिटिक्स को पता नहीं था कि आपने समस्या को कब बंद किया था (मतलब कि संस्करण ने कभी भी किसी क्रैश के लिए कोई क्रैश रिपोर्ट नहीं भेजी थी), तो क्रैशलाइटिक्स समस्या को वापस ले लिया हुआ मानता है और समस्या को फिर से खोल देगा। .
जब कोई समस्या वापस आती है, तो हम एक रिग्रेशन डिटेक्शन अलर्ट भेजते हैं और समस्या में एक रिग्रेशन सिग्नल जोड़ते हैं ताकि आपको पता चल सके कि क्रैशलाईटिक्स ने समस्या को फिर से खोल दिया है। यदि आप नहीं चाहते कि कोई समस्या हमारे प्रतिगमन एल्गोरिदम के कारण दोबारा खुले, तो समस्या को बंद करने के बजाय उसे "म्यूट" करें।
यदि कोई रिपोर्ट किसी पुराने ऐप संस्करण से है, जिसने समस्या को बंद करते समय कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो क्रैशलाइटिक्स समस्या को वापस मानता है और समस्या को फिर से खोल देगा।
यह स्थिति निम्नलिखित स्थिति में हो सकती है: आपने एक बग ठीक कर दिया है और अपने ऐप का एक नया संस्करण जारी किया है, लेकिन आपके पास अभी भी बग फिक्स के बिना पुराने संस्करणों पर उपयोगकर्ता हैं। यदि, संयोग से, उन पुराने संस्करणों में से एक ने समस्या को बंद करते समय कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, और उन उपयोगकर्ताओं को बग का सामना करना शुरू हो गया, तो वे क्रैश रिपोर्ट एक प्रतिगामी समस्या को ट्रिगर कर देंगी।
यदि आप नहीं चाहते कि कोई समस्या हमारे प्रतिगमन एल्गोरिदम के कारण दोबारा खुले, तो समस्या को बंद करने के बजाय उसे "म्यूट" करें।