तुम्ही Connect दाबता, प्रोफाइल एक सेकंद फिरते आणि क्लायंट जोडणी तुटल्याचे सांगतो. सपोर्ट लॉग मागतो, तुम्ही स्क्रीनशॉट जोडता आणि हँडशेकचा कोणता भाग हारला हे कोणीही सांगू शकत नाही म्हणून धागा दोन दिवस थांबतो. एका प्रयत्नाभोवती बांधलेला अहवाल, अरुंद वेळखिडकी आणि पूर्ण झालेला शेवटचा टप्पा यासह, तिकिट एका फेरीत पुढे नेतो. पर्याय, म्हणजे पूर्ण दिवसाचे फोन लॉग, सहसा समोरच्या व्यक्तीला पाहण्यासाठी जास्त जागा देतात.

एकाच गेटवेवरील दोन फोन वेगळे वागू शकतात, कारण प्रोटोकॉल, प्रमाणपत्र संग्रह, प्रमाणीकरण पद्धत किंवा रहदारी धोरण जुळत नसेल. माझ्या फोनवर चालते हे तुलनेची सुरुवात आहे, ॲंड्रॉइड बिघाडाचा पुरावा नाही.

एका दिवसाच्या इतिहासाऐवजी एक प्रयत्न टिपून घ्या

काहीही पुन्हा तयार करण्यापूर्वी वातावरण लिहून घ्या: ॲंड्रॉइड आवृत्ती, उत्पादक आणि मॉडेल, क्लायंटचे नाव आणि आवृत्ती, तुम्ही निवडलेले प्रोफाइल, तुम्ही जोडलेले आहात ते नेटवर्क, आणि टाइमझोनसह घड्याळाची वेळ. बॅटरी सेव्हर किंवा Data Saver सुरू आहे का हेही नोंदवतो, कारण दोन्ही स्क्रीन बंद झाल्यावर क्लायंट काय करू शकतो हे बदलतात.

मग पाचपैकी कोणता निकाल तुम्ही प्रत्यक्षात पाहत आहात ते ठरवा. संमती किंवा परवानगीची विंडो कधीही पूर्ण होत नाही, एंडपॉइंटपर्यंत अजिबात पोहोचता येत नाही, प्रमाणीकरण नाकारले जाते, यशस्वी लॉगिननंतर इंटरफेस सेटअप अयशस्वी होतो, किंवा टनेल वर येतो आणि एक विशिष्ट संसाधन पोहोचण्याबाहेर राहते. प्रत्येकाचा मालक वेगळा आणि उपाय वेगळा आहे, आणि हे मिसळणारे बंडल पुन्हा प्रयत्न करा असे उत्तर मिळवते. यांच्यात अंदाज लावणेच एका तासाचे तिकिट एका आठवड्याच्या पत्रव्यवहारात बदलते.

संक्रमणेही महत्त्वाची आहेत. जर बिघाड फक्त स्क्रीन लॉक झाल्यानंतर किंवा Wi-Fi वरून मोबाइल डेटावर गेल्यानंतर दिसत असेल, तर ते तिकिटाच्या पहिल्या ओळीत लिहा आणि कोणत्या मिनिटाला घडले ते नोंदवा.

प्रथम क्लायंटचा स्वतःचा लॉग निर्यात करा

पहिले संलग्नक ऑपरेटिंग सिस्टमऐवजी ॲपमधून आले पाहिजे. बहुतेक क्लायंट सेटिंग्जमध्ये निदान किंवा जोडणी-लॉग निर्यात देतात, कधीकधी आवृत्ती स्ट्रिंगवर दीर्घ दाबामागे लपलेले असते, आणि ते निर्यात आपली स्थिती-यंत्रणा आधीच समजते. मनोरंजक ओळी तिकिटाच्या मजकुरात पुन्हा टाइप करण्याऐवजी ते जसे येते तसे वापरा.

पहिली त्रुटी आणि त्याच्या लगेच आधीच्या घटना जोडा, फक्त शेवटची डिस्कनेक्ट ओळ नाही. स्वच्छ शेपटीचा अर्थ सहसा खरा बिघाड आधी झाला असतो: सत्यापित न झालेली प्रमाणपत्र साखळी, अनपेक्षित ठिकाणी सोडवलेले नाव, किंवा कधीही कॉन्फिगर न केलेला इंटरफेस.

ज्या प्रश्नाला तुम्ही नाव देऊ शकता त्यासाठीच logcat जोडा

फोनवरील टर्मिनल एम्युलेटर सिस्टम लॉगर नाही. ॲंड्रॉइड आपले बफर स्वतंत्र वर्तुळाकार प्रवाह म्हणून नोंदवते, जे केवळ विशेषाधिकारित प्रक्रिया पूर्ण वाचू शकतात. त्यामुळे सामान्य ॲपला स्वतःचे आउटपुट आणि मर्यादित तुकडा दिसतो, आणि logcat रिकामे होते हे विधान प्लॅटफॉर्मने काय नोंदवले याबद्दल फार थोडे सिद्ध करते.

समर्थित मार्ग म्हणजे तुम्ही नियंत्रित करता त्या संगणकावरून अधिकृत ADB सत्र. विकसक पर्याय आणि USB डीबगिंग सुरू करा, केबल जोडा, आणि डिव्हाइसवर RSA बोटांच्या ठशाचा संवाद स्वीकारा; ती विनंती बंद केली तर पुढील प्रत्येक आदेश unauthorized सह अयशस्वी होतो आणि कोणतेही कॅप्चर सुरू होत नाही.

कॅप्चरमध्ये वेळ घालवण्यापूर्वी डिव्हाइस खरोखर तिथे आहे याची खात्री करा. adb devices ने सीरियल क्रमांक आणि नंतर device शब्द छापला पाहिजे, आणि offline किंवा unauthorized दाखवणाऱ्या कोणत्याही गोष्टीला आधी केबल, विनंती किंवा ड्रायव्हर सुधारण्याची गरज आहे.

यादीत आल्यावर, Connect दाबण्याच्या काही सेकंद आधी कॅप्चर सुरू करा आणि क्लायंट हारल्यावर लगेच थांबा. जाणीवपूर्वक सुरू केलेले थेट कॅप्चर वीस मिनिटांनंतर घेतलेल्या डंपपेक्षा चांगले आहे, कारण वर्तुळाकार बफर आधीच फिरले आहेत आणि तुम्हाला हव्या असलेल्या सुरुवातीच्या ओळी गेल्या असू शकतात:

adb logcat -v threadtime -b main,system,crash > attempt.txt

VPN शब्दाऐवजी वेळ आणि टॅगनुसार फिल्टर करा

कॅप्चरमध्ये vpn शोधणे म्हणजे बिघाड समजावणारी ओळ गमावण्याचा सर्वात वेगवान मार्ग. प्रमाणपत्र सत्यापन, प्रक्रिया क्रॅश आणि कनेक्टिव्हिटी बदल अशा टॅगखाली नोंदले जातात जे कधीही VPN चा उल्लेख करत नाहीत, त्यामुळे कीवर्ड फिल्टर गोंगाट ठेवतो आणि पुरावा फेकून देतो.

आधी वेळखिडकी, नंतर प्राधान्य, नंतर टॅग अरुंद करा. जेव्हा ज्ञात क्षणानंतर काय घडले एवढेच हवे असेल, तेव्हा adb logcat -v threadtime -t '11-03 20:14:00.000' त्या बिंदूपासून अलीकडील शेपटी पुन्हा चालवते, आणि threadtime स्वरूप टाइमस्टॅम्प क्लायंटच्या स्वतःच्या निर्यातीशी तुलनीय ठेवते.

क्लायंट पॅकेज माहीत असल्यास टॅगचा अंदाज न लावता त्याची प्रक्रिया अनुसरा. adb shell pidof com.vendor.client PID परत करते आणि adb logcat --pid=1234 -v threadtime फक्त ती प्रक्रिया छापते, तर adb logcat -g प्रत्येक बफरमध्ये ओव्हरराइट सुरू होण्यापूर्वी किती जागा आहे हे दाखवते.

गुपिते लपवा, नंतर एक सुसंगत बंडल सुपूर्द करा

तुमच्या मशीनमधून काहीही बाहेर जाण्यापूर्वी पासवर्ड, टोकन, खाजगी की, सत्र कुकीज आणि संपूर्ण डिव्हाइस ओळखकर्ते काढून टाका. बिघाड वाचनीय करणारे त्रुटी कोड, घटनांचा क्रम आणि पत्ता संबंध ठेवा, कारण त्या मर्यादेनंतर स्वच्छ केलेले कॅप्चर कधीही फिल्टर न केलेल्या कॅप्चरइतकेच निरुपयोगी आहे.

मग अनेक वेगळ्या फाइलांऐवजी एक बंडल पाठवा: क्लायंट निर्यात, सुरुवात आणि थांब्याच्या वेळेने नाव दिलेली ADB विंडो, अयशस्वी टप्प्याचा दोन ओळींचा सारांश, आणि या यादीच्या वरची वातावरण नोंद. त्यातील काही भाग सार्वजनिकरित्या पोस्ट करता येत नसेल, तर पुरवठादाराचे खाजगी सपोर्ट चॅनेल वापरा आणि कोणत्या फाइलला ते चॅनेल हवे ते सांगा.

पाठवण्यापूर्वी चार गोष्टी तपासा. बंडल संपूर्ण दुपारऐवजी एक प्रयत्न व्यापते का? क्लायंट आणि सिस्टमचे टाइमस्टॅम्प ओव्हरलॅप होतात का? आणि त्यात अजूनही टोकन, पासवर्ड किंवा संपूर्ण ग्राहक ओळखकर्ता आहे का? आधी तो शेवटचा मुद्दा सुधारा, नंतर नवीन तिकिट न उघडता विद्यमान तिकिटात फाइल्स जोडा, जेणेकरून ते घेणारा पूर्वीचा संदर्भ टिकवेल.

संबंधित लेख