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 टूल जोड़ा है . इस 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 रिपोर्टिंग की सुविधा देता है. एएनआर इकट्ठा करने के लिए इस्तेमाल किया जाने वाला एपीआई (getHistoricalProcessExitReasons), 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 टूल v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle प्लग इन का 2.9.4 या इसके बाद का वर्शन

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

  अगर आपको अपने ऐप्लिकेशन की शेयर की गई लाइब्रेरी के लिए सिर्फ़ BuildIds नहीं दिख रहे हैं, तो हो सकता है कि आप शेयर की गई लाइब्रेरी के लिए स्टैंडर्ड, डिफ़ॉल्ट जगह का इस्तेमाल न कर रहे हों. अगर ऐसा है, तो हो सकता है कि 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 Vitals, 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

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

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

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

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

• पहला विकल्प: अपनी 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
   

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

जब कोई ऐप्लिकेशन, फ़ाइल एक्सटेंशन को न दिखाने वाले ऑब्फ़स्क्यूफ़ायर का इस्तेमाल करता है, तो 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 से पहले के कई ऐसे रेग्रेशन दिखते हैं जिन्हें गलत तरीके से पहचाना गया है, तो उन्हें फिर से बंद किया जा सकता है, ताकि वे फिर से न खुलें.