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

iOS+ Android फ़्लटर यूनिटी

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

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

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

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

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

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट का विश्लेषण करता है (जैसे कि क्रैश, नुकसान न पहुंचाने वाले, और ANR) के डेटा के आधार पर, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहते हैं. एक ही समस्या है.

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

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

इन सुधारों के बाद, आपको ये सुविधाएं मिलेंगी:

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

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

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

• बेहतर सूचनाएं और सिग्नल
  एक नई समस्या से असल में एक नई गड़बड़ी का पता चलता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

  खास तौर पर यह देख लें कि आप कम से कम नीचे दिए गए Google Analytics के लिए Firebase SDK टूल:
  Android — v17.2.3+ (BoM v24.7.1+).

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

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

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

अगर आपके कुछ ANRs में 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 जोड़ें.

  • देख लें कि कहीं आपने गलती से BuildId हटा तो नहीं दिया है का साइज़ कम किया जा सकता है.

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

अंतर Crashlytics डैशबोर्ड में ANR रिपोर्ट और Google Play Console

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

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

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

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

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

  -Wl,--no-rosegment
  

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

  -Wl,--rosegment
  

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

-fno-omit-frame-pointer

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

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

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

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

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

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

  Gradle प्लग इन v3.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 का इस्तेमाल करता है, तो हो सकता है कि अपवाद हैंडलर को रजिस्टर करते समय, क्रैश रिपोर्टर रुकावट डाल रहे हों. इस समस्या को ठीक करने के लिए, यहां जाकर क्रैश रिपोर्ट की सुविधा बंद करें Mobile Ads SDK टूल को ऐक्सेस करने के लिए, disableSDKCrashReporting पर कॉल करें.

मेरा 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 से पहले, उन्हें फिर से बंद किया जा सकता है, ताकि उन्हें फिर से न खोला जा सके.