Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल
इस पेज पर, Crashlytics इस्तेमाल करने से जुड़ी समस्याओं को हल करने में मदद मिलती है. साथ ही, अक्सर पूछे जाने वाले सवालों के जवाब भी मिलते हैं. अगर आपको अपनी ज़रूरत के हिसाब से जानकारी नहीं मिल पाती है या आपको ज़्यादा मदद चाहिए, तो Firebase की सहायता टीम से संपर्क करें.
सामान्य समस्याएं हल करना/अक्सर पूछे जाने वाले सवाल
समस्याएं टेबल में, कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट (और कभी-कभी "वैरिएंट") दिखना
आपको Firebase कंसोल में, समस्याएं टेबल में मौजूद समस्याओं के लिए दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. इसके अलावा, आपको कुछ समस्याओं में "वैरिएंट" नाम की सुविधा भी दिख सकती है. यहां इसकी वजह बताई गई है!
साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए बेहतर विश्लेषण इंजन लॉन्च किया था. साथ ही, नई समस्याओं के लिए अपडेट किया गया डिज़ाइन और कुछ बेहतर सुविधाएं भी लॉन्च की थीं. जैसे, वैरिएंट! इस बारे में पूरी जानकारी पाने के लिए, हमारी हाल ही की ब्लॉग पोस्ट देखें. हालांकि, खास जानकारी यहां दी गई है.
Crashlytics आपके ऐप्लिकेशन के सभी इवेंट का विश्लेषण करता है. जैसे, क्रैश, नॉन-फ़ैटल, और एएनआर. साथ ही, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहा जाता है. किसी समस्या में मौजूद सभी इवेंट में, गड़बड़ी की वजह एक ही होती है.
इवेंट को इन समस्याओं में ग्रुप करने के लिए, बेहतर विश्लेषण इंजन अब इवेंट के कई पहलुओं पर गौर करता है. इनमें स्टैक ट्रेस में फ़्रेम, अपवाद का मैसेज, गड़बड़ी का कोड, और अन्य प्लैटफ़ॉर्म या गड़बड़ी के टाइप की विशेषताएं शामिल हैं.
हालांकि, इवेंट के इस ग्रुप में, गड़बड़ी की वजह बताने वाले स्टैक ट्रेस अलग-अलग हो सकते हैं. अलग स्टैक ट्रेस का मतलब है कि समस्या की वजह अलग है.
किसी समस्या में इस संभावित अंतर को दिखाने के लिए, अब हम समस्याओं में वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या में मौजूद इवेंट का एक उप-समूह होता है. इसमें एक ही फ़ेलियर पॉइंट और एक जैसा स्टैक ट्रेस होता है. वैरिएंट की मदद से, किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि अलग-अलग वजहों से समस्या आ रही है या नहीं.
इन सुधारों के बाद, आपको ये सुविधाएं मिलेंगी:
समस्या वाली लाइन में दिखाया गया नया मेटाडेटा अब अपने ऐप्लिकेशन में मौजूद समस्याओं को समझना और उन्हें प्राथमिकता के आधार पर ठीक करना आसान हो गया है.
डुप्लीकेट समस्याओं की संख्या कम होना लाइन नंबर में बदलाव होने से नई समस्या नहीं होती.
अलग-अलग वजहों से होने वाली मुश्किल समस्याओं को आसानी से डीबग करना किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करें.
ज़्यादा काम की चेतावनियां और सिग्नल नई समस्या का मतलब है कि नया बग मौजूद है.
बेहतर खोज की सुविधा हर समस्या में खोजे जा सकने वाले ज़्यादा मेटाडेटा शामिल होते हैं. जैसे, अपवाद का टाइप और पैकेज का नाम.
इन सुधारों को इस तरह रोल आउट किया जा रहा है:
आपके ऐप्लिकेशन से नए इवेंट मिलने पर, हम यह देखेंगे कि वे किसी मौजूदा समस्या से मेल खाते हैं या नहीं.
अगर कोई मैच नहीं मिलता है, तो हम इवेंट पर अपने-आप इवेंट-ग्रुपिंग का बेहतर एल्गोरिदम लागू करेंगे. साथ ही, मेटाडेटा के नए डिज़ाइन के साथ एक नई समस्या बनाएंगे.
हम इवेंट ग्रुपिंग में यह पहला बड़ा अपडेट कर रहे हैं. अगर आपको कोई सुझाव देना है या कोई समस्या आ रही है, तो कृपया
शिकायत दर्ज करें.
ब्रेडक्रंब लॉग नहीं दिख रहे हैं
अगर आपको ब्रेडक्रंब लॉग नहीं दिख रहे हैं, तो हमारा सुझाव है कि आप Google Analytics के लिए, अपने ऐप्लिकेशन के कॉन्फ़िगरेशन की जांच करें.
पक्का करें कि आपने इन ज़रूरी शर्तों को पूरा किया हो:
आपने अपने ऐप्लिकेशन में
जोड़ा है. Crashlytics SDK टूल के अलावा, यह SDK टूल भी जोड़ना ज़रूरी है.
आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए,का इस्तेमाल किया हो.
तेज़ गति से लेन बदलने की सूचनाएं नहीं मिल रही हैं
अगर आपको वेलोसिटी अलर्ट नहीं दिख रहे हैं, तो पक्का करें कि आपने इनका इस्तेमाल किया हो:
क्रैश से जुड़ी मेट्रिक न दिखना या गलत मेट्रिक दिखना
अगर आपको क्रैश-फ़्री मेट्रिक (जैसे कि क्रैश-फ़्री उपयोगकर्ता और सेशन) नहीं दिख रही हैं या आपको ऐसी मेट्रिक दिख रही हैं जिन पर भरोसा नहीं किया जा सकता, तो यहां दी गई जानकारी देखें:
पक्का करें कि आपने इन SDK टूल का इस्तेमाल किया हो:
पक्का करें कि डेटा कलेक्शन की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:
अगर आपने क्रैश की जानकारी अपने-आप रिपोर्ट होने की सुविधा बंद करके, ऑप्ट-इन रिपोर्टिंग की सुविधा चालू की है, तो क्रैश की जानकारी सिर्फ़ उन उपयोगकर्ताओं से Crashlytics को भेजी जा सकती है जिन्होंने डेटा इकट्ठा करने की सुविधा के लिए ऑप्ट-इन किया है. इसलिए, क्रैश न होने की मेट्रिक की सटीक जानकारी पर असर पड़ेगा, क्योंकि Crashlytics के पास सिर्फ़ उन उपयोगकर्ताओं की क्रैश से जुड़ी जानकारी होती है जिन्होंने ऑप्ट-इन किया है. हालांकि, आपके पास सभी उपयोगकर्ताओं की जानकारी होती है. इसका मतलब है कि क्रैश-फ़्री मेट्रिक कम भरोसेमंद हो सकती हैं. साथ ही, इससे आपके ऐप्लिकेशन की स्थिरता के बारे में पूरी जानकारी नहीं मिल सकती.
अगर आपने डेटा अपने-आप इकट्ठा होने की सुविधा बंद की है, तो डिवाइस पर कैश मेमोरी में सेव की गई रिपोर्ट को Crashlytics पर भेजने के लिए, sendUnsentReports का इस्तेमाल किया जा सकता है.
इस तरीके का इस्तेमाल करने पर, Crashlytics को क्रैश का डेटा भेजा जाएगा. हालांकि, सेशन का डेटा नहीं भेजा जाएगा. इस वजह से, कंसोल चार्ट में क्रैश-फ़्री मेट्रिक के लिए कम या शून्य वैल्यू दिखती हैं.
उन उपयोगकर्ताओं का हिसाब कैसे लगाया जाता है जिन्हें क्रैश का अनुभव नहीं हुआ?
किसी समस्या पर नोट कौन देख सकता है, लिख सकता है, और मिटा सकता है?
नोट की मदद से, प्रोजेक्ट के सदस्य किसी खास समस्या पर टिप्पणी कर सकते हैं. साथ ही, सवाल पूछ सकते हैं, स्टेटस अपडेट कर सकते हैं वगैरह.
जब प्रोजेक्ट का कोई सदस्य कोई नोट पोस्ट करता है, तो उसे उसके Google खाते के ईमेल से लेबल किया जाता है. यह ईमेल पता और नोट, उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.
नोट देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में यहां बताया गया है:
प्रोजेक्ट के सदस्य, इन भूमिकाओं में से किसी एक भूमिका के साथ मौजूदा नोट देख सकते हैं और उन्हें मिटा सकते हैं. साथ ही, किसी समस्या पर नए नोट लिख सकते हैं.
प्रोजेक्ट के सदस्य, किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे नोट नहीं लिख सकते या उन्हें मिटा नहीं सकते. इसके लिए, उनके पास इनमें से कोई एक भूमिका होनी चाहिए:
ऐप्लिकेशन, Google Mobile Ads SDK टूल का भी इस्तेमाल करता है, लेकिन क्रैश नहीं हो रहा है
अगर आपका प्रोजेक्ट, Google Mobile Ads SDK के साथ-साथ Crashlytics का इस्तेमाल करता है, तो ऐसा हो सकता है कि क्रैश रिपोर्टर, अपवाद हैंडलर रजिस्टर करते समय दखल दे रहे हों. इस समस्या को ठीक करने के लिए, Mobile Ads SDK टूल में क्रैश रिपोर्टिंग की सुविधा बंद करें. इसके लिए, disableSDKCrashReporting को कॉल करें.
मेरा BigQuery डेटासेट कहां मौजूद है?
Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट अपने-आप अमेरिका में सेव हो जाते हैं. भले ही, आपका Firebase प्रोजेक्ट किसी भी जगह पर हो.
प्लैटफ़ॉर्म के लिए सहायता
पिछली समस्याओं का फिर से दिखना
रिग्रेशन की समस्या क्या होती है?
जब आपने किसी समस्या को पहले बंद कर दिया हो, लेकिन Crashlytics को एक नई रिपोर्ट मिलती है कि समस्या फिर से हो गई है, तो इसका मतलब है कि समस्या फिर से शुरू हो गई है.
Crashlytics इन समस्याओं को अपने-आप फिर से खोल देता है, ताकि आप अपने ऐप्लिकेशन के हिसाब से उन्हें ठीक कर सकें.
यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन के तौर पर कैसे कैटगरी में रखता है:
पहली बार, Crashlytics को Crash "A" के बारे में क्रैश रिपोर्ट मिलती है. Crashlytics उस क्रैश से जुड़ी समस्या (समस्या "A") को खोलता है.
आपने इस गड़बड़ी को तुरंत ठीक कर दिया. इसके बाद, आपने समस्या "A" को बंद कर दिया और अपने ऐप्लिकेशन का नया वर्शन रिलीज़ कर दिया.
Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है. ऐसा तब होता है, जब आपने समस्या को बंद कर दिया हो.
अगर रिपोर्ट, ऐप्लिकेशन के ऐसे वर्शन से मिली है जिसके बारे में Crashlytics को समस्या बंद करते समय पता था, तो Crashlytics इस समस्या को फिर से होने वाली समस्या के तौर पर नहीं मानेगा. इसका मतलब है कि वर्शन ने क्रैश होने की रिपोर्ट भेजी थी. हालांकि, यह रिपोर्ट किसी भी क्रैश के लिए भेजी गई थी. यह समस्या बंद रहेगी.
अगर रिपोर्ट, ऐप्लिकेशन के ऐसे वर्शन से मिली है जिसके बारे में Crashlyticsको नहीं
पता था, तो इसका मतलब है कि उस वर्शन ने क्रैश होने की कोई रिपोर्ट कभी नहीं भेजी थी. ऐसे में, Crashlytics इस समस्या को फिर से शुरू हुई समस्या के तौर पर मानता है और इसे फिर से खोल देगा.
जब कोई समस्या फिर से शुरू हो जाती है, तो हम रिग्रेशन का पता चलने पर सूचना भेजते हैं. साथ ही, समस्या में रिग्रेशन सिग्नल जोड़ते हैं, ताकि आपको पता चल सके कि Crashlytics ने समस्या को फिर से खोल दिया है. अगर आपको नहीं चाहिए कि रिग्रेशन एल्गोरिदम की वजह से कोई समस्या फिर से खुले, तो उसे बंद करने के बजाय "म्यूट" करें.
मुझे ऐप्लिकेशन के पुराने वर्शन में समस्याएं क्यों दिख रही हैं?
अगर रिपोर्ट, ऐप्लिकेशन के किसी ऐसे पुराने वर्शन से है जिसने समस्या बंद करते समय कभी भी क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics इस समस्या को फिर से शुरू हुई समस्या के तौर पर मानता है और इसे फिर से खोल देगा.
ऐसा इन स्थितियों में हो सकता है: आपने किसी गड़बड़ी को ठीक कर दिया है और अपने ऐप्लिकेशन का नया वर्शन रिलीज़ कर दिया है. हालांकि, अब भी ऐसे उपयोगकर्ता हैं जो गड़बड़ी को ठीक किए बिना, ऐप्लिकेशन के पुराने वर्शन का इस्तेमाल कर रहे हैं. अगर किसी पुराने वर्शन में, समस्या को बंद करते समय क्रैश रिपोर्ट कभी नहीं भेजी गई थी और उन उपयोगकर्ताओं को गड़बड़ी का सामना करना पड़ता है, तो वे क्रैश रिपोर्ट, फिर से शुरू हुई समस्या को ट्रिगर करेंगी.
अगर आपको नहीं चाहिए कि रिग्रेशन एल्गोरिदम की वजह से कोई समस्या फिर से खुले, तो उसे बंद करने के बजाय "म्यूट करें".
