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

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

इस पेज पर, आपको इन विषयों के बारे में जानकारी मिल सकती है:

• सामान्य समस्या हल करना. इसमें, Firebase कंसोल में डेटा दिखने या डेटा के साथ काम करने से जुड़े सवाल और पहले से मौजूद समस्याओं के बारे में सवाल शामिल हैं.

• प्लैटफ़ॉर्म के हिसाब से सहायता. इसमें Apple प्लैटफ़ॉर्म, Android, और Unity से जुड़े सवाल शामिल हैं.

• इंटिग्रेशन से जुड़ी सहायता. इसमें BigQuery के बारे में पूछे गए सवाल भी शामिल हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जब आपने किसी समस्या को पहले बंद कर दिया हो, लेकिन Crashlytics को एक नई रिपोर्ट मिलती है कि समस्या फिर से हो गई है, तो इसे समस्या का रीग्रेशन कहा जाता है. Crashlytics, परफ़ॉर्मेंस में गिरावट की वजह से बंद की गई इन समस्याओं को अपने-आप फिर से खोल देता है, ताकि आप अपने ऐप्लिकेशन के हिसाब से उन्हें ठीक कर सकें.

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन के तौर पर कैसे कैटगरी में रखता है:

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को रिग्रेशन के तौर पर तब कैटगरी में रखता था, जब वह समस्या ऐप्लिकेशन के किसी भी वर्शन में फिर से होती थी. भले ही, हमें उन ऐप्लिकेशन वर्शन के बारे में तब पता हो, जब आपने समस्या को बंद किया था. इस वजह से, Crashlytics कभी-कभी रिग्रेशन की पहचान गलत तरीके से हो जाती थी. अब हम ऊपर बताए गए कन्वेंशन का इस्तेमाल करते हैं.

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Android सहायता

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

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

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

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

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

  अगर आपको Android 11 और Android 12 के कुछ एएनआर के लिए BuildId नहीं दिख रहे हैं, तो हो सकता है कि आप SDK टूल और Gradle प्लग इन के पुराने वर्शन का इस्तेमाल कर रहे हों. इन एएनआर के लिए BuildId को सही तरीके से इकट्ठा करने के लिए, आपको इन वर्शन का इस्तेमाल करना होगा:

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

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

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

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

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

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

  • पक्का करें कि APK का साइज़ कम करने के लिए, आपने गलती से BuildId नहीं हटा दिए हों.

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

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

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

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

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

जब कोई ऐप्लिकेशन ऐसे ऑबफ़स्केटर का इस्तेमाल करता है जो फ़ाइल एक्सटेंशन को ज़ाहिर नहीं करता है, तो Crashlytics डिफ़ॉल्ट रूप से हर समस्या को .java फ़ाइल एक्सटेंशन के साथ जनरेट करता है.

इसलिए, Crashlytics सही फ़ाइल एक्सटेंशन के साथ समस्याएं जनरेट कर सकता है. पक्का करें कि आपका ऐप्लिकेशन इस सेटअप का इस्तेमाल करता हो:

• Android Gradle 4.2.0 या इसके बाद के वर्शन का इस्तेमाल करता हो
• यह R8 का इस्तेमाल करता है. इसमें कोड को उलझाने की सुविधा चालू होती है. अपने ऐप्लिकेशन को R8 पर अपडेट करने के लिए, यह दस्तावेज़ पढ़ें.

ध्यान दें कि ऊपर बताए गए सेटअप पर अपडेट करने के बाद, आपको नई .kt समस्याएं दिख सकती हैं. ये समस्याएं, मौजूदा .java समस्याओं की डुप्लीकेट होती हैं. इस बारे में ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.

मुझे .kt ऐसी समस्याएं क्यों दिखती हैं जो मौजूदा .java समस्याओं की डुप्लीकेट हैं?

दिसंबर 2021 के मध्य से, Crashlytics Kotlin का इस्तेमाल करने वाले ऐप्लिकेशन के लिए बेहतर सहायता उपलब्ध कराई गई.

हाल ही में, उपलब्ध ऑबफ़स्केटर फ़ाइल एक्सटेंशन का पता नहीं लगाते थे. इसलिए, Crashlytics डिफ़ॉल्ट रूप से हर समस्या को .java फ़ाइल एक्सटेंशन के साथ जनरेट करता था. हालांकि, Android Gradle 4.2.0 के बाद से, R8 फ़ाइल एक्सटेंशन के साथ काम करता है.

इस अपडेट के बाद, Crashlytics अब यह पता लगा सकता है कि ऐप्लिकेशन में इस्तेमाल की गई हर क्लास को Kotlin में लिखा गया है या नहीं. साथ ही, समस्या के हस्ताक्षर में सही फ़ाइल नाम शामिल कर सकता है. अगर आपके ऐप्लिकेशन में यह सेटअप है, तो अब क्रैश को .kt फ़ाइलों (ज़रूरत के मुताबिक) के लिए सही तरीके से एट्रिब्यूट किया जाता है:

• आपका ऐप्लिकेशन, Android Gradle 4.2.0 या इसके बाद के वर्शन का इस्तेमाल करता हो.
• आपका ऐप्लिकेशन, R8 का इस्तेमाल करता है. इसमें कोड को उलझाने की सुविधा चालू है.

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

Dexguard का इस्तेमाल करने पर क्रैश नहीं हो रहे हैं

अगर आपको यहां दिया गया अपवाद दिखता है, तो हो सकता है कि आप DexGuard के ऐसे वर्शन का इस्तेमाल कर रहे हों जो Firebase Crashlytics SDK टूल के साथ काम नहीं करता:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

इस अपवाद से आपका ऐप्लिकेशन क्रैश नहीं होता. हालांकि, इससे क्रैश रिपोर्ट नहीं भेजी जा सकतीं. इस समस्या को ठीक करने के लिए:

1. पक्का करें कि DexGuard 8.x का नया वर्शन इस्तेमाल किया जा रहा हो. नए वर्शन में ऐसे नियम शामिल हैं जिनकी ज़रूरत Firebase Crashlytics SDK टूल को होती है.

2. अगर आपको DexGuard का वर्शन नहीं बदलना है, तो अपनी DexGuard कॉन्फ़िगरेशन फ़ाइल में, यहां दी गई लाइन को धुंधला करने के नियमों में जोड़ें:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

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 बिल्ड फ़ाइल में नया वर्शन डालें. जैसे:

Kotlin

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

Groovy

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 बाइनरी ओवरराइड की फ़ाइल है.

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

Kotlin

इससे पहले	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } }
अब v3 में उपलब्ध है	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Groovy

इससे पहले	buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
अब v3 में उपलब्ध है	buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

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

Crashlytics डैशबोर्ड और logcat में NDK स्टैक ट्रेस के बीच अंतर

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

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

  -Wl,--no-rosegment

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

  -Wl,--rosegment

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

-fno-omit-frame-pointer

मैं NDK के लिए, Breakpad सिंबल फ़ाइल जनरेट करने वाले अपने खुद के बाइनरी का इस्तेमाल कैसे करूं?

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

ध्यान दें: Android बाइनरी के लिए, Breakpad सिंबल फ़ाइल जनरेटर के Linux वर्शन की ज़रूरत होती है.

Breakpad सिंबल फ़ाइल जनरेटर बाइनरी का पाथ, इन दो तरीकों में से किसी एक तरीके से तय किया जा सकता है:

• पहला विकल्प: अपनी build.gradle फ़ाइल में firebaseCrashlytics एक्सटेंशन के ज़रिए पाथ तय करना

  अपने ऐप्लिकेशन-लेवल की build.gradle.kts फ़ाइल में यह कोड जोड़ें:

  Gradle प्लगिन v3.0.0+

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  प्लगिन के पुराने वर्शन

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• दूसरा विकल्प: Gradle प्रॉपर्टी फ़ाइल में प्रॉपर्टी लाइन के ज़रिए पाथ तय करना

  com.google.firebase.crashlytics.breakpadBinary प्रॉपर्टी का इस्तेमाल करके, एक्ज़ीक्यूटेबल का पाथ तय किया जा सकता है.

  Gradle प्रॉपर्टी फ़ाइल को मैन्युअल तरीके से अपडेट किया जा सकता है. इसके अलावा, कमांड लाइन के ज़रिए भी फ़ाइल को अपडेट किया जा सकता है. उदाहरण के लिए, कमांड लाइन के ज़रिए पाथ तय करने के लिए, इस तरह की कमांड का इस्तेमाल करें:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ध्यान दें: इन्फ़्रास्ट्रक्चर को अपग्रेड करने की यह सुविधा सिर्फ़ Crashlytics बैच एक्सपोर्ट पर लागू होती है. यह सेशन एक्सपोर्ट पर लागू नहीं होती.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Crashlytics से BigQuery में डेटा के बैच एक्सपोर्ट में रुकावट से बचने के लिए, मैन्युअल तरीके से अपग्रेड करने से पहले या 9 जनवरी, 2026 से पहले इस सेक्शन में दिए गए निर्देशों का पालन करें.

वीडियो में रुकावट आने से रोकने के विकल्पों के बारे में निर्देश पर जाएं

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

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

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

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

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

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

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

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

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

पहचानकर्ताओं के मेल न खाने के उदाहरण

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

आपके ऐप्लिकेशन के बाइनरी में मौजूद आइडेंटिफ़ायर	आपके Firebase ऐप्लिकेशन के लिए सेट किए गए आइडेंटिफ़ायर	लेगसी वर्शन का व्यवहार	एक्सपोर्ट के नए इंफ़्रास्ट्रक्चर पर अपग्रेड करने के बाद का व्यवहार	समाधान
foo	bar	ऐप्लिकेशन की बाइनरी (foo) में मौजूद आइडेंटिफ़ायर के नाम वाली एक टेबल में लिखता है	यह कुकी, Firebase ऐप्लिकेशन (bar) के लिए सेट किए गए आइडेंटिफ़ायर के नाम वाली एक टेबल बनाती है और फिर उसमें डेटा लिखती है	यहां दिए गए पहले या दूसरे विकल्प को लागू करें.
foo	bar, qux वगैरह	ऐप्लिकेशन की बाइनरी (foo) में मौजूद आइडेंटिफ़ायर के नाम वाली एक टेबल में लिखता है	यह कुकी, Firebase ऐप्लिकेशन (bar, qux वगैरह) के लिए सेट किए गए आइडेंटिफ़ायर के नाम वाली कई टेबल बनाती* है. इसके बाद, उनमें डेटा लिखती है	नीचे दिए गए दूसरे विकल्प को लागू करें.
foo, baz वगैरह	bar	यह ऐप्लिकेशन के बाइनरी (foo, baz वगैरह) में मौजूद कई आइडेंटिफ़ायर के नाम वाली कई टेबल में लिखता है	यह हर ऐप्लिकेशन का डेटा बनाता है** और फिर उसे एक टेबल में लिखता है. इस टेबल का नाम, Firebase ऐप्लिकेशन (bar) के लिए सेट किए गए आइडेंटिफ़ायर के नाम पर रखा जाता है	इनमें से कोई भी विकल्प लागू नहीं किया जा सकता. हालांकि, ऐप्लिकेशन के bundle_identifier का इस्तेमाल करके, एक ही टेबल में हर ऐप्लिकेशन के डेटा को अलग-अलग किया जा सकता है. यह bundle_identifier, डेटा के साथ एक्सपोर्ट किया जाता है.

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

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

रुकावट से बचने के विकल्प

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

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

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

  1. Firebase कंसोल में जाकर, लिंक किए गए ऐप्लिकेशन के लिए एक्सपोर्ट की सुविधा बंद करें. इसके बाद, इसे फिर से चालू करके, डेटा एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें.

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

  2. Google Cloud कंसोल में जाकर, अपनी लेगसी टेबल से पूरा डेटा कॉपी करें और उसे अभी-अभी बनाई गई नई टेबल में चिपकाएं.

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

  ध्यान दें: अपग्रेड करने के बाद, नया डेटा आपकी लेगसी टेबल में नहीं लिखा जाएगा. लेगसी टेबल में पहले से लिखा गया कोई भी डेटा नहीं मिटाया जाएगा.

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

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

  2. Firebase कंसोल में जाकर, लिंक किए गए ऐप्लिकेशन के लिए एक्सपोर्ट की सुविधा बंद करें. इसके बाद, इसे फिर से चालू करके, डेटा एक्सपोर्ट करने के नए इन्फ़्रास्ट्रक्चर पर अपग्रेड करें.

     इस कार्रवाई से दो काम होते हैं:

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

     • यह सोर्स Firebase Crashlytics with Multi-Region Support के साथ BigQuery "डेटा ट्रांसफ़र कॉन्फ़िगरेशन" बनाता है.

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

        ध्यान दें: अगर आपने पहले किसी एक टेबल में डेटा लिखा था और अब अपग्रेड करने के बाद आपके पास कई टेबल हैं, तो हर लागू होने वाले gmp_app_id के लिए एक ही client_namespace का इस्तेमाल किया जा सकता है. BigQuery सभी टेबल को मर्ज कर देगा और Firebase ऐप्लिकेशन का सारा डेटा एक ही टेबल में लिख देगा.

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

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

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