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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• आपने अपने 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 टैब में जाएं. इसके बाद, ZIP फ़ॉर्मैट वाला ऐसा आर्काइव अपलोड करें जिसमें छूटी हुई dSYM फ़ाइलें मौजूद हों.
     • दूसरा विकल्प: dSYMs टैब में दिए गए यूयूआईडी के लिए, छूटी हुई dSYM फ़ाइलों को अपलोड करने के लिए, upload-symbols स्क्रिप्ट का इस्तेमाल करें.

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

क्रैश को ठीक से सिंबॉलिकेट नहीं किया गया है

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

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

• अगर आपको अपने ऐप्लिकेशन की लाइब्रेरी के लिए कई (Missing) फ़्रेम दिखते हैं, तो देखें कि क्या Firebase Console के Crashlytics dSYMs टैब में, ऐप्लिकेशन के उस वर्शन के लिए कुछ वैकल्पिक 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 11 या इसके बाद के वर्शन वाले डिवाइसों के लिए ही ANR की गड़बड़ियों की रिपोर्ट क्यों की जाती है?

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, ऐप्लिकेशन के अगली बार शुरू होने पर एएनआर की रिपोर्ट करता है. वहीं, Android की ज़रूरी जानकारी, एएनआर होने के बाद एएनआर का डेटा भेजती है.

इसके अलावा, 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 लेबल वाली नई समस्याएं दिख सकती हैं. हालांकि, ये समस्याएं .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.5.0" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' 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 से इस ABI के लिए सहायता हटा दी गई है.

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

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

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

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

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

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

हां, 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 कंसोल में अपवाद प्रिंट करता है. हालांकि, यह अपवाद भी दिखाता है, भले ही इसे अब तक दिखाया गया हो या नहीं. यह गड़बड़ी को नॉनलोकल तरीके से दिखाता है. इसका मतलब है कि Debug.LogException(exception) try-catch ब्लॉक के साथ भी, अपवाद को नहीं पकड़ा जा सकता.

इसलिए, 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 एसडीके का भी इस्तेमाल करता है, लेकिन क्रैश नहीं हो रहा है

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

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

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

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

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

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

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

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

सभी Firebase प्रोजेक्ट, 2 मार्च, 2026 से बैच एक्सपोर्ट करने वाले नए इन्फ़्रास्ट्रक्चर पर अपने-आप अपग्रेड हो गए हैं.

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

• नया इंफ़्रास्ट्रक्चर, अमेरिका के बाहर की Crashlytics डेटासेट की जगहों के साथ काम करता है.

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

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

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

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

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

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

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

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

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

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

समझें कि एक्सपोर्ट इंफ़्रास्ट्रक्चर, BigQuery टेबल में डेटा लिखने के लिए आइडेंटिफ़ायर का इस्तेमाल कैसे करता है

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

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

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

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

अगर अपग्रेड करने से पहले इस समस्या को ठीक नहीं किया गया, तो क्या होगा?

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

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

• पहचान करने वाले आपके ऐप्लिकेशन के बाइनरी के आधार पर नाम वाली किसी भी मौजूदा "लेगसी" टेबल में अब डेटा नहीं लिखा जाता है.

आइडेंटिफ़ायर के न मिलने के उदाहरण

ध्यान दें कि BigQuery बैच टेबल के नामों में, ऐप्लिकेशन के प्लैटफ़ॉर्म के बारे में बताने के लिए _IOS या _ANDROID अपने-आप जुड़ जाता है.

^{* अगर आपके ऐप्लिकेशन के बाइनरी में मौजूद आइडेंटिफ़ायर, Firebase ऐप्लिकेशन के लिए सेट किए गए किसी आइडेंटिफ़ायर से मेल खाता है, तो नया एक्सपोर्ट इंफ़्रास्ट्रक्चर उस आइडेंटिफ़ायर के लिए नई टेबल नहीं बनाता है. इसके बजाय, यह उस ऐप्लिकेशन के लिए डेटा लिखना जारी रखेगा. अन्य सभी ऐप्लिकेशन, नई टेबल में लिखे जाएंगे.}

^{** अगर आपके ऐप्लिकेशन के बाइनरी में मौजूद कोई आइडेंटिफ़ायर, Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर से मेल खाता है, तो एक्सपोर्ट करने की नई सुविधा से नई टेबल नहीं बनाई गई. इसके बजाय, यह उस टेबल को बनाए रखेगा और सभी ऐप्लिकेशन के लिए उसमें डेटा लिखना शुरू कर देगा.}

रुकावट को कम करने के विकल्प

• पहला विकल्प:
  एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर से बनाई गई नई टेबल का इस्तेमाल करें. आपको लेगसी टेबल से नई टेबल में डेटा कॉपी करना होगा.

  1. Google Cloud कंसोल में जाकर, अपनी लेगसी टेबल से पूरा डेटा कॉपी करें. इसके बाद, इसे उस नई टेबल में चिपकाएं जिसे बुनियादी ढांचे को अपग्रेड करने के दौरान बनाया गया था.

  2. अगर आपकी कोई डाउनस्ट्रीम डिपेंडेंसी, बैच टेबल पर निर्भर करती है, तो उसे नई टेबल का इस्तेमाल करने के लिए बदलें.

• दूसरा विकल्प:
  लेगसी टेबल में फिर से लिखने के लिए, कॉन्फ़िगरेशन बदलें. इसके लिए, आपको BigQuery कॉन्फ़िगरेशन में कुछ डिफ़ॉल्ट सेटिंग बदलनी होंगी.

  1. Firebase कंसोल में, उस ऐप्लिकेशन का Firebase ऐप्लिकेशन आईडी ढूंढें और नोट करें जिसका बैच टेबल का नाम और आइडेंटिफ़ायर मेल नहीं खा रहा है. उदाहरण के लिए, 1:1234567890:ios:321abc456def7890:
     settings प्रोजेक्ट सेटिंग पर जाएं. इसके बाद, आपके ऐप्लिकेशन कार्ड पर जाकर, अपने सभी Firebase ऐप्लिकेशन और उनकी जानकारी देखें.

  2. Google Cloud कंसोल में, बुनियादी सुविधाओं को अपग्रेड करने के बाद बनाए गए नए "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" में बदलाव करें, ताकि डेटा आपकी लेगसी टेबल में लिखा जा सके:

     1. "डेटा ट्रांसफ़र कॉन्फ़िगरेशन " देखने के लिए, BigQuery> डेटा ट्रांसफ़र पर जाएं.

     2. वह कॉन्फ़िगरेशन चुनें जिसमें सोर्स मौजूद है Firebase Crashlytics with Multi-Region Support.

     3. सबसे ऊपर दाएं कोने में मौजूद, बदलाव करें पर क्लिक करें.

     4. डेटा सोर्स की जानकारी सेक्शन में, gmp_app_id और client_namespace की सूची ढूंढें.

        BigQuery में, Firebase ऐप्लिकेशन आईडी को gmp_app_id कहा जाता है. डिफ़ॉल्ट रूप से, BigQuery में client_namespace की वैल्यू, ऐप्लिकेशन का यूनीक बंडल आईडी / पैकेज नेम होता है. हालांकि, इस डिफ़ॉल्ट कॉन्फ़िगरेशन को बदला जा सकता है.

        BigQuery, लिंक किए गए हर Firebase ऐप्लिकेशन के लिए, बैच टेबल के नाम के तौर पर client_namespace वैल्यू का इस्तेमाल करता है.

     5. उस Firebase ऐप्लिकेशन का gmp_app_id ढूंढें जिसके लिए आपको डिफ़ॉल्ट सेटिंग बदलनी हैं. इसके client_namespace की वैल्यू को उस टेबल के नाम पर सेट करें जिसमें Firebase ऐप्लिकेशन को डेटा लिखना है. आम तौर पर, यह उस लेगसी टेबल का नाम होता है जिसमें ऐप्लिकेशन, लेगसी एक्सपोर्ट इंफ़्रास्ट्रक्चर का इस्तेमाल करके डेटा लिखता था.

     6. कॉन्फ़िगरेशन में किए गए बदलाव को सेव करें.

  3. उन दिनों के लिए बैकफ़िल करने का शेड्यूल बनाएं जब आपकी लेगसी टेबल में डेटा मौजूद नहीं है.

  4. बैकफ़िल पूरा होने के बाद, नई एक्सपोर्ट इन्फ़्रास्ट्रक्चर की मदद से अपने-आप बनी नई टेबल मिटाएं.