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

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

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

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

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

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

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

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

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 प्रोजेक्ट में रखना होता था.

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

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

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

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

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

  अगर आपको Android 11 और Android 12 के कुछ एएनआर के लिए BuildId नहीं दिख रहे हैं, तो हो सकता है कि आप एसडीके और 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 के बीच, एएनआर की संख्या में अंतर हो सकता है. ऐसा इसलिए होता है, क्योंकि एएनआर डेटा को इकट्ठा करने और रिपोर्ट करने के तरीके अलग-अलग होते हैं. 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

Crashlytics Gradle प्लगिन v3 पर कैसे अपग्रेड करें?

Crashlytics Gradle प्लगिन का नया वर्शन, एक मुख्य वर्शन (v3.0.0) है. साथ ही, यह SDK को आधुनिक बनाता है. इसके लिए, यह Gradle और Android Gradle प्लगिन के पुराने वर्शन के साथ काम नहीं करता. इसके अलावा, इस रिलीज़ में किए गए बदलावों से AGP v8.1+ से जुड़ी समस्याएं हल हो जाती हैं. साथ ही, नेटिव ऐप्लिकेशन और पसंद के मुताबिक बनाए गए बिल्ड के लिए बेहतर सहायता मिलती है.

ज़रूरी शर्तें

Crashlytics Gradle प्लगिन v3 के लिए, ये ज़रूरी शर्तें पूरी होनी चाहिए:

• Android Gradle प्लग इन 8.1+
  Android Studio के नए वर्शन पर, Android Gradle प्लग इन अपग्रेड असिस्टेंट का इस्तेमाल करके, इस प्लग इन को अपग्रेड करें.

• Firebase का google-services Gradle प्लगिन 4.4.1+
  इस प्लगिन को अपग्रेड करने के लिए, अपने प्रोजेक्ट की Gradle बिल्ड फ़ाइल में नया वर्शन डालें. जैसे:

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Crashlytics एक्सटेंशन में हुए बदलाव

Crashlytics Gradle प्लगिन के तीसरे वर्शन में, Crashlytics एक्सटेंशन में ये बदलाव किए गए हैं:

• defaultConfig Android ब्लॉक से एक्सटेंशन हटा दिया गया है. इसके बजाय, आपको हर वैरिएंट को कॉन्फ़िगर करना चाहिए.

• अब इस्तेमाल में नहीं रहे फ़ील्ड mappingFile को हटा दिया गया है. इसके बजाय, अब मर्ज की गई मैपिंग फ़ाइल अपने-आप उपलब्ध कराई जाती है.

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

• unstrippedNativeLibsDir फ़ील्ड को कुल वैल्यू के तौर पर दिखाने के लिए बदला गया है.

  एक से ज़्यादा डायरेक्ट्री वाला उदाहरण देखें

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  uploadCrashlyticsSymbolFilesBasicRelease टास्क सिर्फ़ MY/NATIVE/LIBS में मौजूद सिंबल अपलोड करेगा. हालांकि, uploadCrashlyticsSymbolFilesFeatureXRelease टास्क, MY/NATIVE/LIBS और MY/FEATURE_X/LIBS, दोनों में मौजूद सिंबल अपलोड करेगा.

• क्लोज़र फ़ील्ड symbolGenerator को दो नए टॉप लेवल फ़ील्ड से बदल दिया गया है:

  • symbolGeneratorType, एक स्ट्रिंग है. इसकी वैल्यू "breakpad" (डिफ़ॉल्ट) या "csym" हो सकती है.
  • breakpadBinary, स्थानीय dump_syms बाइनरी ओवरराइड की फ़ाइल.

एक्सटेंशन को अपग्रेड करने के तरीके का उदाहरण

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

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
  

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

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

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 को किसी ऐसे अपवाद की रिपोर्ट फ़ैटल के तौर पर करनी चाहिए जिसे पकड़ा नहीं गया है. इसके लिए, इन दोनों शर्तों को पूरा करना ज़रूरी है:

• आपके ऐप्लिकेशन में शुरू होने के दौरान, 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
    //
}

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

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

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

Firebase, डेटा को उस डेटासेट लोकेशन पर एक्सपोर्ट करता है जिसे आपने BigQuery पर डेटा एक्सपोर्ट करने की सुविधा सेट अप करते समय चुना था.

• यह जगह, Crashlytics डेटासेट और Firebase सेशन डेटासेट, दोनों पर लागू होती है. हालांकि, ऐसा तब होता है, जब सेशन के डेटा को एक्सपोर्ट करने की सुविधा चालू हो.

• यह जगह की जानकारी सिर्फ़ BigQuery में एक्सपोर्ट किए गए डेटा के लिए लागू होती है. इससे Firebase कंसोल के Crashlytics डैशबोर्ड या Android Studio में इस्तेमाल के लिए सेव किए गए डेटा की जगह की जानकारी पर कोई असर नहीं पड़ता.

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

BigQuery के लिए, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करने का तरीका क्या है?

अक्टूबर 2024 के बीच में, Crashlytics ने Crashlytics के डेटा को BigQuery में बैच एक्सपोर्ट करने के लिए, नया इन्फ़्रास्ट्रक्चर लॉन्च किया.

• अगर आपने बैच एक्सपोर्ट की सुविधा अक्टूबर 2024 के बाद चालू की है, तो आपका Firebase प्रोजेक्ट, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर का इस्तेमाल अपने-आप कर रहा है. आपको कुछ भी करने की ज़रूरत नहीं है.

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

सभी Firebase प्रोजेक्ट, 9 जनवरी, 2026 से नए बैच एक्सपोर्ट इंफ़्रास्ट्रक्चर पर अपने-आप अपग्रेड हो जाएंगे. इस तारीख से पहले अपग्रेड किया जा सकता है. हालांकि, पक्का करें कि आपकी BigQuery बैच टेबल, अपग्रेड करने की ज़रूरी शर्तों को पूरा करती हों.

यह पता लगाना कि आप नए इंफ़्रास्ट्रक्चर पर हैं या नहीं

अगर आपने अक्टूबर 2024 के बीच या उसके बाद बैच एक्सपोर्ट की सुविधा चालू की है, तो आपका Firebase प्रोजेक्ट, एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर का इस्तेमाल अपने-आप कर रहा है.

यह देखा जा सकता है कि आपका प्रोजेक्ट किस इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है: Google Cloud कंसोल पर जाएं. अगर आपके "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" को Firebase Crashlytics with Multi-Region Support के तौर पर लेबल किया गया है, तो इसका मतलब है कि आपका प्रोजेक्ट, नए एक्सपोर्ट इंफ़्रास्ट्रक्चर का इस्तेमाल कर रहा है.

डेटा एक्सपोर्ट करने के पुराने और नए इन्फ़्रास्ट्रक्चर के बीच मुख्य अंतर

• नए इंफ़्रास्ट्रक्चर में, अमेरिका के बाहर की Crashlytics डेटासेट लोकेशन काम करती हैं.

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

  • डेटा एक्सपोर्ट करने की सुविधा अक्टूबर 2024 के बीच में या उसके बाद चालू की गई हो — सेटअप के दौरान, आपको डेटा एक्सपोर्ट करने के लिए कोई जगह चुनने के लिए कहा गया हो.

• नए इन्फ़्रास्ट्रक्चर में, एक्सपोर्ट की सुविधा चालू करने से पहले के डेटा को वापस नहीं लाया जा सकता.

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

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

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

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

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

पहला चरण: अपग्रेड करने के लिए ज़रूरी शर्तें

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

   • आपको अपने Firebase प्रोजेक्ट में रजिस्टर किए गए सभी Firebase ऐप्लिकेशन, Firebase कंसोल में दिखेंगे: अपने Firebase प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, आपके ऐप्लिकेशन कार्ड पर स्क्रोल करके, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखें.settings

   • आपको अपनी सभी BigQuery बैच टेबल, Google Cloud कंसोल के BigQuery पेज पर मिल सकती हैं.

   REALTIME

   उदाहरण के लिए, यहां कुछ ऐसी स्थितियां दी गई हैं जिनमें अपग्रेड करने पर आपको कोई समस्या नहीं आएगी:

   • आपके पास com_yourcompany_yourproject_IOS नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject बंडल आईडी वाला Firebase iOS+ ऐप्लिकेशन रजिस्टर है.

   • आपके पास com_yourcompany_yourproject_ANDROID नाम की बैच टेबल है. साथ ही, आपके Firebase प्रोजेक्ट में com.yourcompany.yourproject पैकेज नाम वाला Firebase Android ऐप्लिकेशन रजिस्टर है.

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

दूसरा चरण: मैन्युअल तरीके से नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करना

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

यहां इस बारे में ज़्यादा जानकारी दी गई है:

1. Firebase कंसोल में, इंटिग्रेशन पेज पर जाएं.

2. BigQuery कार्ड में, मैनेज करें पर क्लिक करें.

3. एक्सपोर्ट की सुविधा बंद करने के लिए, Crashlytics स्लाइडर को टॉगल करके बंद करें. जब कहा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करने की सुविधा बंद करनी है.

4. एक्सपोर्ट की सुविधा को फिर से चालू करने के लिए, Crashlytics स्लाइडर को तुरंत फिर से चालू करें. जब आपसे पूछा जाए, तब पुष्टि करें कि आपको डेटा एक्सपोर्ट करना है.

   Crashlytics से BigQuery में डेटा एक्सपोर्ट करने के लिए, अब एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर का इस्तेमाल किया जा रहा है.

आपकी मौजूदा बैच टेबल का नाम, Firebase ऐप्लिकेशन के आइडेंटिफ़ायर से मेल नहीं खाता