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

  • अगर आपने डेटा कलेक्शन अपने-आप इकट्ठा होने की सुविधा बंद की है, तो 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 कंसोल में "डीएसवाईएम मौजूद नहीं है" सूचना दिखती है, तो Xcode में जाकर देखें कि बिल्ड के लिए डीएसवाईएम सही तरीके से जनरेट हो रहे हैं या नहीं.

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

   • पक्का करें कि आपके पास Crashlytics का नया वर्शन हो.

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

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

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

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

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

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

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

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

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

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

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

Android 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 ऐप्लिकेशन के अगली बार शुरू होने पर, 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 plugin 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 के बाद से, इस ABI के लिए सहायता हटा दी गई है.

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

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

• इस फ़ंक्शन का इस्तेमाल, Unity कंसोल में अपवाद को प्रिंट करने के लिए किया जाता है.
• अपवाद को Crashlytics में गंभीर इवेंट के तौर पर अपलोड करने के लिए.
• अपवाद को थ्रो करने के लिए, इसे uncaught अपवाद के तौर पर माना जाता है. साथ ही, इसे 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 में बैच एक्सपोर्ट करने के लिए, नया इन्फ़्रास्ट्रक्चर लॉन्च किया.

सभी 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. बैकफ़िल पूरा होने के बाद, नई एक्सपोर्ट इन्फ़्रास्ट्रक्चर की मदद से अपने-आप बनाई गई नई टेबल मिटाएं.