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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• आपने अपने ऐप्लिकेशन में, Google Analytics के लिए Firebase SDK टूल जोड़ा हो: iOS+ | Android | Flutter | Unity.
  इस एसडीके को Crashlytics एसडीके के अलावा जोड़ना होगा.

• आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, Firebase SDK टूल के सबसे नए वर्शन इस्तेमाल किए हों (iOS+ | Android | Flutter | Unity).

  खास तौर पर, Apple प्लैटफ़ॉर्म और Android ऐप्लिकेशन के लिए, पक्का करें कि Google Analytics के लिए Firebase SDK टूल के कम से कम इस वर्शन का इस्तेमाल किया जा रहा हो: iOS+ — v6.3.1+ (macOS और tvOS के लिए v8.9.0+) | Android — v17.2.3+ (BoM v24.7.1+).

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

अगर आपको वेलोसिटी अलर्ट नहीं दिख रही हैं, तो पक्का करें कि आपने इन वर्शन का इस्तेमाल किया हो:

क्रैश-फ़्री मेट्रिक नहीं दिख रही हैं या भरोसेमंद मेट्रिक नहीं दिख रही हैं

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

• पक्का करें किका इस्तेमाल किया जा रहा हो.

• पक्का करें कि डेटा कलेक्शन की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:

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

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

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

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

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

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

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

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

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

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

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

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

रिग्रेशन की समस्या क्या होती है?

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

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

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

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

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

---

प्लैटफ़ॉर्म के हिसाब से सहायता

यहां दिए गए सेक्शन में, प्लैटफ़ॉर्म के हिसाब से समस्या हल करने के तरीके और अक्सर पूछे जाने वाले सवालों के बारे में बताया गया है: iOS+ | Android | Unity.

Apple के प्लैटफ़ॉर्म पर काम करता है

dSYM फ़ाइलें मौजूद नहीं हैं/अपलोड नहीं हो रही हैं

अपने प्रोजेक्ट के dSYM अपलोड करने और ज़्यादा जानकारी वाला आउटपुट पाने के लिए, यह देखें:

1. पक्का करें कि आपके प्रोजेक्ट के बिल्ड फ़ेज़ में Crashlytics रन स्क्रिप्ट शामिल हो. इससे Xcode को बिल्ड के समय आपके प्रोजेक्ट के dSYM अपलोड करने की अनुमति मिलती है. स्क्रिप्ट जोड़ने के निर्देशों के लिए, Crashlytics को चालू करना लेख पढ़ें. अपने प्रोजेक्ट को अपडेट करने के बाद, क्रैश को फ़ोर्स करें और पुष्टि करें कि क्रैश, Crashlytics डैशबोर्ड में दिखता है.

2. अगर आपको Firebase कंसोल में "डीएसवाईएम मौजूद नहीं है" सूचना दिखती है, तो Xcode में जाकर देखें कि बिल्ड के लिए डीएसवाईएम सही तरीके से जनरेट हो रहे हैं या नहीं.

3. अगर Xcode, dSYM फ़ाइलें सही तरीके से बना रहा है और आपको अब भी dSYM फ़ाइलें नहीं दिख रही हैं, तो हो सकता है कि रन स्क्रिप्ट टूल, dSYM फ़ाइलों को अपलोड करते समय अटक गया हो. ऐसे में, इनमें से हर एक को आज़माएं:

   • पक्का करें कि आपके डिवाइस में Crashlytics का नया वर्शन इंस्टॉल हो.

   • छूटी हुई dSYM फ़ाइलों को मैन्युअल तरीके से अपलोड करें:

     • पहला विकल्प: कंसोल में मौजूद "खींचें और छोड़ें" विकल्प का इस्तेमाल करें. इसके लिए, dSYMs टैब में जाएं. इस विकल्प का इस्तेमाल करके, dSYM फ़ाइलों वाला ज़िप संग्रह अपलोड करें.
     • दूसरा विकल्प: dSYMs टैब में दिए गए यूयूआईडी के लिए, upload-symbols स्क्रिप्ट का इस्तेमाल करके, dSYM फ़ाइलें अपलोड करें.

4. अगर आपको अब भी dSYM फ़ाइलें नहीं दिख रही हैं या अपलोड नहीं हो रही हैं, तो Firebase की सहायता टीम से संपर्क करें. साथ ही, अपने लॉग शामिल करना न भूलें.

क्रैश को ठीक से सिंबोलाइज़ नहीं किया गया है

अगर आपकी स्टैक ट्रेस ठीक से सिम्बॉलिकेट नहीं की गई हैं, तो यहां दी गई बातें देखें:

• अगर आपके ऐप्लिकेशन की लाइब्रेरी के फ़्रेम में, आपके ऐप्लिकेशन के कोड के रेफ़रंस नहीं हैं, तो पक्का करें कि -fomit-frame-pointer को कंपाइलेशन फ़्लैग के तौर पर सेट न किया गया हो.

• अगर आपको अपने ऐप्लिकेशन की लाइब्रेरी के लिए कई (Missing) फ़्रेम दिखते हैं, तो देखें कि क्या Firebase कंसोल के Crashlytics dSYM टैब में, प्रभावित ऐप्लिकेशन वर्शन के लिए कुछ वैकल्पिक dSYM, 'मौजूद नहीं हैं' के तौर पर सूची में शामिल हैं. अगर ऐसा है, तो इस पेज पर dSYM फ़ाइलें मौजूद नहीं हैं/अपलोड नहीं हो रही हैं के बारे में अक्सर पूछे जाने वाले सवालों में, "dSYM फ़ाइल मौजूद नहीं है" वाली समस्या हल करने का तरीका अपनाएं. ध्यान दें कि इन dSYM को अपलोड करने से, पहले हो चुके क्रैश के सिंबल नहीं दिखेंगे. हालांकि, इससे आने वाले समय में होने वाले क्रैश के सिंबल दिखेंगे.

क्या macOS या tvOS के लिए, Crashlytics का इस्तेमाल किया जा सकता है?

हां, macOS और tvOS प्रोजेक्ट में Crashlytics को लागू किया जा सकता है. पक्का करें कि आपने Google Analytics के लिए Firebase SDK का v8.9.0 या इसके बाद का वर्शन शामिल किया हो, ताकि क्रैश को Google Analytics से इकट्ठा की गई मेट्रिक का ऐक्सेस मिल सके. जैसे, क्रैश न होने वाले उपयोगकर्ताओं की संख्या, नया वर्शन, वेलोसिटी अलर्ट, और ब्रेडक्रंब लॉग.

क्या अलग-अलग Apple प्लैटफ़ॉर्म पर मौजूद कई ऐप्लिकेशन वाले Firebase प्रोजेक्ट में Crashlytics का इस्तेमाल किया जा सकता है?

अब एक ही Firebase प्रोजेक्ट में, कई ऐप्लिकेशन के क्रैश की रिपोर्ट की जा सकती है. ऐसा तब भी किया जा सकता है, जब ऐप्लिकेशन अलग-अलग Apple प्लैटफ़ॉर्म (जैसे कि iOS, tvOS, और Mac Catalyst) के लिए बनाए गए हों. पहले, अगर ऐप्लिकेशन में एक ही बंडल आईडी होता था, तो आपको उन्हें अलग-अलग Firebase प्रोजेक्ट में रखना होता था.

---

Android सहायता

ANR की गड़बड़ियों की रिपोर्ट सिर्फ़ 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 या इसके बाद का वर्शन

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

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

मुझे .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 के तौर पर लेबल की गई किसी मौजूदा समस्या की डुप्लीकेट है. अगर ऐसा होता है, तो हम आपको इसकी सूचना देते हैं.

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

Android-NDK से जुड़ी खास सहायता

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 प्लगिन 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
  

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

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

---

Unity के साथ काम करने की सुविधा

Crashlytics डैशबोर्ड में, Android ऐप्लिकेशन के लिए बिना सिंबल वाले स्टैक ट्रेस दिख रहे हैं

अगर Unity IL2CPP का इस्तेमाल किया जा रहा है और आपको स्टैक ट्रेस में सिंबल नहीं दिख रहे हैं, तो यह तरीका आज़माएं:

1. पक्का करें कि आपके पास Crashlytics Unity SDK का v8.6.1 या इसके बाद का वर्शन हो.

2. पक्का करें कि आपने Firebase CLI crashlytics:symbols:upload कमांड सेट अप की हो और उसका इस्तेमाल किया जा रहा हो, ताकि सिंबल फ़ाइल जनरेट और अपलोड की जा सके.

   आपको इस सीएलआई कमांड को हर बार तब चलाना होगा, जब आपको कोई रिलीज़ बिल्ड या ऐसा बिल्ड बनाना हो जिसके लिए आपको Firebase कंसोल में सिंबोलाइज्ड स्टैक ट्रेस देखने हों. पढ़ने में आसान क्रैश रिपोर्ट पाना लेख में इसके बारे में ज़्यादा जानें.

क्या Crashlytics का इस्तेमाल, IL2CPP का इस्तेमाल करने वाले ऐप्लिकेशन के साथ किया जा सकता है?

हां, Crashlytics, IL2CPP का इस्तेमाल करने वाले आपके ऐप्लिकेशन के लिए, सिंबोलाइज्ड स्टैक ट्रेस दिखा सकता है. यह सुविधा, Android या Apple प्लैटफ़ॉर्म पर रिलीज़ किए गए ऐप्लिकेशन के लिए उपलब्ध है. इसके लिए, आपको यह तरीका अपनाना होगा:

1. पक्का करें कि आपके पास Crashlytics Unity SDK का v8.6.0 या इसके बाद का वर्शन हो.

2. अपने प्लैटफ़ॉर्म के लिए ज़रूरी टास्क पूरे करें:

   • Apple प्लैटफ़ॉर्म के ऐप्लिकेशन के लिए: कोई खास कार्रवाई करने की ज़रूरत नहीं है. Apple प्लैटफ़ॉर्म वाले ऐप्लिकेशन के लिए, Firebase Unity Editor प्लगिन, सिंबल अपलोड करने के लिए आपके Xcode प्रोजेक्ट को अपने-आप कॉन्फ़िगर करता है.

   • Android ऐप्लिकेशन के लिए: पक्का करें कि आपने सिंबल फ़ाइल जनरेट और अपलोड करने के लिए, Firebase CLI crashlytics:symbols:upload कमांड सेट अप की हो और वह काम कर रही हो.

     आपको इस सीएलआई कमांड को हर बार तब चलाना होगा, जब आपको कोई रिलीज़ बिल्ड या ऐसा बिल्ड बनाना हो जिसके लिए आपको Firebase कंसोल में सिंबोलाइज्ड स्टैक ट्रेस देखने हों. पढ़ने में आसान क्रैश रिपोर्ट पाना लेख में इसके बारे में ज़्यादा जानें.

पहचानी और मैनेज नहीं की गई गड़बड़ियों को गंभीर गड़बड़ियों के तौर पर रिपोर्ट करना

Crashlytics, बिना हैंडल किए गए अपवादों को फ़ैटल के तौर पर रिपोर्ट कर सकता है. यह सुविधा, Unity SDK के v10.4.0 से शुरू होती है. यहां दिए गए अक्सर पूछे जाने वाले सवालों से, इस सुविधा को इस्तेमाल करने के पीछे की वजह और सबसे सही तरीकों के बारे में जानने में मदद मिलती है.

किसी ऐप्लिकेशन को, बिना हैंडल किए गए अपवादों की रिपोर्ट, गंभीर गड़बड़ियों के तौर पर क्यों करनी चाहिए?

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

ध्यान दें कि गंभीर समस्याओं की रिपोर्टिंग शुरू करने पर, बिना क्रैश हुए ऐप्लिकेशन इस्तेमाल करने वाले उपयोगकर्ताओं (सीएफ़यू) का प्रतिशत कम हो सकता है. हालांकि, सीएफ़यू मेट्रिक से, ऐप्लिकेशन इस्तेमाल करने वाले उपयोगकर्ताओं के अनुभव के बारे में ज़्यादा जानकारी मिलेगी.

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

किन अपवादों को गंभीर गड़बड़ियों के तौर पर रिपोर्ट किया जाएगा?

Crashlytics को किसी ऐसे अपवाद की सूचना देनी चाहिए जिसे हैंडल नहीं किया गया है. इसके लिए, ये दोनों शर्तें पूरी होनी चाहिए:

• आपके ऐप्लिकेशन में शुरू होने के दौरान, ReportUncaughtExceptionsAsFatal प्रॉपर्टी को true पर सेट किया जाना चाहिए.

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

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

जब आपको ऐसे अपवादों की रिपोर्ट मिलने लगें जिन्हें हैंडल नहीं किया गया है और वे गंभीर अपवादों के तौर पर दिख रहे हैं, तो यहां दिए गए विकल्पों का इस्तेमाल करके, इन अपवादों को हैंडल किया जा सकता है:

• सोचें कि इन अनकैच किए गए अपवादों को कैसे पकड़ा और हैंडल किया जा सकता है.
• Unity के डीबग कंसोल और Crashlytics में अपवादों को लॉग करने के लिए, अलग-अलग विकल्पों पर विचार करें.

थ्रो किए गए अपवादों को कैच करना और उन्हें हैंडल करना

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

हमारा सुझाव है कि अनुमानित सभी अपवादों को पकड़ा जाए और उन्हें हैंडल किया जाए. हालांकि, ऐसा तब तक किया जाना चाहिए, जब तक प्रोग्राम को जानी-पहचानी स्थिति में वापस नहीं लाया जा सकता.

यह कंट्रोल करने के लिए कि किस तरह के अपवादों को किस कोड से पकड़ा और हैंडल किया जाता है, अपवाद जनरेट करने वाले कोड को try-catch ब्लॉक में रैप करें. पक्का करें कि catch स्टेटमेंट में दी गई शर्तें, खास अपवादों को सही तरीके से हैंडल करने के लिए ज़्यादा से ज़्यादा सीमित हों.

Unity या Crashlytics में अपवादों को लॉग करना

समस्या को डीबग करने के लिए, Unity या Crashlytics में अपवादों को रिकॉर्ड करने के कई तरीके हैं.

Crashlytics का इस्तेमाल करते समय, यहां दो सबसे सामान्य और सुझाए गए विकल्प दिए गए हैं:

• पहला विकल्प: डेवलपमेंट या समस्या हल करने के दौरान, Unity कंसोल में प्रिंट करें, लेकिन Crashlytics को रिपोर्ट न करें

  • Debug.Log(exception), Debug.LogWarning(exception), और Debug.LogError(exception) का इस्तेमाल करके, Unity कंसोल में प्रिंट करें. ये तीनों, अपवाद के कॉन्टेंट को Unity कंसोल में प्रिंट करते हैं और अपवाद को फिर से नहीं फेंकते.

• दूसरा विकल्प: इन स्थितियों में, Crashlytics डैशबोर्ड में एक साथ रिपोर्टिंग के लिए, Crashlytics पर अपलोड करें:

  • अगर किसी अपवाद को लॉग करना ज़रूरी है, ताकि बाद के Crashlytics इवेंट को डीबग किया जा सके, तो Crashlytics.Log(exception.ToString()) का इस्तेमाल करें.
  • अगर किसी अपवाद को पकड़े जाने और हैंडल किए जाने के बावजूद, Crashlytics को रिपोर्ट किया जाना चाहिए, तो इसे नॉनफ़ैटल इवेंट के तौर पर लॉग करने के लिए Crashlytics.LogException(exception) का इस्तेमाल करें.

हालांकि, अगर आपको किसी गंभीर इवेंट की रिपोर्ट Unity Cloud Diagnostics को मैन्युअल तरीके से भेजनी है, तो Debug.LogException का इस्तेमाल किया जा सकता है. यह विकल्प, पहले विकल्प की तरह Unity कंसोल में अपवाद प्रिंट करता है. हालांकि, यह अपवाद भी दिखाता है (चाहे इसे पहले दिखाया गया हो या नहीं). यह गड़बड़ी को नॉनलोकल तरीके से दिखाता है. इसका मतलब है कि try-catch ब्लॉक के साथ Debug.LogException(exception) का इस्तेमाल करने पर भी, अनकैच किए गए अपवाद का सामना करना पड़ता है.

इसलिए, Debug.LogException को सिर्फ़ तब कॉल करें, जब आपको यहां दी गई सभी कार्रवाइयां करनी हों:

• इस फ़ंक्शन का इस्तेमाल, Unity कंसोल में अपवाद को प्रिंट करने के लिए किया जाता है.
• अपवाद को Crashlytics में गंभीर इवेंट के तौर पर अपलोड करना.
• अपवाद को थ्रो करने के लिए, इसे अनकैच अपवाद के तौर पर माना जाता है. साथ ही, इसे Unity Cloud Diagnostics को रिपोर्ट किया जाता है.

ध्यान दें कि अगर आपको पकड़े गए अपवाद को Unity कंसोल में प्रिंट करना है और Crashlytics पर नॉनफ़ैटल इवेंट के तौर पर अपलोड करना है, तो यह तरीका अपनाएं:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}