यह पृष्ठ Crashlytics का उपयोग करने के बारे में अक्सर पूछे जाने वाले प्रश्नों के लिए समस्या निवारण सहायता और उत्तर प्रदान करता है। यदि आपको वह नहीं मिल रहा है जिसकी आप तलाश कर रहे हैं या अतिरिक्त सहायता की आवश्यकता है, तो Firebase सहायता से संपर्क करें।
सामान्य समस्या निवारण / अक्सर पूछे जाने वाले प्रश्न
यदि आप क्रैश-मुक्त उपयोगकर्ता, ब्रेडक्रंब लॉग और/या वेग अलर्ट नहीं देख रहे हैं, तो हम अनुशंसा करते हैं कि आप Google Analytics के लिए अपने ऐप के कॉन्फ़िगरेशन की जाँच करें।
सुनिश्चित करें कि आपने अपने Firebase प्रोजेक्ट में Google Analytics को सक्षम कर दिया है ।
सुनिश्चित करें कि Firebase कंसोल के एकीकरण > Google Analytics पृष्ठ में Google Analytics के लिए डेटा साझाकरण सक्षम है। ध्यान दें कि डेटा साझाकरण सेटिंग Firebase कंसोल में प्रदर्शित की जाती हैं लेकिन Google Analytics कंसोल में प्रबंधित की जाती हैं।
Firebase Crashlytics SDK के अलावा, सुनिश्चित करें कि आपने अपने ऐप ( iOS+ | Android ) में Google Analytics के लिए Firebase SDK जोड़ा है।
सुनिश्चित करें कि आप अपने सभी Firebase SDK ( iOS+ | Android ) के लिए नवीनतम संस्करण का उपयोग कर रहे हैं।
विशेष रूप से जांचें कि आप Google Analytics के लिए Firebase SDK के कम से कम निम्न संस्करणों का उपयोग कर रहे हैं: iOS+ — v6.3.1+ (macOS और tvOS के लिए v8.9.0+) | Android — v17.2.3+(बीओएम v24.7.1+) ।
आप Firebase कंसोल में अपनी समस्या तालिका में सूचीबद्ध समस्याओं के लिए दो अलग-अलग प्रारूप देख सकते हैं। उसकी वजह यहाँ है!
Crashlytics आपके ऐप से सभी ईवेंट का विश्लेषण करता है — क्रैश, गैर-घातक और ANR — और समान ईवेंट को अलग-अलग मुद्दों में समूहित करता है। जनवरी 2023 में, हमने आपके ऐप के कोड के आधार पर ईवेंट को समूहीकृत करने के लिए एक बेहतर विश्लेषण इंजन और नए मुद्दों को प्रदर्शित करने के लिए एक अपडेटेड डिज़ाइन शुरू किया।
यहां बताया गया है कि आप इन सुधारों के साथ क्या अनुभव करेंगे:
नया रूप दिया गया मेटाडेटा समस्या पंक्ति में प्रदर्शित होता है
अब आपके ऐप में समस्याओं को समझना और उनका चयन करना आसान हो गया है।कम डुप्लिकेट मुद्दे
एक पंक्ति संख्या परिवर्तन के परिणामस्वरूप कोई नई समस्या नहीं होती है।अधिक सार्थक अलर्ट और संकेत
एक नया मुद्दा वास्तव में एक नए बग का प्रतिनिधित्व करता है।अधिक शक्तिशाली खोज
प्रत्येक अंक में अधिक खोजने योग्य मेटाडेटा होता है, जैसे अपवाद प्रकार और पैकेज का नाम।
यहां बताया गया है कि ये सुधार कैसे शुरू हो रहे हैं:
जब हमें आपके ऐप से नए ईवेंट मिलते हैं, तो हम जाँच करेंगे कि क्या वे किसी मौजूदा समस्या से मेल खाते हैं।
यदि कोई मिलान नहीं होता है, तो हम स्वचालित रूप से अपने स्मार्ट इवेंट-ग्रुपिंग एल्गोरिद्म को ईवेंट पर लागू कर देंगे और संशोधित मेटाडेटा डिज़ाइन के साथ एक नया मुद्दा बना देंगे।
यह पहला बड़ा अपडेट है जो हम अपने इवेंट ग्रुपिंग में कर रहे हैं। यदि आपके पास प्रतिक्रिया है या कोई समस्या आती है, तो कृपया रिपोर्ट दर्ज करके हमें बताएं।
Crashlytics Android 11 और उसके बाद के संस्करण चलाने वाले उपकरणों से Android ऐप्स के लिए ANR रिपोर्टिंग का समर्थन करता है। ANRs ( getHistoricalProcessExitReasons ) एकत्र करने के लिए हम जिस अंतर्निहित API का उपयोग करते हैं, वह SIGQUIT या वॉचडॉग-आधारित दृष्टिकोणों की तुलना में अधिक विश्वसनीय है। यह API केवल Android 11+ डिवाइस पर उपलब्ध है।
Google Play और Crashlytics के बीच ANRs की गिनती के बीच बेमेल हो सकता है। यह ANR डेटा एकत्र करने और रिपोर्ट करने के तंत्र में अंतर के कारण अपेक्षित है। जब ऐप अगली बार शुरू होता है तो Crashlytics ANRs की रिपोर्ट करता है, जबकि Android Vitals ANR होने के बाद ANR डेटा भेजता है।
इसके अतिरिक्त, Google Play की तुलना में Crashlytics केवल Android 11+ चलाने वाले उपकरणों पर होने वाले ANR प्रदर्शित करता है, जो Google Play सेवाओं और डेटा संग्रह सहमति वाले उपकरणों से ANR प्रदर्शित करता है।
एलएलवीएम और जीएनयू टूलचैन में आपके ऐप की बायनेरिज़ के रीड-ओनली सेगमेंट के लिए अलग-अलग डिफ़ॉल्ट और उपचार हैं, जो फायरबेस कंसोल में असंगत स्टैक ट्रेस उत्पन्न कर सकते हैं। इसे कम करने के लिए, अपनी बिल्ड प्रक्रिया में निम्न लिंकर फ़्लैग जोड़ें:
यदि आप एलएलवीएम टूलचैन से
lldलिंकर का उपयोग कर रहे हैं, तो जोड़ें:-Wl,--no-rosegmentयदि आप GNU टूलचेन से
ld.goldलिंकर का उपयोग कर रहे हैं, तो जोड़ें:-Wl,--rosegment
यदि आप अभी भी स्टैक ट्रेस विसंगतियां देख रहे हैं (या यदि कोई भी फ़्लैग आपके टूलचैन से संबंधित नहीं है), तो इसके बजाय अपनी बिल्ड प्रक्रिया में निम्नलिखित को जोड़ने का प्रयास करें:
-fno-omit-frame-pointer
Crashlytics प्लगइन एक अनुकूलित ब्रेकपैड प्रतीक फ़ाइल जनरेटर को बंडल करता है। यदि आप ब्रेकपैड प्रतीक फ़ाइलों को उत्पन्न करने के लिए अपनी स्वयं की बाइनरी का उपयोग करना पसंद करते हैं (उदाहरण के लिए, यदि आप स्रोत से अपनी बिल्ड श्रृंखला में सभी मूल निष्पादनयोग्य बनाना पसंद करते हैं), निष्पादन योग्य पथ निर्दिष्ट करने के लिए वैकल्पिक symbolGeneratorBinary एक्सटेंशन गुण का उपयोग करें।
आप दो तरीकों में से एक में ब्रेकपैड सिंबल फ़ाइल जनरेटर बाइनरी का पथ निर्दिष्ट कर सकते हैं:
विकल्प 1 : अपनी
build.gradleफ़ाइल मेंfirebaseCrashlyticsएक्सटेंशन के माध्यम से पथ निर्दिष्ट करेंअपनी ऐप-लेवल
build.gradleफ़ाइल में निम्नलिखित जोड़ें: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") } } } } }विकल्प 2 : अपनी ग्रेडल गुण फ़ाइल में एक संपत्ति रेखा के माध्यम से पथ निर्दिष्ट करें
निष्पादन योग्य का पथ निर्दिष्ट करने के लिए आप
com.google.firebase.crashlytics.symbolGeneratorBinaryगुण का उपयोग कर सकते हैं।आप मैन्युअल रूप से अपनी ग्रेडल गुण फ़ाइल को अपडेट कर सकते हैं या फ़ाइल को कमांड लाइन के माध्यम से अपडेट कर सकते हैं। उदाहरण के लिए, कमांड लाइन के माध्यम से पथ निर्दिष्ट करने के लिए, निम्न की तरह कमांड का उपयोग करें:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
यदि आप निम्न अपवाद देखते हैं, तो संभव है कि आप DexGuard के ऐसे संस्करण का उपयोग कर रहे हैं जो Firebase Crashlytics SDK के साथ असंगत है:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
यह अपवाद आपके ऐप को क्रैश नहीं करता है लेकिन इसे क्रैश रिपोर्ट भेजने से रोकता है। इसे ठीक करने के लिए:
सुनिश्चित करें कि आप नवीनतम DexGuard 8.x रिलीज़ का उपयोग कर रहे हैं। नवीनतम संस्करण में वे नियम हैं जो Firebase Crashlytics SDK के लिए आवश्यक हैं।
यदि आप अपने DexGuard संस्करण को बदलना नहीं चाहते हैं, तो निम्न पंक्ति को अपने अस्पष्टता नियमों (अपनी DexGuard कॉन्फ़िगरेशन फ़ाइल में) में जोड़ने का प्रयास करें:
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
जब कोई ऐप किसी ऑबफसकेटर का उपयोग करता है जो फ़ाइल एक्सटेंशन को उजागर नहीं करता है, तो Crashlytics डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ प्रत्येक समस्या उत्पन्न करता है।
ताकि Crashlytics सही फ़ाइल एक्सटेंशन के साथ समस्या उत्पन्न कर सके, सुनिश्चित करें कि आपका ऐप निम्न सेटअप का उपयोग करता है:
- Android Gradle 4.2.0 या उच्चतर का उपयोग करता है
- R8 का उपयोग अस्पष्टता चालू के साथ करता है। अपने ऐप को R8 में अपडेट करने के लिए, इस दस्तावेज़ का पालन करें।
ध्यान दें कि ऊपर वर्णित सेटअप में अपडेट करने के बाद, आपको नई .kt समस्याएँ दिखाई देने लग सकती हैं जो मौजूदा .java समस्याओं के डुप्लिकेट हैं। उस परिस्थिति के बारे में अधिक जानने के लिए अक्सर पूछे जाने वाले प्रश्न देखें।
दिसंबर 2021 के मध्य से क्रैशलाइटिक्स ने कोटलिन का उपयोग करने वाले अनुप्रयोगों के लिए समर्थन में सुधार किया।
कुछ समय पहले तक, उपलब्ध पर्यवेक्षक फ़ाइल एक्सटेंशन को उजागर नहीं करते थे, इसलिए Crashlytics डिफ़ॉल्ट रूप से .java फ़ाइल एक्सटेंशन के साथ प्रत्येक समस्या उत्पन्न करता है। हालाँकि, Android Gradle 4.2.0 के रूप में, R8 फ़ाइल एक्सटेंशन का समर्थन करता है।
इस अद्यतन के साथ, Crashlytics अब यह निर्धारित कर सकता है कि ऐप के भीतर उपयोग की जाने वाली प्रत्येक कक्षा कोटलिन में लिखी गई है और समस्या हस्ताक्षर में सही फ़ाइल नाम शामिल करती है। यदि आपके ऐप में निम्न सेटअप है तो क्रैश को अब सही ढंग से .kt फ़ाइलों (जैसा उपयुक्त हो) के लिए जिम्मेदार ठहराया जाता है:
- आपका ऐप Android Gradle 4.2.0 या उच्चतर का उपयोग करता है।
- आपका ऐप R8 का उपयोग अस्पष्टता चालू होने के साथ करता है।
चूंकि नए क्रैश में अब उनके जारी किए गए हस्ताक्षरों में सही फ़ाइल एक्सटेंशन शामिल है, इसलिए आपको नए .kt मुद्दे दिखाई दे सकते हैं जो वास्तव में मौजूदा .java लेबल वाले मुद्दों के डुप्लिकेट हैं। फायरबेस कंसोल में, यदि कोई नया .kt मुद्दा किसी मौजूदा .java लेबल वाले मुद्दे का संभावित डुप्लिकेट है, तो हम आपकी पहचान करने और आपसे संवाद करने का प्रयास करते हैं।
क्रैश-मुक्त मान उन उपयोगकर्ताओं के प्रतिशत का प्रतिनिधित्व करता है, जो आपके ऐप से जुड़े थे, लेकिन किसी विशिष्ट समय अवधि में क्रैश नहीं हुए थे।
क्रैश-मुक्त उपयोगकर्ताओं के प्रतिशत की गणना करने का सूत्र यहां दिया गया है। इसके इनपुट मान Google Analytics द्वारा प्रदान किए जाते हैं।
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
जब कोई क्रैश होता है, तो Google Analytics एक
app_exceptionइवेंट प्रकार भेजता है और CRASHED_USERS उस ईवेंट प्रकार से जुड़े उपयोगकर्ताओं की संख्या का प्रतिनिधित्व करता है।ALL_USERS उन उपयोगकर्ताओं की कुल संख्या का प्रतिनिधित्व करता है, जो आपके द्वारा Crashlytics डैशबोर्ड के ऊपरी-दाएँ भाग में ड्रॉपडाउन मेनू से चुनी गई समयावधि के दौरान आपके ऐप से जुड़े रहे।
क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत समय के साथ एकत्रीकरण है, औसत नहीं।
उदाहरण के लिए, कल्पना करें कि आपके ऐप के तीन उपयोगकर्ता हैं; हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B और उपयोगकर्ता C कहेंगे। निम्न तालिका दर्शाती है कि कौन से उपयोगकर्ता प्रतिदिन आपके ऐप से जुड़े और उनमें से किस उपयोगकर्ता का उस दिन क्रैश हुआ था:
| सोमवार | मंगलवार | बुधवार | |
|---|---|---|---|
| वे उपयोगकर्ता जो आपके ऐप से जुड़े हैं | ए, बी, सी | ए, बी, सी | ए, बी |
| उपयोगकर्ता जो दुर्घटनाग्रस्त हो गया था | सी | बी | ए |
बुधवार को, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 50% है (2 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
आपके दो उपयोगकर्ता बुधवार को आपके ऐप से जुड़े थे, लेकिन उनमें से केवल एक (उपयोगकर्ता B) का कोई क्रैश नहीं हुआ था।पिछले 2 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 33.3% है (3 में से 1 उपयोगकर्ता क्रैश-मुक्त था)।
आपके तीन उपयोगकर्ता पिछले दो दिनों में आपके ऐप से जुड़े, लेकिन उनमें से केवल एक (उपयोगकर्ता C) का कोई क्रैश नहीं हुआ।पिछले 3 दिनों के लिए, आपके क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत 0% है (3 में से 0 उपयोगकर्ता क्रैश-मुक्त थे)।
आपके तीन उपयोगकर्ता पिछले तीन दिनों में आपके ऐप से जुड़े, लेकिन उनमें से शून्य का कोई क्रैश नहीं हुआ।
नोट्स परियोजना के सदस्यों को प्रश्न, स्थिति अद्यतन आदि के साथ विशिष्ट मुद्दों पर टिप्पणी करने की अनुमति देते हैं।
जब कोई प्रोजेक्ट सदस्य कोई नोट पोस्ट करता है, तो उसे उनके Google खाते के ईमेल के साथ लेबल किया जाता है। यह ईमेल पता, नोट के साथ, उन सभी प्रोजेक्ट सदस्यों के लिए दृश्यमान है, जिनके पास नोट देखने की पहुंच है।
निम्नलिखित नोट्स देखने, लिखने और हटाने के लिए आवश्यक एक्सेस का वर्णन करता है:
निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य मौजूदा नोट्स को देख और हटा सकते हैं और किसी मुद्दे पर नए नोट्स लिख सकते हैं।
- प्रोजेक्ट स्वामी या संपादक , Firebase व्यवस्थापक , गुणवत्ता व्यवस्थापक , या Crashlytics व्यवस्थापक
निम्न में से किसी भी भूमिका वाले प्रोजेक्ट सदस्य किसी मुद्दे पर पोस्ट किए गए नोट्स देख सकते हैं, लेकिन वे नोट को हटा या लिख नहीं सकते हैं।
- प्रोजेक्ट व्यूअर , फायरबेस व्यूअर , क्वालिटी व्यूअर या क्रैशलाइटिक्स व्यूअर
एकीकरण
यदि आपका प्रोजेक्ट Google मोबाइल विज्ञापन SDK के साथ Crashlytics का उपयोग करता है, तो संभव है कि क्रैश रिपोर्टर अपवाद संचालकों को पंजीकृत करते समय हस्तक्षेप कर रहे हों। समस्या को ठीक करने के लिए, disableSDKCrashReporting कॉल करके मोबाइल विज्ञापन SDK में क्रैश रिपोर्टिंग बंद करें।
आपके द्वारा Crashlytics को BigQuery से लिंक करने के बाद, आपके द्वारा बनाए गए नए डेटासेट आपके Firebase प्रोजेक्ट के स्थान की परवाह किए बिना स्वचालित रूप से संयुक्त राज्य अमेरिका में स्थित हैं।
मंच का समर्थन
Firebase Crashlytics NDK ARMv5 (armeabi) का समर्थन नहीं करता है। इस ABI के लिए समर्थन NDK r17 के रूप में हटा दिया गया था।
प्रतिगमन मुद्दे
जब आपने समस्या को पहले ही बंद कर दिया था, तो समस्या वापस आ गई थी, लेकिन Crashlytics को एक नई रिपोर्ट मिलती है कि समस्या फिर से हुई है। Crashlytics स्वचालित रूप से इन प्रतिगामी समस्याओं को फिर से खोल देता है ताकि आप उन्हें अपने ऐप के लिए उपयुक्त रूप से संबोधित कर सकें।
यहां एक उदाहरण परिदृश्य दिया गया है जो बताता है कि Crashlytics किसी समस्या को प्रतिगमन के रूप में कैसे वर्गीकृत करता है:
- पहली बार, Crashlytics को Crash "A" के बारे में क्रैश रिपोर्ट मिलती है। Crashlytics उस क्रैश (अंक "A") के लिए संबंधित समस्या खोलता है।
- आप इस बग को जल्दी से ठीक करें, अंक "ए" को बंद करें और फिर अपने ऐप का एक नया संस्करण जारी करें।
- आपके द्वारा समस्या बंद करने के बाद Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है।
- यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी), तो Crashlytics इस मुद्दे को वापस नहीं लेगा। मामला बंद रहेगा।
- यदि रिपोर्ट किसी ऐसे ऐप संस्करण से है जिसके बारे में Crashlytics को पता नहीं था जब आपने समस्या को बंद कर दिया था (जिसका अर्थ है कि संस्करण ने कभी भी किसी क्रैश के लिए कोई क्रैश रिपोर्ट नहीं भेजी थी), तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी .
जब कोई समस्या वापस आती है, तो हम एक रिग्रेशन डिटेक्शन अलर्ट भेजते हैं और समस्या में एक रिग्रेशन सिग्नल जोड़ते हैं ताकि आपको पता चल सके कि Crashlytics ने समस्या को फिर से खोल दिया है। यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।
यदि कोई रिपोर्ट किसी पुराने ऐप संस्करण से है जिसने समस्या को बंद करने के दौरान कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics को लगता है कि समस्या वापस आ गई है और समस्या को फिर से खोल देगी।
यह स्थिति निम्न स्थिति में हो सकती है: आपने एक बग ठीक कर लिया है और अपने ऐप का एक नया संस्करण जारी कर दिया है, लेकिन आपके पास अभी भी बग फिक्स के बिना पुराने संस्करणों पर उपयोगकर्ता हैं। यदि, संयोग से, उन पुराने संस्करणों में से एक ने कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी जब आपने समस्या को बंद कर दिया था, और उन उपयोगकर्ताओं को बग का सामना करना शुरू हो गया, तो वे क्रैश रिपोर्ट एक प्रतिगमन समस्या को ट्रिगर करेंगे।
यदि आप हमारे प्रतिगमन एल्गोरिथम के कारण किसी मुद्दे को फिर से नहीं खोलना चाहते हैं, तो समस्या को बंद करने के बजाय "म्यूट" करें।