Crashlytics समस्या निवारण और अक्सर पूछे जाने वाले प्रश्न

क्रैश-मुक्त उपयोगकर्ता, ब्रेडक्रंब लॉग और/या वेलोसिटी अलर्ट दिखाई नहीं दे रहे हैं

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

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

हालाँकि, घटनाओं के इस समूह के भीतर, विफलता की ओर ले जाने वाले स्टैक ट्रेस भिन्न हो सकते हैं। एक अलग स्टैक ट्रेस का मतलब एक अलग मूल कारण हो सकता है। किसी मुद्दे के भीतर इस संभावित अंतर का प्रतिनिधित्व करने के लिए, अब हम मुद्दों के भीतर वेरिएंट बनाते हैं - प्रत्येक संस्करण एक समस्या में घटनाओं का एक उप-समूह होता है जिसमें समान विफलता बिंदु और समान स्टैक ट्रेस होता है। वेरिएंट के साथ, आप किसी समस्या के भीतर सबसे सामान्य स्टैक ट्रेस को डिबग कर सकते हैं और यह निर्धारित कर सकते हैं कि क्या विभिन्न मूल कारण विफलता का कारण बन रहे हैं।

यहां बताया गया है कि आप इन सुधारों के साथ क्या अनुभव करेंगे:

• नया रूप दिया गया मेटाडेटा समस्या पंक्ति में प्रदर्शित होता है
  अब आपके ऐप में समस्याओं को समझना और उनका चयन करना आसान हो गया है।

• कम डुप्लिकेट मुद्दे
  एक पंक्ति संख्या परिवर्तन के परिणामस्वरूप कोई नई समस्या नहीं होती है।

• विभिन्न मूल कारणों के साथ जटिल मुद्दों की आसान डिबगिंग
  किसी समस्या के सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए वेरिएंट का इस्तेमाल करें.

• अधिक सार्थक अलर्ट और सिग्नल
  एक नया मुद्दा वास्तव में एक नए बग का प्रतिनिधित्व करता है।

• अधिक शक्तिशाली खोज
  प्रत्येक अंक में अधिक खोजने योग्य मेटाडेटा होता है, जैसे अपवाद प्रकार और पैकेज का नाम।

यहां बताया गया है कि ये सुधार कैसे शुरू हो रहे हैं:

• जब हमें आपके ऐप से नए ईवेंट मिलते हैं, तो हम जाँच करेंगे कि क्या वे किसी मौजूदा समस्या से मेल खाते हैं।

• यदि कोई मिलान नहीं होता है, तो हम स्वचालित रूप से अपने स्मार्ट इवेंट-ग्रुपिंग एल्गोरिद्म को ईवेंट पर लागू कर देंगे और संशोधित मेटाडेटा डिज़ाइन के साथ एक नया मुद्दा बना देंगे।

यह पहला बड़ा अपडेट है जो हम अपने इवेंट ग्रुपिंग में कर रहे हैं। यदि आपके पास प्रतिक्रिया है या कोई समस्या आती है, तो कृपया रिपोर्ट दर्ज करके हमें बताएं।

ANRs को केवल Android 11+ के लिए ही क्यों रिपोर्ट किया जाता है?

Crashlytics Android 11 और उसके बाद के संस्करण चलाने वाले उपकरणों से Android ऐप्स के लिए ANR रिपोर्टिंग का समर्थन करता है। ANRs ( getHistoricalProcessExitReasons ) एकत्र करने के लिए हम जिस अंतर्निहित API का उपयोग करते हैं, वह SIGQUIT या वॉचडॉग-आधारित दृष्टिकोणों की तुलना में अधिक विश्वसनीय है। यह API केवल Android 11+ डिवाइस पर उपलब्ध है।

कुछ ANRs के BuildId क्यों नहीं हैं?

यदि आपके कुछ ANR में उनके BuildId नहीं हैं, तो निम्नानुसार समस्या निवारण करें:

• सुनिश्चित करें कि आप अप-टू-डेट Crashlytics Android SDK और Crashlytics Gradle प्लगइन संस्करण का उपयोग कर रहे हैं।

  यदि आप Android 11 और कुछ Android 12 ANR के लिए BuildId खो रहे हैं, तो संभव है कि आप पुराने SDK, Gradle प्लगइन, या दोनों का उपयोग कर रहे हों। इन ANRs के लिए BuildId ठीक से एकत्रित करने के लिए, आपको निम्न संस्करणों का उपयोग करने की आवश्यकता है:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle प्लगइन v2.9.4+

• जांचें कि क्या आप अपने साझा पुस्तकालयों के लिए गैर-मानक स्थान का उपयोग कर रहे हैं।

  यदि आप अपने ऐप के साझा पुस्तकालयों के लिए केवल BuildId खो रहे हैं, तो संभव है कि आप साझा पुस्तकालयों के लिए मानक, डिफ़ॉल्ट स्थान का उपयोग नहीं कर रहे हों। अगर ऐसा है, तो Crashlytics संबद्ध BuildId s का पता लगाने में सक्षम नहीं हो सकता है। हम अनुशंसा करते हैं कि आप साझा लाइब्रेरी के लिए मानक स्थान का उपयोग करने पर विचार करें.

• सुनिश्चित करें कि आप बिल्ड प्रक्रिया के दौरान BuildId s को अलग नहीं कर रहे हैं।

  ध्यान दें कि निम्न समस्या निवारण युक्तियाँ ANR और स्थानीय क्रैश दोनों पर लागू होती हैं।

  • जांचें कि आपकी बाइनरी पर readelf -n चलाकर BuildId मौजूद है या नहीं। यदि BuildId अनुपस्थित हैं, तो -Wl,--build-id अपने बिल्ड सिस्टम के फ़्लैग में जोड़ें।

  • जांचें कि आप अपने एपीके आकार को कम करने के प्रयास में अनजाने में BuildId को अलग नहीं कर रहे हैं।

  • यदि आप किसी लाइब्रेरी के स्ट्रिप्ड और अनस्ट्रिप्ड संस्करण रखते हैं, तो अपने कोड में सही संस्करण को इंगित करना सुनिश्चित करें।

Crashlytics डैशबोर्ड और Google Play कंसोल में ANR रिपोर्ट के बीच अंतर

Google Play और Crashlytics के बीच ANRs की गिनती के बीच बेमेल हो सकता है। यह ANR डेटा एकत्र करने और रिपोर्ट करने के तंत्र में अंतर के कारण अपेक्षित है। जब ऐप अगली बार शुरू होता है तो Crashlytics ANRs की रिपोर्ट करता है, जबकि Android Vitals ANR होने के बाद ANR डेटा भेजता है।

इसके अतिरिक्त, Google Play की तुलना में Crashlytics केवल Android 11+ चलाने वाले उपकरणों पर होने वाले ANR प्रदर्शित करता है, जो Google Play सेवाओं और डेटा संग्रह सहमति वाले उपकरणों से ANR प्रदर्शित करता है।

Crashlytics डैशबोर्ड और logcat में NDK स्टैक ट्रेस के बीच अंतर

एलएलवीएम और जीएनयू टूलचैन में आपके ऐप की बायनेरिज़ के रीड-ओनली सेगमेंट के लिए अलग-अलग डिफ़ॉल्ट और उपचार हैं, जो फायरबेस कंसोल में असंगत स्टैक ट्रेस उत्पन्न कर सकते हैं। इसे कम करने के लिए, अपनी बिल्ड प्रक्रिया में निम्न लिंकर फ़्लैग जोड़ें:

• यदि आप एलएलवीएम टूलचैन से lld लिंकर का उपयोग कर रहे हैं, तो जोड़ें:

  -Wl,--no-rosegment
  

• यदि आप GNU टूलचेन से ld.gold लिंकर का उपयोग कर रहे हैं, तो जोड़ें:

  -Wl,--rosegment
  

यदि आप अभी भी स्टैक ट्रेस विसंगतियां देख रहे हैं (या यदि कोई भी फ़्लैग आपके टूलचैन से संबंधित नहीं है), तो इसके बजाय अपनी बिल्ड प्रक्रिया में निम्नलिखित को जोड़ने का प्रयास करें:

-fno-omit-frame-pointer

मैं एनडीके के लिए अपने स्वयं के ब्रेकपैड प्रतीक फ़ाइल जेनरेटर बाइनरी का उपयोग कैसे करूं?

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

डेक्सगार्ड के साथ क्रैश नहीं हो रहा है

यदि आप निम्न अपवाद देखते हैं, तो संभव है कि आप DexGuard के ऐसे संस्करण का उपयोग कर रहे हैं जो Firebase Crashlytics SDK के साथ असंगत है:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

यह अपवाद आपके ऐप को क्रैश नहीं करता है लेकिन इसे क्रैश रिपोर्ट भेजने से रोकता है। इसे ठीक करने के लिए:

1. सुनिश्चित करें कि आप नवीनतम DexGuard 8.x रिलीज़ का उपयोग कर रहे हैं। नवीनतम संस्करण में वे नियम हैं जो Firebase Crashlytics SDK के लिए आवश्यक हैं।

2. यदि आप अपने DexGuard संस्करण को बदलना नहीं चाहते हैं, तो निम्न पंक्ति को अपने अस्पष्टता नियमों (अपनी DexGuard कॉन्फ़िगरेशन फ़ाइल में) में जोड़ने का प्रयास करें:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct
   

मुझे .kt फ़ाइलों से .java समस्याओं के रूप में लेबल किए गए क्रैश क्यों दिखाई देते हैं?

जब कोई ऐप किसी ऑबफसकेटर का उपयोग करता है जो फ़ाइल एक्सटेंशन को उजागर नहीं करता है, तो Crashlytics डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ प्रत्येक समस्या उत्पन्न करता है।

ताकि Crashlytics सही फ़ाइल एक्सटेंशन के साथ समस्या उत्पन्न कर सके, सुनिश्चित करें कि आपका ऐप निम्न सेटअप का उपयोग करता है:

• Android Gradle 4.2.0 या उच्चतर का उपयोग करता है
• R8 का उपयोग अस्पष्टता चालू के साथ करता है। अपने ऐप को R8 में अपडेट करने के लिए, इस दस्तावेज़ का पालन करें।

ध्यान दें कि ऊपर वर्णित सेटअप में अपडेट करने के बाद, आपको नई .kt समस्याएँ दिखाई देने लग सकती हैं जो मौजूदा .java समस्याओं के डुप्लिकेट हैं। उस परिस्थिति के बारे में अधिक जानने के लिए अक्सर पूछे जाने वाले प्रश्न देखें।

मुझे .kt समस्याएँ क्यों दिखाई देती हैं जो मौजूदा .java समस्याओं के डुप्लिकेट हैं?

दिसंबर 2021 के मध्य से क्रैशलाइटिक्स ने कोटलिन का उपयोग करने वाले अनुप्रयोगों के लिए समर्थन में सुधार किया।

कुछ समय पहले तक, उपलब्ध पर्यवेक्षक फ़ाइल एक्सटेंशन को उजागर नहीं करते थे, इसलिए Crashlytics डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ प्रत्येक समस्या उत्पन्न करता है। हालाँकि, Android Gradle 4.2.0 के रूप में, R8 फ़ाइल एक्सटेंशन का समर्थन करता है।

इस अद्यतन के साथ, Crashlytics अब यह निर्धारित कर सकता है कि ऐप के भीतर उपयोग की जाने वाली प्रत्येक कक्षा कोटलिन में लिखी गई है और समस्या हस्ताक्षर में सही फ़ाइल नाम शामिल करती है। यदि आपके ऐप में निम्न सेटअप है तो क्रैश को अब सही ढंग से .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 उन उपयोगकर्ताओं की कुल संख्या का प्रतिनिधित्व करता है, जो आपके द्वारा Crashlytics डैशबोर्ड के ऊपरी-दाएँ भाग में ड्रॉपडाउन मेनू से चुनी गई समयावधि के दौरान आपके ऐप से जुड़े रहे।

क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत समय के साथ एकत्रीकरण है, औसत नहीं।

उदाहरण के लिए, कल्पना करें कि आपके ऐप के तीन उपयोगकर्ता हैं; हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B और उपयोगकर्ता C कहेंगे। निम्न तालिका दर्शाती है कि कौन से उपयोगकर्ता प्रतिदिन आपके ऐप से जुड़े और उनमें से किस उपयोगकर्ता का उस दिन क्रैश हुआ था:

• बुधवार को, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 50% है (2 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
  आपके दो उपयोगकर्ता बुधवार को आपके ऐप से जुड़े थे, लेकिन उनमें से केवल एक (उपयोगकर्ता B) का कोई क्रैश नहीं हुआ था।

• पिछले 2 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 33.3% है (3 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
  आपके तीन उपयोगकर्ता पिछले दो दिनों में आपके ऐप से जुड़े, लेकिन उनमें से केवल एक (उपयोगकर्ता C) का कोई क्रैश नहीं हुआ।

• पिछले 3 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 0% है (3 में से 0 उपयोगकर्ता क्रैश-मुक्त थे)।
  आपके तीन उपयोगकर्ता पिछले तीन दिनों में आपके ऐप से जुड़े, लेकिन उनमें से शून्य का कोई क्रैश नहीं हुआ।

किसी मुद्दे पर नोट कौन देख सकता है, लिख सकता है और हटा सकता है?

नोट्स परियोजना के सदस्यों को प्रश्नों, स्थिति अपडेट आदि के साथ विशिष्ट मुद्दों पर टिप्पणी करने की अनुमति देते हैं।

जब कोई प्रोजेक्ट सदस्य कोई नोट पोस्ट करता है, तो उसे उनके Google खाते के ईमेल के साथ लेबल किया जाता है। यह ईमेल पता, नोट के साथ, उन सभी प्रोजेक्ट सदस्यों के लिए दृश्यमान है, जिनके पास नोट देखने की पहुंच है।

निम्नलिखित नोट्स देखने, लिखने और हटाने के लिए आवश्यक एक्सेस का वर्णन करता है:

• निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य मौजूदा नोट्स को देख और हटा सकते हैं और किसी मुद्दे पर नए नोट्स लिख सकते हैं।

  • प्रोजेक्ट स्वामी या संपादक , Firebase व्यवस्थापक , गुणवत्ता व्यवस्थापक , या Crashlytics व्यवस्थापक

• निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य किसी मुद्दे पर पोस्ट किए गए नोट्स देख सकते हैं, लेकिन वे नोट को हटा या लिख ​​नहीं सकते हैं।

  • प्रोजेक्ट व्यूअर , फायरबेस व्यूअर , क्वालिटी व्यूअर या क्रैशलाइटिक्स व्यूअर

ऐप Google मोबाइल विज्ञापन SDK का भी उपयोग करता है लेकिन क्रैश नहीं हो रहा है

यदि आपका प्रोजेक्ट Google मोबाइल विज्ञापन SDK के साथ Crashlytics का उपयोग करता है, तो संभव है कि क्रैश रिपोर्टर अपवाद संचालकों को पंजीकृत करते समय हस्तक्षेप कर रहे हों। समस्या को ठीक करने के लिए, disableSDKCrashReporting कॉल करके मोबाइल विज्ञापन SDK में क्रैश रिपोर्टिंग बंद करें।

मेरा BigQuery डेटासेट कहाँ स्थित है?

आपके द्वारा Crashlytics को BigQuery से लिंक करने के बाद, आपके द्वारा बनाए गए नए डेटासेट आपके Firebase प्रोजेक्ट के स्थान की परवाह किए बिना स्वचालित रूप से संयुक्त राज्य अमेरिका में स्थित हैं।

क्या Crashlytics armeabi का समर्थन करता है?

Firebase Crashlytics NDK ARMv5 (armeabi) का समर्थन नहीं करता है। इस ABI के लिए समर्थन NDK r17 के रूप में हटा दिया गया था।

एक प्रतिगमन मुद्दा क्या है?

जब आपने समस्या को पहले ही बंद कर दिया था, तो समस्या वापस आ गई थी, लेकिन Crashlytics को एक नई रिपोर्ट मिलती है कि समस्या फिर से हुई है। Crashlytics स्वचालित रूप से इन प्रतिगामी समस्याओं को फिर से खोल देता है ताकि आप उन्हें अपने ऐप के लिए उपयुक्त रूप से संबोधित कर सकें।

यहां एक उदाहरण परिदृश्य दिया गया है जो बताता है कि Crashlytics किसी समस्या को प्रतिगमन के रूप में कैसे वर्गीकृत करता है:

1. पहली बार, Crashlytics को Crash "A" के बारे में क्रैश रिपोर्ट मिलती है। Crashlytics उस क्रैश (अंक "A") के लिए संबंधित समस्या खोलता है।
2. आप इस बग को जल्दी से ठीक करें, अंक "ए" को बंद करें और फिर अपने ऐप का एक नया संस्करण जारी करें।
3. आपके द्वारा समस्या बंद करने के बाद Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है।
   • यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी), तो Crashlytics इस मुद्दे को वापस नहीं लेगा। मामला बंद रहेगा।
   • यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता नहीं था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने कभी भी किसी क्रैश के लिए कोई क्रैश रिपोर्ट नहीं भेजी थी), तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी .

जब कोई समस्या वापस आती है, तो हम एक रिग्रेशन डिटेक्शन अलर्ट भेजते हैं और समस्या में एक रिग्रेशन सिग्नल जोड़ते हैं ताकि आपको पता चल सके कि Crashlytics ने समस्या को फिर से खोल दिया है। यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।

मुझे ऐप के पुराने संस्करणों के लिए प्रतिगामी समस्याएं क्यों दिखाई दे रही हैं?

यदि कोई रिपोर्ट किसी पुराने ऐप संस्करण से है जिसने समस्या को बंद करने के दौरान कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी।

यह स्थिति निम्न स्थिति में हो सकती है: आपने एक बग ठीक कर लिया है और अपने ऐप का एक नया संस्करण जारी कर दिया है, लेकिन आपके पास अभी भी बग फिक्स के बिना पुराने संस्करणों पर उपयोगकर्ता हैं। यदि, संयोग से, उन पुराने संस्करणों में से एक ने कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी जब आपने समस्या को बंद कर दिया था, और उन उपयोगकर्ताओं को बग का सामना करना शुरू हो गया, तो वे क्रैश रिपोर्ट एक प्रतिगमन समस्या को ट्रिगर करेंगे।

यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।