इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आपने अपने Firebase प्रोजेक्ट में Google Analytics चालू किया हो.
आपने Google Analytics के लिए डेटा शेयर करने की सुविधा चालू की हो. Analytics में डेटा शेयर करने की सेटिंग मैनेज करना लेख में इस सेटिंग के बारे में ज़्यादा जानें
आपने अपने ऐप्लिकेशन में Google Analytics के लिए Firebase SDK टूल जोड़ा है जोड़ा है. Crashlytics SDK टूल के अलावा, यह SDK टूल भी जोड़ना ज़रूरी है.
आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, Firebase SDK के नए वर्शन का इस्तेमाल किया हो.

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

तेज़ गति से लेन बदलने की सूचनाएं नहीं मिल रही हैं

अगर आपको वेलोसिटी अलर्ट नहीं दिख रहे हैं, तो पक्का करें कि आपने इनका इस्तेमाल किया हो: Crashlytics SDK v18.6.0+ (या Firebase BoM v32.6.0+).

क्रैश से जुड़ी मेट्रिक न दिखना या गलत मेट्रिक दिखना

अगर आपको क्रैश-फ़्री मेट्रिक (जैसे कि क्रैश-फ़्री उपयोगकर्ता और सेशन) नहीं दिख रही हैं या आपको ऐसी मेट्रिक दिख रही हैं जिन पर भरोसा नहीं किया जा सकता, तो यहां दी गई जानकारी देखें:

पक्का करें कि आपने इन SDK टूल का इस्तेमाल किया हो: Crashlytics SDK v18.6.0+ (या Firebase BoM v32.6.0+).
पक्का करें कि डेटा कलेक्शन की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:
- अगर आपने क्रैश की जानकारी अपने-आप रिपोर्ट होने की सुविधा बंद करके, ऑप्ट-इन रिपोर्टिंग की सुविधा चालू की है, तो क्रैश की जानकारी सिर्फ़ उन उपयोगकर्ताओं से Crashlytics को भेजी जा सकती है जिन्होंने डेटा इकट्ठा करने की सुविधा के लिए ऑप्ट-इन किया है. इसलिए, क्रैश न होने की मेट्रिक की सटीक जानकारी पर असर पड़ेगा, क्योंकि Crashlytics के पास सिर्फ़ उन उपयोगकर्ताओं की क्रैश से जुड़ी जानकारी होती है जिन्होंने ऑप्ट-इन किया है. हालांकि, आपके पास सभी उपयोगकर्ताओं की जानकारी होती है. इसका मतलब है कि क्रैश-फ़्री मेट्रिक कम भरोसेमंद हो सकती हैं. साथ ही, इससे आपके ऐप्लिकेशन की स्थिरता के बारे में पूरी जानकारी नहीं मिल सकती.
- अगर आपने डेटा अपने-आप इकट्ठा होने की सुविधा बंद की है, तो डिवाइस पर कैश मेमोरी में सेव की गई रिपोर्ट को Crashlytics पर भेजने के लिए, sendUnsentReports का इस्तेमाल किया जा सकता है. इस तरीके का इस्तेमाल करने पर, Crashlytics को क्रैश का डेटा भेजा जाएगा. हालांकि, सेशन का डेटा नहीं भेजा जाएगा. इस वजह से, कंसोल चार्ट में क्रैश-फ़्री मेट्रिक के लिए कम या शून्य वैल्यू दिखती हैं.

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

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

Android 11 और इसके बाद के वर्शन पर चलने वाले डिवाइसों के लिए ही एएनआर की रिपोर्ट क्यों की जाती है?

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

कुछ एएनआर में `BuildId` क्यों नहीं दिखते?

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

पक्का करें कि Crashlytics Android SDK और Crashlytics Gradle प्लगिन के सबसे नए वर्शन का इस्तेमाल किया जा रहा हो.

अगर आपको Android 11 और Android 12 के कुछ एएनआर के लिए BuildId नहीं दिख रहे हैं, तो हो सकता है कि आप SDK टूल और Gradle प्लग इन के पुराने वर्शन का इस्तेमाल कर रहे हों. इन एएनआर के लिए BuildId को सही तरीके से इकट्ठा करने के लिए, आपको इन वर्शन का इस्तेमाल करना होगा:
- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Crashlytics Gradle प्लगिन v2.9.4 या इसके बाद का वर्शन
देखें कि शेयर की गई लाइब्रेरी के लिए, किसी गैर-मानक जगह का इस्तेमाल तो नहीं किया जा रहा है.

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

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

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

Google Play और Crashlytics के बीच, एएनआर की संख्या में अंतर हो सकता है. ऐसा इसलिए होता है, क्योंकि ANR डेटा को इकट्ठा करने और रिपोर्ट करने के तरीके अलग-अलग होते हैं. Crashlytics ऐप्लिकेशन के अगली बार शुरू होने पर, ANR की रिपोर्ट करता है. वहीं, Android की ज़रूरी जानकारी, 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 एक्सटेंशन प्रॉपर्टी का इस्तेमाल करें.

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

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

अपने ऐप्लिकेशन-लेवल की 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

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

पक्का करें कि DexGuard 8.x का नया वर्शन इस्तेमाल किया जा रहा हो. नए वर्शन में ऐसे नियम शामिल हैं जिनकी ज़रूरत Firebase Crashlytics SDK टूल को होती है.
अगर आपको 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 समस्याएं दिख सकती हैं. हालांकि, ये समस्याएं असल में .kt के तौर पर लेबल की गई मौजूदा समस्याओं की डुप्लीकेट होती हैं..java Firebase कंसोल में, हम यह पता लगाने की कोशिश करते हैं कि क्या कोई नई .kt समस्या, .java के तौर पर लेबल की गई किसी मौजूदा समस्या की डुप्लीकेट है. अगर ऐसा होता है, तो हम आपको इसकी सूचना देते हैं.

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

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

जब प्रोजेक्ट का कोई सदस्य कोई नोट पोस्ट करता है, तो उसे उसके 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 किसी समस्या को रिग्रेशन के तौर पर कैसे कैटगरी में रखता है:

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

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

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

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

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

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

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

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

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