Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल

iOS+ Android Flutter Unity

इस पेज पर, समस्या हल करने में मदद मिलती है. साथ ही, Crashlytics के इस्तेमाल के बारे में अक्सर पूछे जाने वाले सवालों के जवाब भी मिलते हैं. अगर आपको अपनी ज़रूरत के हिसाब से जानकारी नहीं मिल पा रही है या आपको और मदद चाहिए, तो Firebase की सहायता टीम से संपर्क करें.

समस्या हल करने के सामान्य तरीके/अक्सर पूछे जाने वाले सवाल

समस्याएं टेबल में, कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट (और कभी-कभी "वैरिएंट") दिखना

आपको Firebase कंसोल में, समस्याएं टेबल में दी गई समस्याओं के लिए, दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. साथ ही, आपको अपनी कुछ समस्याओं में "वैरिएंट" नाम की सुविधा भी दिख सकती है. इसकी वजह यहां बताई गई है!

साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए, बेहतर विश्लेषण इंजन लॉन्च किया था. साथ ही, हमने इसका अपडेट किया गया डिज़ाइन और नई समस्याओं (जैसे, वैरिएंट!) के लिए कुछ ऐडवांस सुविधाएं भी लॉन्च की थीं. पूरी जानकारी के लिए, हमारी हाल की ब्लॉग पोस्ट देखें. हालांकि, यहां दी गई हाइलाइट के बारे में पढ़ें.

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट (जैसे, क्रैश, गैर-फ़ैटल, और ANR) का विश्लेषण करता है. साथ ही, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहा जाता है — किसी समस्या में मौजूद सभी इवेंट में एक ही तरह की गड़बड़ी होती है.

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

हालांकि, इवेंट के इस ग्रुप में, गड़बड़ी की वजह से स्टैक ट्रेस अलग-अलग हो सकते हैं. अगर स्टैक ट्रेस अलग है, तो इसकी अलग वजह हो सकती है. किसी समस्या में इस संभावित अंतर को दिखाने के लिए, अब हम समस्याओं में वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या में इवेंट का ऐसा सब-ग्रुप होता है जिसमें फ़ेलियर पॉइंट और एक जैसा स्टैक ट्रेस होता है. वैरिएंट की मदद से, किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि क्या अलग-अलग मुख्य वजहों से गड़बड़ी हो रही है.

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

• समस्या वाली लाइन में बेहतर मेटाडेटा दिखाया गया है
  अब आपके ऐप्लिकेशन में समस्याओं को समझना और उन्हें प्राथमिकता के हिसाब से निपटाना आसान हो गया है.

• डुप्लीकेट समस्याएं कम होंगी
  लाइन नंबर बदलने पर, नई समस्या नहीं आती.

• अलग-अलग वजहों से होने वाली मुश्किल समस्याओं को आसानी से डीबग करना
  किसी समस्या में सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करें.

• ज़्यादा काम की चेतावनियां और सिग्नल
  एक नई समस्या का मतलब है कि एक नई गड़बड़ी हुई है.

• ज़्यादा असरदार खोज
  हर समस्या में, खोजे जा सकने वाले ज़्यादा मेटाडेटा होते हैं. जैसे, अपवाद का टाइप और पैकेज का नाम.

ये सुधार इस तरह रोल आउट किए जा रहे हैं:

• आपके ऐप्लिकेशन से नए इवेंट मिलने पर, हम जांच करेंगे कि वे किसी मौजूदा समस्या से मेल खाते हैं या नहीं.

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

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

क्रैश-फ़्री मेट्रिक और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं

अगर आपको क्रैश-फ़्री मेट्रिक (जैसे, क्रैश-फ़्री उपयोगकर्ता और सेशन) और/या वेग से जुड़ी चेतावनियां नहीं दिख रही हैं, तो पक्का करें कि आपने Crashlytics SDK टूल का 18.6.0 या इसके बाद का वर्शन (या Firebase BoM v32.6.0 या इसके बाद का वर्शन) इस्तेमाल किया हो.

ब्रेडक्रंब लॉग नहीं दिख रहे हैं

अगर आपको ब्रेडक्रंब लॉग नहीं दिख रहे हैं, तो हमारा सुझाव है कि आप अपने ऐप्लिकेशन के कॉन्फ़िगरेशन में Google Analytics देखें. पक्का करें कि आपने ये ज़रूरी शर्तें पूरी की हों:

• आपने अपने Firebase प्रोजेक्ट में, Google Analytics को चालू किया हो.

• आपने Google Analytics के लिए, डेटा शेयर करने की सुविधा चालू की है. Analytics में डेटा शेयर करने की सेटिंग मैनेज करना में जाकर, इस सेटिंग के बारे में ज़्यादा जानें

• आपने Google Analytics के लिए Firebase SDK टूल जोड़ा है . इस एसडीके को Crashlytics SDK टूल में के साथ जोड़ना ज़रूरी है.

• आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, Firebase SDK टूल के नए वर्शन इस्तेमाल किए हैं.

  खास तौर पर, यह देखें कि Google Analytics के लिए, Firebase SDK टूल के कम से कम इस वर्शन का इस्तेमाल किया जा रहा हो:
  Android — v17.2.3+ (BoM v24.7.1+).

सिर्फ़ Android 11 और उसके बाद के वर्शन के लिए, ANR की शिकायत क्यों की जाती है?

Crashlytics, Android 11 और उसके बाद के वर्शन वाले डिवाइसों पर, Android ऐप्लिकेशन के लिए ANR रिपोर्टिंग की सुविधा देता है. एएनआर इकट्ठा करने के लिए, हम जिस एपीआई का इस्तेमाल करते हैं (get प्रतिशतप्रोसेस बाहर निकलने की वजह), SIGQUIT या वॉचडॉग पर आधारित तरीकों के मुकाबले ज़्यादा भरोसेमंद है. यह एपीआई सिर्फ़ Android 11 और उसके बाद के वर्शन वाले डिवाइसों पर उपलब्ध है.

कुछ ANR में BuildId क्यों नहीं दिख रहे हैं?

अगर आपके कुछ ANR में BuildId मौजूद नहीं हैं, तो समस्या हल करने के लिए यह तरीका अपनाएं:

• पक्का करें कि आपके पास Crashlytics Android SDK टूल और Crashlytics Gradle प्लग इन का अप-टू-डेट वर्शन हो.

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

  • Crashlytics Android SDK टूल का वर्शन 18.3.5 और इसके बाद के वर्शन (Firebase BoM 31.2.2 और इसके बाद के वर्शन)
  • Crashlytics Gradle प्लग इन का 2.9.4 या इसके बाद का वर्शन

• देखें कि क्या शेयर की गई लाइब्रेरी के लिए, स्टैंडर्ड लोकेशन का इस्तेमाल किया जा रहा है या नहीं.

  अगर आपके ऐप्लिकेशन की शेयर की गई लाइब्रेरी के लिए सिर्फ़ BuildId मौजूद नहीं हैं, तो हो सकता है कि आपने शेयर की गई लाइब्रेरी के लिए स्टैंडर्ड, डिफ़ॉल्ट जगह का इस्तेमाल न किया हो. अगर ऐसा है, तो हो सकता है कि Crashlytics, उससे जुड़े BuildId को न ढूंढ पाए. हमारा सुझाव है कि शेयर की गई लाइब्रेरी के लिए, स्टैंडर्ड जगह का इस्तेमाल करें.

• पक्का करें कि बिल्ड करने की प्रोसेस के दौरान, BuildId को हटाया न जा रहा हो.

  ध्यान दें कि समस्या हल करने के ये सुझाव, ANR और नेटिव क्रैश, दोनों पर लागू होते हैं.

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

  • देखें कि APK का साइज़ कम करने के लिए, आपने BuildId को अनजाने में हटाया तो नहीं.

  • अगर आपने लाइब्रेरी के बिना स्ट्रिप किए गए और स्ट्रिप किए गए वर्शन बनाए हैं, तो पक्का करें कि आपने अपने कोड में सही वर्शन का इस्तेमाल किया हो.

Crashlytics डैशबोर्ड और Google Play Console में, एएनआर रिपोर्ट के बीच अंतर

Google Play और Crashlytics के बीच, ANR की संख्या में अंतर हो सकता है. ऐसा इसलिए होता है, क्योंकि ANR डेटा इकट्ठा करने और उसकी रिपोर्टिंग करने के तरीके में अंतर होता है. Crashlytics, ऐप्लिकेशन के अगली बार शुरू होने पर ANR की रिपोर्ट करता है. वहीं, 'Android की ज़रूरी जानकारी', ANR होने के बाद ANR का डेटा भेजती है.

इसके अलावा, Crashlytics सिर्फ़ Android 11 और उसके बाद के वर्शन वाले डिवाइसों पर होने वाले एएनआर दिखाता है. वहीं, Google Play उन डिवाइसों पर होने वाले एएनआर दिखाता है जिनमें Google Play services और डेटा इकट्ठा करने की सहमति स्वीकार की गई है.

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

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

• अगर LLVM टूलचेन से lld लिंकर का इस्तेमाल किया जा रहा है, तो जोड़ें:

  -Wl,--no-rosegment

• अगर GNU टूलचेन से ld.gold लिंकर का इस्तेमाल किया जा रहा है, तो जोड़ें:

  -Wl,--rosegment

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

-fno-omit-frame-pointer

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

Crashlytics प्लग इन, पसंद के मुताबिक बनाए गए Breakpad सिंबल फ़ाइल जनरेटर को बंडल करता है. अगर आपको Breakpad सिंबल फ़ाइलें जनरेट करने के लिए, अपनी बाइनरी का इस्तेमाल करना है, तो symbolGeneratorBinary एक्सटेंशन प्रॉपर्टी का इस्तेमाल करें. यह प्रॉपर्टी ज़रूरी नहीं है. इसका इस्तेमाल करके, एक्सीक्यूटेबल का पाथ बताया जा सकता है. उदाहरण के लिए, अगर आपको अपनी बिल्ड चेन में सोर्स से सभी नेटिव एक्सीक्यूटेबल बनाना है.

ध्यान दें: Android बाइनरी के लिए, Breakpad सिंबल फ़ाइल जनरेटर का Linux वर्शन ज़रूरी है.

ब्रेकपैड सिंबल फ़ाइल जनरेटर बाइनरी का पाथ, इन दो में से किसी एक तरीके से तय किया जा सकता है:

• पहला विकल्प: अपनी build.gradle फ़ाइल में firebaseCrashlytics एक्सटेंशन की मदद से पाथ बताएं

  ऐप्लिकेशन-लेवल की build.gradle.kts फ़ाइल में यह कोड जोड़ें:

  Gradle प्लग इन का वर्शन 3.0.0 और इसके बाद के वर्शन

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  प्लग इन के पुराने वर्शन

  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")
            }
          }
        }
     }
  }

• दूसरा विकल्प: अपनी Gradle प्रॉपर्टी फ़ाइल में प्रॉपर्टी लाइन के ज़रिए पाथ तय करना

  com.google.firebase.crashlytics.breakpadBinary प्रॉपर्टी का इस्तेमाल करके, एक्सीक्यूटेबल के पाथ की जानकारी दी जा सकती है.

  Gradle प्रॉपर्टी फ़ाइल को मैन्युअल तरीके से अपडेट किया जा सकता है या कमांड लाइन की मदद से अपडेट किया जा सकता है. उदाहरण के लिए, कमांड लाइन के ज़रिए पाथ तय करने के लिए, इस तरह के कमांड का इस्तेमाल करें:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Dexguard की मदद से क्रैश नहीं हो रहे हैं

अगर आपको यह अपवाद दिखता है, तो इसका मतलब है कि शायद आपके डिवाइस में 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 ने Kotlin का इस्तेमाल करने वाले ऐप्लिकेशन के लिए बेहतर सहायता उपलब्ध कराई है.

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

इस अपडेट के बाद, Crashlytics यह तय कर सकता है कि ऐप्लिकेशन में इस्तेमाल की गई हर क्लास को Kotlin में लिखा गया है या नहीं. साथ ही, समस्या के हस्ताक्षर में सही फ़ाइल का नाम शामिल कर सकता है. अगर आपके ऐप्लिकेशन में यह सेटअप है, तो क्रैश की जानकारी अब सही तरीके से .kt फ़ाइलों को दी जाएगी:

• आपका ऐप्लिकेशन, 'Android Gradle 4.2.0' या इसके बाद के वर्शन का इस्तेमाल करता है.
• आपका ऐप्लिकेशन, कोड को गड़बड़ करने की सुविधा चालू करके R8 का इस्तेमाल करता है.

अब क्रैश की नई समस्याओं के हस्ताक्षर में सही फ़ाइल एक्सटेंशन शामिल होता है. इसलिए, आपको .kt वाली नई समस्याएं दिख सकती हैं. हालांकि, ये समस्याएं असल में .java लेबल वाली मौजूदा समस्याओं की डुप्लीकेट होती हैं. Firebase कंसोल में, अगर .kt की नई समस्या, .java लेबल वाली किसी मौजूदा समस्या की डुप्लीकेट है, तो हम आपको इसकी पहचान करने और आपसे संपर्क करने की कोशिश करते हैं.

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

नोट की मदद से, प्रोजेक्ट के सदस्य किसी खास समस्या के बारे में सवाल पूछ सकते हैं, स्टेटस के बारे में अपडेट दे सकते हैं वगैरह.

जब कोई प्रोजेक्ट में शामिल व्यक्ति कोई नोट पोस्ट करता है, तो उसे उसके Google खाते के ईमेल पते से लेबल किया जाता है. यह ईमेल पता, नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.

यहां नोट देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में बताया गया है:

• प्रोजेक्ट के जिन सदस्यों के पास इनमें से कोई भी भूमिका है वे मौजूदा नोट देख सकते हैं और उन्हें मिटा सकते हैं. साथ ही, किसी समस्या के बारे में नए नोट लिख सकते हैं.

  • प्रोजेक्ट मालिक या एडिटर, Firebase एडमिन, क्वालिटी एडमिन या Crashlytics का एडमिन

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

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

उन उपयोगकर्ताओं का हिसाब कैसे लगाया जाता है जिन्हें क्रैश का अनुभव नहीं हुआ?

क्रैश-फ़्री मेट्रिक को समझना लेख पढ़ें.

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

नोट की मदद से, प्रोजेक्ट के सदस्य किसी खास समस्या के बारे में सवाल पूछ सकते हैं, स्टेटस के बारे में अपडेट दे सकते हैं वगैरह.

जब कोई प्रोजेक्ट में शामिल व्यक्ति कोई नोट पोस्ट करता है, तो उसे उसके Google खाते के ईमेल पते से लेबल किया जाता है. यह ईमेल पता, नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.

यहां नोट देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में बताया गया है:

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

  • प्रोजेक्ट का मालिक या एडिटर, Firebase एडमिन, क्वालिटी एडमिन या Crashlytics एडमिन

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

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

इंटिग्रेशन

ऐप्लिकेशन में Google Mobile Ads SDK टूल का भी इस्तेमाल किया जाता है, लेकिन ऐप्लिकेशन क्रैश नहीं हो रहा

अगर आपका प्रोजेक्ट Google Mobile Ads SDK टूल के साथ-साथ Crashlytics का इस्तेमाल करता है, तो हो सकता है कि अपवाद हैंडलर को रजिस्टर करते समय, क्रैश रिपोर्टर रुकावट डाल रहे हों. इस समस्या को ठीक करने के लिए, disableSDKCrashReporting को कॉल करके Mobile Ads SDK टूल में क्रैश रिपोर्टिंग की सुविधा बंद करें.

मेरा BigQuery डेटासेट कहां मौजूद है?

Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट अपने-आप अमेरिका में सेव हो जाते हैं. भले ही, आपके Firebase प्रोजेक्ट की लोकेशन कुछ भी हो.

प्लैटफ़ॉर्म से जुड़ी सहायता

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

Firebase Crashlytics NDK, ARMv5 (armeabi) के साथ काम नहीं करता. NDK r17 से, इस एबीआई के लिए सहायता हटा दी गई है.

बेहतर होने के बजाय खराब हुई समस्याएं

पहले से मौजूद समस्या क्या है?

जब आपने पहले ही समस्या को बंद कर दिया हो, लेकिन Crashlytics को एक नई रिपोर्ट मिले कि समस्या फिर से आ गई है, तो समस्या फिर से आ गई है. Crashlytics, इन समस्याओं को अपने-आप फिर से खोलता है, ताकि आप अपने ऐप्लिकेशन के हिसाब से इनका समाधान कर सकें.

यहां उदाहरण के तौर पर एक उदाहरण दिया गया है. इसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन की कैटगरी में कैसे रखता है:

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics ने ऐप्लिकेशन के किसी वर्शन में बार-बार होने वाली समस्या को रिग्रेशन की कैटगरी में रखा था. ऐसा ऐप्लिकेशन के उन वर्शन के लिए भी किया गया था जिनके बारे में हमें पता था कि आपने समस्या को कब बंद किया था. इस वजह से, Crashlytics कभी-कभी रिग्रेशन की गलत पहचान कर पाता था. अब हम ऊपर बताए गए तरीके का इस्तेमाल करते हैं.

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

मुझे ऐप्लिकेशन के पुराने वर्शन में, पहले से मौजूद समस्याएं क्यों दिख रही हैं?

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

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

अगर आपको हमारे रेग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो उसे बंद करने के बजाय "म्यूट" करें.

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को तब रिग्रेशन के तौर पर कैटगरी में रखता था, जब वह समस्या ऐप्लिकेशन के किसी वर्शन में फिर से दिखती थी. भले ही, वह समस्या ठीक करने के बाद, हमें ऐप्लिकेशन के उन वर्शन के बारे में पता हो. इस वजह से, Crashlytics कभी-कभी गलत तरीके से रेग्रेशन की पहचान की जाती है. अब हम ऊपर बताए गए तरीके का इस्तेमाल करते हैं.

अगर आपको फ़रवरी 2022 से पहले ऐसे कई रिग्रेशन दिखते हैं जिनकी गलत पहचान की गई है, तो उन्हें फिर से बंद करें, ताकि वे फिर से न खुलें.