इस पेज पर, समस्या हल करने से जुड़ी सहायता और Crashlytics इस्तेमाल करने के बारे में अक्सर पूछे जाने वाले सवालों के जवाब दिए गए हैं. अगर आपको जो जानकारी चाहिए वह नहीं मिल रही या कोई और मदद चाहिए, तो Firebase की सहायता टीम से संपर्क करें.
सामान्य समस्याएं हल करना/अक्सर पूछे जाने वाले सवाल
समस्याएं टेबल में कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट (और कभी-कभी "वैरिएंट") देखना
आपको Firebase कंसोल में, समस्याएं टेबल में दी गई समस्याओं के लिए दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. आपको अपनी कुछ समस्याओं में "वैरिएंट" नाम की सुविधा भी दिख सकती है. इसकी वजह यह है!
साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए, बेहतर विश्लेषण इंजन लॉन्च किया था. साथ ही, हमने इसका अपडेट किया गया डिज़ाइन और नई समस्याओं (जैसे, वैरिएंट!) के लिए कुछ ऐडवांस सुविधाएं भी लॉन्च की थीं. पूरी जानकारी के लिए, हमारी हाल की ब्लॉग पोस्ट देखें. हालांकि, यहां दी गई हाइलाइट के बारे में पढ़ें.
Crashlytics, आपके ऐप्लिकेशन के सभी इवेंट का विश्लेषण करता है. जैसे, क्रैश, नुकसान न पहुंचाने वाली समस्याएं, और ANR वाली गड़बड़ियां. साथ ही, यह समस्याएं नाम के इवेंट के ग्रुप बनाता है. किसी समस्या में सभी इवेंट एक ही वजह से फ़ेल हो जाते हैं.
इवेंट को इन समस्याओं के हिसाब से ग्रुप करने के लिए, बेहतर विश्लेषण इंजन अब इवेंट के कई पहलुओं पर ध्यान देता है. इनमें स्टैक ट्रेस में फ़्रेम, अपवाद मैसेज, गड़बड़ी कोड, और दूसरे प्लैटफ़ॉर्म या गड़बड़ी के टाइप से जुड़ी विशेषताएं शामिल हैं.
हालांकि, इवेंट के इस ग्रुप में, गड़बड़ी की वजह बनने वाले स्टैक ट्रेस अलग हो सकते हैं. अगर स्टैक ट्रेस अलग है, तो इसकी अलग वजह हो सकती है. किसी समस्या में इस संभावित अंतर को दिखाने के लिए, अब हम समस्याओं में वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या में इवेंट का एक सब-ग्रुप होता है, जिसमें फ़ेलियर पॉइंट और एक जैसा स्टैक ट्रेस होता है. वैरिएंट की मदद से, किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि क्या अलग-अलग मुख्य वजहों से गड़बड़ी हो रही है.
इन सुधारों से आपको मिलने वाले फ़ायदों के बारे में यहां बताया गया है:
समस्या वाली लाइन में बेहतर मेटाडेटा दिखाया गया है
अब आपके ऐप्लिकेशन में होने वाली समस्याओं को समझना और उन्हें प्राथमिकता के हिसाब से निपटाना आसान हो गया है.डुप्लीकेट समस्याएं कम होंगी
लाइन नंबर बदलने पर, नई समस्या नहीं आती.अलग-अलग मूल वजहों से, जटिल समस्याओं को आसानी से डीबग करने की सुविधा
किसी समस्या में मौजूद सबसे आम स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करना.ज़्यादा काम की सूचनाएं और सिग्नल
एक नई समस्या, असल में एक नई गड़बड़ी दिखाती है.ज़्यादा असरदार खोज
हर समस्या में ऐसा मेटाडेटा होता है जिसे खोजा जा सके, जैसे कि अपवाद का टाइप और पैकेज का नाम.
इन सुधारों के रोल आउट होने का तरीका यहां बताया गया है:
आपके ऐप्लिकेशन से नए इवेंट मिलने पर, हम जांच करेंगे कि वे किसी मौजूदा समस्या से मेल खाते हैं या नहीं.
अगर कोई मैच नहीं होता है, तो हम अपने बेहतर इवेंट-ग्रुपिंग एल्गोरिदम को अपने-आप इवेंट पर लागू कर देंगे. इसके बाद, नए मेटाडेटा डिज़ाइन के साथ नई समस्या शुरू कर दी जाएगी.
यह पहला बड़ा अपडेट है, जिसे हम अपने इवेंट के ग्रुप में लागू कर रहे हैं. अगर आपको कोई सुझाव/राय देनी है या शिकायत करनी है या कोई समस्या आती है, तो कृपया शिकायत दर्ज करके हमें बताएं.
क्रैश-फ़्री मेट्रिक और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं
अगर आपको क्रैश-फ़्री मेट्रिक (जैसे, बिना क्रैश वाले उपयोगकर्ता और सेशन) और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं, तो पक्का करें कि Crashlytics SDK v18.6.0+ (या Firebase BoM v32.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 और इसके बाद के वर्शन वाले डिवाइसों के लिए क्यों रिपोर्ट की जाती हैं?
Crashlytics, Android 11 और उसके बाद के वर्शन वाले डिवाइसों पर, Android ऐप्लिकेशन के लिए ANR रिपोर्टिंग की सुविधा देता है. हम ANR को इकट्ठा करने के लिए जिस एपीआई का इस्तेमाल करते हैं (get प्रतिशतप्रोसेस बाहर निकलने की वजह), SIGQUIT या वॉचडॉग पर आधारित तरीकों के मुकाबले ज़्यादा भरोसेमंद है. यह एपीआई सिर्फ़ Android 11 और इसके बाद के वर्शन वाले डिवाइसों पर उपलब्ध है.
कुछ ANR में, BuildId
मौजूद क्यों नहीं हैं?
अगर आपके कुछ ANRs में BuildId
मौजूद नहीं हैं, तो इस तरीके से समस्या हल करें:
पक्का करें कि Crashlytics Android SDK और Crashlytics Gradle प्लग इन का नया वर्शन इस्तेमाल किया जा रहा है.
अगर Android 11 और Android 12 के कुछ ANRs के लिए
BuildId
मौजूद नहीं हैं, तो हो सकता है कि आपने पुराने SDK टूल, Gradle प्लग इन या दोनों का इस्तेमाल किया हो. इन एएनआर के लिएBuildId
सही तरीके से इकट्ठा करने के लिए, आपको नीचे दिए गए वर्शन इस्तेमाल करने होंगे:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Crashlytics Gradle प्लग इन v2.9.4+
देखें कि शेयर की गई लाइब्रेरी के लिए किसी नॉन-स्टैंडर्ड जगह की जानकारी का इस्तेमाल तो नहीं किया जा रहा है.
अगर आपके ऐप्लिकेशन की शेयर की गई लाइब्रेरी में सिर्फ़
BuildId
मौजूद नहीं हैं, तो हो सकता है कि आप शेयर की गई लाइब्रेरी के लिए, स्टैंडर्ड और डिफ़ॉल्ट जगह की जानकारी का इस्तेमाल न कर रहे हों. अगर ऐसा है, तो हो सकता है कि Crashlytics, जुड़े हुएBuildId
का पता न लगा पाए. हमारा सुझाव है कि आप शेयर की गई लाइब्रेरी के लिए, स्टैंडर्ड जगह की जानकारी का इस्तेमाल करें.पक्का करें कि बिल्ड प्रोसेस के दौरान आप
BuildId
न निकाल रहे हों.ध्यान दें कि समस्या हल करने के ये सुझाव, ANR और नेटिव क्रैश, दोनों पर लागू होते हैं.
अपनी बाइनरी पर
readelf -n
चलाकर देखें किBuildId
मौजूद हैं या नहीं. अगरBuildId
मौजूद नहीं हैं, तो अपने बिल्ड सिस्टम के फ़्लैग में-Wl,--build-id
जोड़ें.देख लें कि आपने APK का साइज़ कम करने के लिए, अनजाने में
BuildId
का साइज़ कम न कर दिया हो.अगर किसी लाइब्रेरी के स्ट्रिप और ड्राप्ड वर्शन रखे जाते हैं, तो पक्का करें कि आपको अपने कोड में सही वर्शन पर ले जाना हो.
Crashlytics के डैशबोर्ड और Google Play Console में ANR रिपोर्ट के बीच अंतर
ऐसा हो सकता है कि Google Play और Crashlytics के बीच ANR की संख्या में अंतर हो. ऐसा ANR डेटा इकट्ठा करने और उसे रिपोर्ट करने के तरीके में अंतर की वजह से होना चाहिए. जब ऐप्लिकेशन अगली बार शुरू होता है, तब Crashlytics, ANR की गड़बड़ियों की रिपोर्ट करता है. वहीं, Android की ज़रूरी जानकारी, ANR की गड़बड़ी होने के बाद ANR का डेटा भेजती है.
इसके अलावा, Crashlytics, ऐप्लिकेशन से सिर्फ़ Android 11 या इसके बाद के वर्शन वाले डिवाइसों पर हुए एएनआर की जानकारी दिखाता है. इन ANR की गड़बड़ियों की जानकारी, Google Play से उन डिवाइसों से मिले एएनआर के बारे में दिखती है जिन पर Google Play services और डेटा कलेक्शन के लिए, सहमति से जुड़ी सहमति को स्वीकार किया गया है.
Crashlytics डैशबोर्ड और Logcat में एनडीके स्टैक ट्रेस के बीच अंतर
एलएलवीएम और GNU टूलचेन में, आपके ऐप्लिकेशन की बाइनरी के रीड-ओनली सेगमेंट के लिए अलग-अलग डिफ़ॉल्ट तरीके और ट्रीटमेंट होते हैं. इससे Firebase कंसोल में, एक जैसा स्टैक ट्रेस जनरेट हो सकते हैं. इसे कम करने के लिए, अपनी बिल्ड प्रोसेस में नीचे दिए गए लिंकर फ़्लैग जोड़ें:
अगर एलएलवीएम टूलचेन से
lld
लिंकर का इस्तेमाल किया जा रहा है, तो यह जोड़ें:-Wl,--no-rosegment
अगर GNU टूलचेन से
ld.gold
लिंकर का इस्तेमाल किया जा रहा है, तो यह जोड़ें:-Wl,--rosegment
अगर आपको अब भी स्टैक ट्रेस में अंतर दिख रहा है (या अगर आपके टूलचेन के लिए कोई भी फ़्लैग ज़रूरी नहीं है), तो बिल्ड प्रोसेस में इन्हें जोड़ने के बजाय:
-fno-omit-frame-pointer
मैं एनडीके के लिए अपने ब्रेकपैड सिंबल की फ़ाइल जनरेटर बाइनरी का इस्तेमाल कैसे करूं?
Crashlytics प्लगिन की मदद से पसंद के मुताबिक बनाया गया ब्रेकपैड सिंबल फ़ाइल जनरेटर बंडल किया जाता है.
अगर आपको ब्रेकपैड सिंबल वाली फ़ाइलें जनरेट करने के लिए अपनी बाइनरी का इस्तेमाल करना है (उदाहरण के लिए, अगर आपको सोर्स से अपनी बिल्ड चेन में सभी नेटिव एक्ज़ीक्यूटेबल फ़ाइल बनाना है), तो वैकल्पिक symbolGeneratorBinary
एक्सटेंशन प्रॉपर्टी का इस्तेमाल करके एक्ज़ीक्यूटेबल फ़ाइल का पाथ तय करें.
ब्रेकपैड सिंबल फ़ाइल जनरेटर बाइनरी का पाथ, इन दो में से किसी एक तरीके से तय किया जा सकता है:
पहला विकल्प: अपनी
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
की ऐसी नई समस्याएं दिख सकती हैं जो .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, आर्मीबी के साथ काम करता है?
Firebase Crashlytics NDK, ARMv5 (armeabi) के साथ काम नहीं करता. NDK r17 के बाद, इस एबीआई की सुविधा हटा दी गई थी.
ऐसी समस्याएं जिनका समाधान नहीं हुआ है
रिग्रेशन की समस्या क्या है?
जब आपने पहले समस्या को बंद कर दिया था, तब उसमें एक समस्या का रिग्रेशन हुआ हो. हालांकि, Crashlytics को एक नई रिपोर्ट मिलती है कि यह समस्या फिर से आई है. Crashlytics, वापस आने वाली इन समस्याओं को अपने-आप दोबारा खोलता है, ताकि आप अपने ऐप्लिकेशन के हिसाब से उन्हें ठीक कर सकें.
यहां उदाहरण के तौर पर एक उदाहरण दिया गया है. इसमें बताया गया है कि Crashlytics, किसी समस्या को रिग्रेशन की कैटगरी में कैसे बांटता है:
- पहली बार, Crashlytics को क्रैश "A" के बारे में क्रैश रिपोर्ट मिली है. Crashlytics से, क्रैश से जुड़ी समस्या (समस्या "A") खुलती है.
- इस गड़बड़ी को तुरंत ठीक किया जाता है, समस्या "A" को बंद किया जाता है, और अपने ऐप्लिकेशन का नया वर्शन रिलीज़ किया जाता है.
- जब आप समस्या को बंद कर देते हैं, तो Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है.
- अगर रिपोर्ट किसी ऐप्लिकेशन के ऐसे वर्शन की है जिसके बारे में Crashlytics को किसी समस्या को ठीक करने के बारे में जानकारी है (यानी कि वर्शन ने किसी भी क्रैश के लिए, क्रैश रिपोर्ट भेजी थी, तो Crashlytics, समस्या को वापस आने वाली समस्या नहीं मानेगा. समस्या बंद रहेगी.
- अगर रिपोर्ट किसी ऐप्लिकेशन के ऐसे वर्शन की है जिसके बारे में Crashlytics को समस्या बंद करने के बारे में नहीं पता है (यानी कि वर्शन ने किसी भी क्रैश के लिए कभी भी कोई क्रैश रिपोर्ट नहीं भेजी है), तो Crashlytics, समस्या के ठीक होने के बारे में मानेगा और समस्या को दोबारा शुरू कर देगा.
जब किसी समस्या के वापस आने पर, हम उसे रिग्रेशन की चेतावनी भेजते हैं और समस्या के साथ एक रिग्रेशन सिग्नल जोड़ते हैं. इससे आपको पता चलता है कि Crashlytics ने समस्या को फिर से खोल दिया है. अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो समस्या को बंद करने के बजाय "म्यूट करें" विकल्प चुनें.
मुझे ऐप्लिकेशन के पुराने वर्शन के लिए, वापस आने वाली समस्याएं क्यों दिख रही हैं?
अगर कोई रिपोर्ट ऐप्लिकेशन के किसी पुराने वर्शन की है, जिसने समस्या को बंद करने के समय कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics, समस्या के ठीक होने के बारे में मानेगा और समस्या को फिर से खोलेगा.
ऐसा नीचे दी गई स्थिति में हो सकता है: आपने कोई गड़बड़ी ठीक की है और अपने ऐप्लिकेशन का नया वर्शन रिलीज़ किया है, लेकिन उपयोगकर्ता अब भी बिना गड़बड़ी के पुराने वर्शन का इस्तेमाल कर रहे हैं. अगर समस्या की वजह से, उन क्रैश रिपोर्ट में से किसी एक ने समस्या को बंद किए जाने के बाद भी कभी भी कोई क्रैश रिपोर्ट नहीं भेजी और उन उपयोगकर्ताओं को गड़बड़ी मिली, तो फिर उन क्रैश रिपोर्ट से वापस आने वाली समस्या ट्रिगर होगी.
अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से, किसी समस्या के बारे में फिर से जानकारी नहीं देनी है, तो समस्या को बंद करने के बजाय "म्यूट करें" विकल्प चुनें.