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

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

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

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

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

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

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

इन सुधारों से आपको ये फ़ायदे मिलेंगे:

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

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

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

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

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

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

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

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

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

ब्रेडक्रंब लॉग न दिखना

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

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

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

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

• अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, 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 उस समस्या को फिर से हुई समस्या मानेगा और उसे फिर से खोलेगा.

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

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

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

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

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

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

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

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

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

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

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

   • मैन्युअल तरीके से, मौजूद नहीं होने वाली dSYM फ़ाइलें अपलोड करें:

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

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

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

अगर आपको लगता है कि आपके स्टैक ट्रेस सही तरीके से सिंबल नहीं किए गए हैं, तो इनकी जांच करें:

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

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

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

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

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

अब एक ही 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 नहीं मिल रहे हैं, तो हो सकता है कि आप SDK टूल, Gradle प्लग इन या दोनों के पुराने वर्शन का इस्तेमाल कर रहे हों. इन एएनआर के लिए BuildId को सही तरीके से इकट्ठा करने के लिए, आपको इन वर्शन का इस्तेमाल करना होगा:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle प्लगिन का वर्शन 2.9.4 या इसके बाद का वर्शन

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

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

• पक्का करें कि बिल्ड प्रोसेस के दौरान, BuildId को हटाया न जा रहा हो.

  ध्यान दें कि समस्या हल करने के ये सुझाव, एएनआर और नेटिव क्रैश, दोनों पर लागू होते हैं.

  • अपनी बाइनरी पर readelf -n चलाकर देखें कि BuildId मौजूद हैं या नहीं. अगर BuildId मौजूद नहीं हैं, तो अपने बिल्ड सिस्टम के फ़्लैग में -Wl,--build-id जोड़ें.

  • देख लें कि आपने अपने APK का साइज़ कम करने की कोशिश में, अनजाने में BuildId को न हटाया हो.

  • अगर आपने किसी लाइब्रेरी के स्ट्रिप्ड और अनस्ट्रिप्ड वर्शन रखे हैं, तो पक्का करें कि आपने अपने कोड में सही वर्शन को पॉइंट किया हो.

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

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

इसके अलावा, Crashlytics सिर्फ़ उन एएनआर को दिखाता है जो Android 11 और इसके बाद के वर्शन वाले डिवाइसों पर होते हैं. वहीं, Google Play उन डिवाइसों से जुड़े एएनआर दिखाता है जिनमें Google Play services मौजूद है और डेटा कलेक्शन की सहमति दी गई है.

मुझे .java समस्याओं के तौर पर लेबल की गई .kt फ़ाइलों से क्रैश क्यों दिखते हैं?

जब कोई ऐप्लिकेशन, फ़ाइल एक्सटेंशन को छिपाने वाले टूल का इस्तेमाल करता है, तो 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) है. यह Gradle और Android Gradle प्लगिन के पुराने वर्शन के साथ काम नहीं करता. इससे एसडीके को आधुनिक बनाने में मदद मिलती है. इसके अलावा, इस रिलीज़ में किए गए बदलावों से, एजीपी के 8.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 में एनडीके स्टैक ट्रेस के बीच अंतर

LLVM और GNU टूलचेन में, आपके ऐप्लिकेशन की बाइनरी के रीड-ओनली सेगमेंट के लिए अलग-अलग डिफ़ॉल्ट और ट्रीटमेंट होते हैं. इनकी वजह से, Firebase कंसोल में अलग-अलग स्टैक ट्रेस जनरेट हो सकते हैं. इस समस्या को कम करने के लिए, अपनी बिल्ड प्रोसेस में ये लिंकर फ़्लैग जोड़ें:

• अगर LLVM टूलचेन के lld लिंकर का इस्तेमाल किया जा रहा है, तो यह जोड़ें:

  -Wl,--no-rosegment

• अगर GNU टूलचेन के ld.gold लिंकर का इस्तेमाल किया जा रहा है, तो यह जोड़ें:

  -Wl,--rosegment

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

-fno-omit-frame-pointer

मैं एनडीके के लिए, 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 एनडीके, ARMv5 (armeabi) के साथ काम नहीं करता. NDK r17 से, इस एबीआई के लिए सहायता हटा दी गई थी.

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

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

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

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

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

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

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

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

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

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

   • Android ऐप्लिकेशन के लिए: पक्का करें कि आपने सिंबल फ़ाइल जनरेट और अपलोड करने के लिए, Firebase सीएलआई 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 एसडीके का भी इस्तेमाल किया जा रहा है, लेकिन क्रैश नहीं हो रहा है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • नया इन्फ़्रास्ट्रक्चर, डेटा को बैच टेबल में लिखता है. इन टेबल के नाम, बंडल आईडी या पैकेज के नामों पर आधारित होते हैं. ये नाम, आपके 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, बैच टेबल के नाम के लिए client_namespace वैल्यू का इस्तेमाल करता है. लिंक किया गया हर Firebase ऐप्लिकेशन, इस बैच टेबल में डेटा लिखता है.

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

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

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

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