डायरी ऐप की क्रैश रिपोर्ट में क्या हो सकता है?

एक मानक क्रैश रिपोर्ट क्या दिखाती है?

एक स्टैक ट्रेस क्रैश से जुड़े फ़ंक्शन कॉल्स को सूचीबद्ध करता है। यह डेवलपर्स को संबंधित कोड पाथ का पता लगाने में मदद करता है, लेकिन आमतौर पर यह अपने आप में पूरी परिस्थितियों की व्याख्या नहीं करता या यह साबित नहीं करता कि उपयोगकर्ता क्या कर रहा था। रिपोर्ट ऐप और ऑपरेटिंग सिस्टम के वर्शन, डिवाइस मॉडल, क्रैश का समय और पर्यावरण के अन्य विवरणों की भी पहचान कर सकती हैं। Apple क्रैश रिपोर्ट को क्रैश के समय ऐप की स्थिति के रिकॉर्ड के रूप में वर्णित करता है और संपूर्ण ऑपरेटिंग-सिस्टम रिपोर्ट का विश्लेषण करने की सलाह देता है; इसका मार्गदर्शन डिवाइस, ऐप और OS जानकारी जैसे फ़ील्ड की पहचान करता है। Apple की [क्रैश रिपोर्ट विश्लेषण गाइड](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report) देखें।

रिपोर्ट का प्रारूप उसके स्रोत पर निर्भर करता है। Xcode के माध्यम से एकत्र की गई Apple क्रैश रिपोर्ट और Android बग रिपोर्ट अलग-अलग कलाकृतियाँ (artifacts) हैं। Android की आधिकारिक गाइड कहती है कि एक बग रिपोर्ट में डिवाइस लॉग, स्टैक ट्रेस, सिस्टम सेवाओं से डायग्नोस्टिक आउटपुट, त्रुटि लॉग और Android के `Log` वर्ग का उपयोग करने वाले ऐप के सिस्टम संदेश शामिल हो सकते हैं। यह केवल-क्रैश रिकॉर्ड से कहीं अधिक व्यापक है। किसी व्यक्तिगत रिपोर्ट की सामग्री अभी भी इस बात पर निर्भर करती है कि क्या एकत्र और शामिल किया गया था। [बग रिपोर्ट कैप्चर करने और पढ़ने के लिए Android की गाइड](https://developer.android.com/studio/debug/bug-report) देखें।

क्या रिपोर्ट में डायरी का टेक्स्ट शामिल हो सकता है?

कुछ कॉन्फ़िगरेशन के तहत ऐसा हो सकता है, लेकिन केवल क्रैश रिपोर्ट की उपस्थिति यह स्थापित नहीं करती है कि इसमें प्रविष्टि (entry) का टेक्स्ट शामिल है। मुख्य प्रश्न यह है कि ऐप क्रैश के साथ-साथ क्या रिकॉर्ड करता है और रिपोर्ट प्रारूप क्या कैप्चर करता है।

उदाहरण के लिए, ऐप डेवलपर्स डायग्नोस्टिक लॉग संदेश या कस्टम इवेंट जोड़ सकते हैं। यदि उन संदेशों में डायरी प्रविष्टि, शीर्षक, खोज शब्द या किसी संपादक से कॉपी किया गया टेक्स्ट शामिल है, तो वह जानकारी इवेंट के साथ जा सकती है। Sentry ब्रेडक्रंब (breadcrumbs) को किसी समस्या से पहले की घटनाओं के एक सिलसिले (trail) के रूप में वर्णित करता है; प्रत्येक में एक संदेश और मनमाना संरचित डेटा हो सकता है। ब्रेडक्रंब सक्षम एकीकरणों के माध्यम से स्वचालित रूप से एकत्र किए जा सकते हैं या किसी ऐप द्वारा जोड़े जा सकते हैं। [Sentry का ब्रेडक्रंब दस्तावेज़](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/) देखें। Android बग रिपोर्ट में सिस्टम संदेश लॉग भी शामिल होते हैं, जिनमें ऐप द्वारा लिखे गए संदेश हो सकते हैं। इन दोनों तथ्यों का यह मतलब नहीं है कि हर ऐप निजी टेक्स्ट को लॉग करता है: यह ऐप के कार्यान्वयन और कॉन्फ़िगरेशन पर निर्भर करता है।

लॉग, ब्रेडक्रंब, अटैचमेंट और रीप्ले क्या हैं?

ये शब्द अलग-अलग प्रकार के डायग्नोस्टिक डेटा को संदर्भित करते हैं। लॉग ऐप या सिस्टम द्वारा रिकॉर्ड किए गए संदेश होते हैं। ब्रेडक्रंब किसी त्रुटि से पहले की घटनाओं का एक चयनित क्रम होते हैं, जिसमें संभावित रूप से टाइमस्टैम्प, श्रेणियां, संदेश और की-वैल्यू डेटा शामिल होते हैं। ऐप क्या रिकॉर्ड करता है, इसके आधार पर दोनों एक स्टैक ट्रेस की तुलना में अधिक संदर्भ प्रकट कर सकते हैं।

अटैचमेंट किसी इवेंट के साथ भेजी गई फ़ाइलें होती हैं, जैसे लॉग फ़ाइल, स्क्रीनशॉट या क्रैश डंप। Sentry नोट करता है कि नेटिव मिनीडंप में संवेदनशील सामग्री हो सकती है जैसे पर्यावरण चर (environment variables), स्थानीय पथ, या इनपुट फ़ील्ड के इन-मेमोरी निरूपण। इसका दस्तावेज़ीकरण कहता है कि घटनाओं को बनाने के लिए मिनीडंप का उपयोग किया जाता है और डिफ़ॉल्ट रूप से हटा दिया जाता है, लेकिन यदि वह सेटिंग सक्षम है तो उन्हें अटैचमेंट के रूप में संग्रहीत किया जा सकता है; यह भी कहा गया है कि अटैचमेंट Sentry डेटा स्क्रबिंग द्वारा कवर नहीं किए जाते हैं। क्रैश डेटा पर [Sentry का दस्तावेज़ीकरण](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) और [अटैचमेंट](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/) देखें।

सेशन रीप्ले एक अलग, वैकल्पिक सुविधा है, न कि प्रत्येक क्रैश रिपोर्ट का एक मानक घटक। Sentry का JavaScript रीप्ले दस्तावेज़ ब्राउज़र गतिविधि के एक वीडियो जैसे पुनर्निर्माण का वर्णन करता है, जिसमें DOM स्थिति और इंटरैक्शन शामिल हैं। यह कहता है कि SDK डिफ़ॉल्ट रूप से DOM टेक्स्ट, छवियों और उपयोगकर्ता इनपुट को मास्क करता है, जबकि कॉन्फ़िगरेशन विकल्प भी प्रदान करता है। मास्किंग सेटिंग्स और समर्थित प्लेटफ़ॉर्म मायने रखते हैं: वास्तविक प्रदाता सेटअप और गोपनीयता कॉन्फ़िगरेशन की जाँच किए बिना यह अनुमान न लगाएं कि डायरी की सामग्री दृश्यमान है या सुरक्षित है। [Sentry की JavaScript सेशन रीप्ले गाइड](https://docs.sentry.io/platforms/javascript/session-replay/) देखें।

रिपोर्ट साझा करने से पहले आपको क्या समीक्षा करनी चाहिए?

वास्तविक फ़ाइल या रिपोर्ट पूर्वावलोकन पर इस चेकलिस्ट का उपयोग करें, और रिपोर्ट की सामग्री स्पष्ट न होने पर ऐप या प्रदाता के गोपनीयता दस्तावेज़ों की जाँच करें:

यह चेकलिस्ट डायरी उपयोगकर्ता के लिए रिपोर्ट भेजने से पहले उसकी समीक्षा करने हेतु व्यावहारिक संपादकीय मार्गदर्शन है। यह निर्माता के निर्देशों से अलग है: डेवलपर्स अपनी स्वयं की लॉगिंग, रीप्ले और अटैचमेंट सेटिंग्स को नियंत्रित करते हैं, और उन्हें यह दस्तावेजित करना चाहिए कि वे सुविधाएँ क्या एकत्र करती हैं और समीक्षा करनी चाहिए कि क्या डायग्नोस्टिक फ़ील्ड में उपयोगकर्ता द्वारा दर्ज की गई सामग्री हो सकती है।

विभिन्न ऐप्स और डिवाइसों के बीच रिपोर्टें भिन्न क्यों हो सकती हैं?

ऑपरेटिंग सिस्टम अलग-अलग रिपोर्ट प्रारूप और संग्रह पथ उत्पन्न करते हैं; डेवलपर्स कस्टम कॉन्फ़िगरेशन के साथ किसी तीसरे पक्ष के SDK का भी उपयोग कर सकते हैं। Apple का कहना है कि ऐप स्टोर और TestFlight क्रैश रिपोर्ट Xcode के माध्यम से उपलब्ध हैं, जबकि अन्य डायग्नोस्टिक लॉग को किसी डिवाइस से स्थानांतरित करने की आवश्यकता हो सकती है। Android पूर्ण बग रिपोर्ट को Google Play या Firebase जैसी सेवाओं के माध्यम से प्रदान की जाने वाली क्रैश रिपोर्ट से अलग करता है। प्रदाता सेटिंग्स आगे यह निर्धारित कर सकती हैं कि कौन सी घटनाएं, ब्रेडक्रंब, अटैचमेंट या रीप्ले डेटा कैप्चर और संग्रहीत किए जाते हैं। यह मानने के बजाय कि प्रत्येक सेवा समान फ़ील्ड भेजती है, ऐप के गोपनीयता नोटिस और वास्तविक रिपोर्ट को किसी विशेष मामले के मार्गदर्शक के रूप में मानें।

इस विषय को आगे पढ़ें