हैलो, हैकरून! मेरा नाम अलेक्जेंडर कारपेंको है, और मैं इनड्राइव में एक क्यूए इंजीनियर के रूप में काम करता हूं। मैंने यह लेख नौसिखिए क्यूए विशेषज्ञों के लिए तैयार किया है। नीचे, मैं आपको बताऊंगा कि मोबाइल एप्लिकेशन परीक्षण में एंड्रॉइड डिबग ब्रिज (एडीबी) का उपयोग कैसे करें और पहली जगह में इसकी आवश्यकता क्यों है।
मुझे लगता है कि आपको पहले से ही परीक्षण के बुनियादी ज्ञान का बुनियादी ज्ञान है, इसलिए मैं परियोजनाओं को तैयार करने और स्थापित करने की प्रक्रिया को छोड़ दूंगा।
एडीबी की क्षमताओं का लगातार विस्तार हो रहा है, लेकिन मैं कुछ मूल्यवान तकनीकों को साझा करूंगा जो आपके दैनिक कार्यप्रवाह में सुधार करेंगी। जैसा कि मेरी कहानी मोबाइल ऐप परीक्षण के बारे में है, मैं macOS पर ध्यान केंद्रित करूंगा, जो आपको सभी लोकप्रिय मोबाइल प्लेटफॉर्म के साथ प्रभावी ढंग से काम करने देता है। अन्य ऑपरेटिंग सिस्टम के लिए, उदाहरण थोड़े अलग हो सकते हैं, लेकिन उम्मीद है कि विंडोज उपयोगकर्ता इसे मेरे खिलाफ नहीं रखेंगे।
आरंभ करने के लिए, आइए यह सुनिश्चित करने के लिए सबसे बुनियादी आदेशों को स्पर्श करें कि बाद के बिंदु तार्किक क्रम में प्रस्तुत किए गए हैं।
आम तौर पर, हम एक डिवाइस के साथ काम करते हैं, लेकिन कभी-कभी कई डिवाइस कनेक्ट होते हैं, उदाहरण के लिए, टीसीपी/आईपी के माध्यम से। इस मामले में, हमें उस डिवाइस को मैन्युअल रूप से निर्दिष्ट करना होगा जिस पर हम कमांड चलाना चाहते हैं।
adb devices
- कनेक्टेड डिवाइसेस की सूची प्रदर्शित करता है ( -l
स्विच का उपयोग करके गुणों की एक विस्तृत सूची को खींचता है)। यह उपयोगी है यदि कई डिवाइस जुड़े हुए हैं और यह तुरंत स्पष्ट नहीं है कि हमें किसकी आवश्यकता है।
ADB को यह बताने के लिए कि किस उपकरण को लक्षित करना है, -s
स्विच के बाद डिवाइस का क्रमांक निर्दिष्ट किया जाना चाहिए:
adb -s <serial_number> <command>
, जहां <serial_number>
सूची से डिवाइस का सीरियल नंबर है और <command>
डिवाइस पर निष्पादित करने के लिए कमांड है।
उदाहरण के लिए, सूची से किसी विशिष्ट डिवाइस पर एप्लिकेशन इंस्टॉल करना:
adb -s 32312b96 install user/download/app.apk
एक और लगातार परिदृश्य तब होता है जब ऑपरेशन में एक साथ एक वास्तविक डिवाइस और एक एमुलेटर शामिल होता है, उदाहरण के लिए, निष्पादक/प्रवर्तक की विभिन्न भूमिकाओं के लिए। इस मामले में, डिवाइस आसानी से उनके सीरियल नंबर से नहीं बल्कि adbcommand के बाद —d —e
स्विच पर आधारित होते हैं। उदाहरण:
adb —d install user/download/app.apk
— कमांड को वास्तविक डिवाइस पर निष्पादित किया जाएगा, एमुलेटर पर —е
स्विच के साथ।
हम डिवाइस को टीसीपी/आईपी पर भी कनेक्ट कर सकते हैं जब वह उसी वाई-फाई नेटवर्क का उपयोग करता है। ऐसा करने के लिए, डिवाइस को केबल से पीसी से कनेक्ट करें और कमांड का उपयोग करके डिवाइस पर ऑपरेटिंग मोड को यूएसबी से टीसीपी/आईपी में बदलें:
adb tcpip 5555
उदाहरण के लिए, सामान्य सूचना में या कमांड के साथ फोन सेटिंग्स के माध्यम से:
adb shell ifconfig wlan0
यदि आपका डिवाइस इस समय पीसी से पहले ही डिस्कनेक्ट हो चुका है, तो डिवाइस के एस/एन को अतिरिक्त रूप से निर्दिष्ट करना सुनिश्चित करें। अगला, हम इससे जुड़ते हैं:
adb connect ip_address:5555
डिवाइस को कमांड के साथ अक्षम किया जा सकता है:
adb disconnect ip_address:5555
adb disconnect
- हमारे सभी टीसीपी/आईपी उपकरणों को अक्षम करने के लिए।
USB मोड पर लौटने के लिए, कमांड का उपयोग करें:
adb usb
(लोअरकेस महत्वपूर्ण है)।
कमांड का उपयोग करके एप्लिकेशन इंस्टॉल किया गया है:
adb install <apk_path>
, जहां <apk_path>
हमारी एपीके एप्लिकेशन फ़ाइल का पूर्ण पथ है।
इंस्टॉल कमांड के बाद अक्सर उपयोग किए जाने वाले कुछ उपयोगी स्विच यहां दिए गए हैं:
—d
— डाउनग्रेड किए गए संस्करण के साथ पुनः स्थापित करता है। अन्यथा, एक विफलता होगी (त्रुटि) [INSTALL_FAILED_VERSION_DOWNGRADE]
)।
—r
— सहेजे गए डेटा के साथ एप्लिकेशन को फिर से इंस्टॉल करता है।
—g
— संस्थापन प्रक्रिया के दौरान अनुप्रयोग मेनिफेस्ट में निर्दिष्ट सभी अनुमतियाँ देता है।
उदाहरण के लिए, इस स्विच के साथ इंस्टॉल किया गया ऐप आपको फोटो डाउनलोड करने के लिए जियोलोकेशन या स्टोरेज स्पेस तक पहुंच की अनुमति देने के लिए नहीं कहेगा।
पैकेज के नाम के आधार पर एप्लिकेशन को अनइंस्टॉल कर दिया गया है। ऐसा करने के लिए, आपको यह जानना होगा कि सिस्टम में एप्लिकेशन कैसे पंजीकृत है। शेल और पैकेज मैनेजर (दोपहर) का उपयोग करें।
सभी स्थापित अनुप्रयोगों की सूची प्रदर्शित करने के लिए निम्न आदेश चलाएँ:
adb shell pm list packages
सूची को एप्लिकेशन के नाम से फ़िल्टर किया जा सकता है। सूची काफी बड़ी होने पर आपको इसकी आवश्यकता होगी, लेकिन हम जानते हैं कि पैकेज के नाम में कौन सा शब्द निहित है:
adb shell pm list packages | grep com.myApp
आप एक अलग फ़ाइल में आउटपुट भी कर सकते हैं और वहां आवश्यक पैकेज ढूंढ सकते हैं:
adb shell pm list packages > /Users/username/packages.txt
अब जब हम जानते हैं कि एप्लिकेशन पैकेज के नाम का पता कैसे लगाया जाए, तो आइए इसे डिवाइस से निकालने के तरीके पर वापस जाएं। यह कमांड का उपयोग करके किया जा सकता है:
adb uninstall com.myApp
adb uninstall -k com.myApp
- एप्लिकेशन को हटाता है लेकिन डेटा और कैशे फाइलों को बचाता है।
मैं अलग से एक आदेश प्रस्तुत करूंगा जो अक्सर उपयोगी साबित हो सकता है:
adb shell pm clear com.myApp
— ऐप के कैशे और डेटा को साफ करता है।
मुझे लगता है कि यह एक दुर्लभ स्थिति है। लेकिन यह किसी के काम आ सकता है, जैसा कि एक बार मेरे लिए किया था। सभी इंस्टॉल किए गए एप्लिकेशन अपनी एपीके फाइलों को /data/appfolder में स्टोर करते हैं। चूंकि आप पैकेज का नाम जानते हैं, आप उस स्थान को ढूंढ सकते हैं जहां एप्लिकेशन इंस्टॉल किया गया है और वहां से इसका एपीके डाउनलोड करें। ऐसा करने के लिए, निम्न आदेश चलाएँ:
adb shell pm path com.myApp
— अनुप्रयोग की संस्थापन निर्देशिका प्रदर्शित करता है।
यह सब प्रस्तुत करने योग्य नहीं लग सकता है:
package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk
लेकिन ठीक ऐसा ही हमें देखने के लिए इस पथ की आवश्यकता है। आइए थोड़ा आगे बढ़ते हैं और देखते हैं कि हम जिस फाइल की जरूरत है उसे फोन से पीसी में कैसे कॉपी कर सकते हैं। यह कमांड का उपयोग करके किया जा सकता है:
adb pull <crazyPath> /Users/username/
, जहां <crazyPath>
हमारे पिछले कमांड का आउटपुट है, /Users/username/
पीसी पर वह पाथ है जहां आप हमारी फाइल को कॉपी करना चाहते हैं।
आइए संक्षेप में टेक्स्ट फ़ील्ड्स की जाँच के बारे में बात करते हैं। उदाहरण के लिए, आपको टेक्स्ट फ़ील्ड में दर्ज किए जा सकने वाले वर्णों की अधिकतम संख्या की सीमा की जांच करनी होगी। यदि आप एक ही उपकरण का उपयोग करते हैं, तो स्थानांतरित डेटा के विभिन्न सेट फोन पर या क्लाउड में संग्रहीत किए जा सकते हैं। हालाँकि, यदि परीक्षण विभिन्न उपकरणों पर किया जाना है, तो परीक्षण डेटा को पीसी पर संग्रहीत किया जा सकता है और निम्नलिखित आदेशों के माध्यम से उपकरणों में स्थानांतरित किया जा सकता है:
adb shell input text <text>
उदाहरण:
adb shell input text test%stest
— स्ट्रिंग "टेस्ट टेस्ट" दर्ज किया जाएगा। स्पेस को स्पेशल कैरेक्टर %s
से बदलें, अन्यथा, स्पेस से पहले का हिस्सा ही डिवाइस को भेजा जाएगा। यदि हम ट्रांसमिट किए जा रहे टेक्स्ट में !@#
जैसे विशेष वर्णों का उपयोग करते हैं, तो उन्हें उनके सामने एक बैकस्लैश ( \
) डालकर चिह्नित करना होगा।
उदाहरण के लिए, आदेश:
adb shell input text test\!\@\#\$%stest
स्क्रीन पर “test!@#$ test”
प्रदर्शित करेगा
(एडीबी सिरिलिक वर्णों के साथ काम नहीं करता है और एक NullPointerException त्रुटि उत्पन्न करता है)।
क्लिपबोर्ड की सामग्री को इस तरह स्थानांतरित किया जा सकता है:
adb shell input text $(pbpaste)
ध्यान रखें कि कुछ वर्ण पीसी पर दिखाई देने पर प्रसारित नहीं हो सकते हैं। स्ट्रीमिंग टेक्स्ट एडिटर (sed) का उपयोग करके समस्या का समाधान किया जा सकता है। यहां एक विस्तारित कमांड का उदाहरण दिया गया है जहां हम बफर में सभी रिक्त स्थान को विशेष वर्णों के साथ बदलते हैं, हमें यह सुनिश्चित करने के लिए आवश्यक है कि टेक्स्ट सही तरीके से डिवाइस में स्थानांतरित हो:
adb shell input text $(pbpaste | sed -e 's/ /\%s/g')
pbpaste
वह टेक्स्ट है जो बफर में निहित है।
”—e”
स्विच- आपको टेक्स्ट संपादित करने के लिए आवश्यक कमांड निष्पादित करने की अनुमति देता है।
“s/take this/change_it_to/option”
उपयोग करने के लिए टेम्पलेट (पैटर्न) है।
/g
बिना किसी अपवाद के किसी विशेष टेम्पलेट के लिए सभी मैचों को बदलने के लिए ध्वज है।
आइए ध्यान रखें कि यह सबसे अच्छा है जब परीक्षण यथासंभव वास्तविक जीवन के करीब के वातावरण में किया जाता है, लेकिन यह जानना सहायक होता है कि यह विकल्प भी उपलब्ध है।
यह रणनीति आपको आवश्यक स्क्रीन के गहरे लिंक की जांच करने में मदद करेगी, जब कई स्क्रीन का उपयोग किया जाता है, या यदि हमें बुनियादी ढांचे की समस्या है और कोई पुश नोटिफिकेशन नहीं आता है, या यदि उनमें से कोई भी अभी तक नहीं आया है, लेकिन आपको यह जांचने की आवश्यकता है कि कैसे आवेदन व्यवहार करता है।
आप यह देखने के लिए भी जांच कर सकते हैं कि क्या एप्लिकेशन सही ढंग से काम करता है और पुश नोटिफिकेशन अलर्ट में कोई अमान्य डीप लिंक दिखाई देने पर क्रैश नहीं होता है। या ऐसी स्थिति से निपटते समय जब हम किसी ऐसी स्क्रीन के डीप लिंक का अनुसरण करते हैं जो अब मौजूद नहीं है, या जिसकी स्थिति बदल गई है, या यदि हमें उस स्क्रीन तक पहले स्थान पर पहुंच नहीं मिलनी चाहिए, क्योंकि पुश अलर्ट में रहा है लंबे समय तक सूचनाएं। ऐसी कई स्थितियां हो सकती हैं।
शेल ADB में, हम कमांड को निष्पादित करने के लिए एक्टिविटी मैनेजर (AM) का उपयोग कर सकते हैं।
हम अपनी गतिविधि शुरू करते हैं और डीप लिंक भेजते हैं जिसे हम जांचना चाहते हैं। डीप लिंक में आमतौर पर "&" वर्ण होता है, जो स्क्रीन को अलग करता है। इसलिए, टर्मिनल के माध्यम से खोलते समय, इसके सामने एक बैकस्लैश (\) डालना पड़ता है।
adb shell am start -W -a android.intent.action.VIEW -d “myApp://open/client/trip\&last_trip=test” com.myApp
am
— एक्टिविटी मैनेजर को कॉल करता है।
W
- कमांड निष्पादित करने से पहले डाउनलोड की प्रतीक्षा कर रहा है।
a
- निर्धारित करता है कि कौन सी कार्रवाई की जानी है। इस मामले में, यह क्रिया है। देखें।
d
- रन के लिए आवश्यक डेटा। इस मामले में, हम स्वयं डीप लिंक और फिर उस एप्लिकेशन के बारे में बात कर रहे हैं जिसका उपयोग इसे खोलने के लिए किया जाना चाहिए।
कमांड को टर्मिनल पर स्थानांतरित करते समय आपको मैन्युअल रूप से उद्धरण चिह्नों को फिर से सम्मिलित करना पड़ सकता है या उन्हें सिंगल कोट्स से बदलना पड़ सकता है। यदि कोई सिंटैक्स त्रुटि है, तो आपको एक उपयुक्त संदेश मिल सकता है।
स्क्रीनशॉट लेने के लिए इस कमांड का उपयोग करें:
adb shell screencap -p <device_path/screenshot_name.png>
उदाहरण:
adb shell screencap -p /sdcard/screencap.png
— एक स्क्रीनशॉट लेता है और screencap.png
नाम की फाइल को डिवाइस पर /sdcard/screencap.png
फ़ोल्डर में सेव करता है।
आप अपने कंप्यूटर पर स्क्रीनशॉट को इस प्रकार सहेज सकते हैं:
adb pull /sdcard/screencap.png
— डिफ़ॉल्ट रूप से, फ़ाइल को वर्तमान उपयोगकर्ता की निर्देशिका में कॉपी किया जाता है, अर्थात /Users/username/screencap.png
।
या आप एक ही बार में पूरी कमांड चला सकते हैं:
adb shell screencap -p /sdcard/screencap.png && adb pull /sdcard/screencap.png
ADB के नवीनतम संस्करणों में, स्क्रीनशॉट प्राप्त करने के लिए निम्न कमांड का उपयोग किया जा सकता है:
adb exec—out screencap —p > screen.png
— स्क्रीनशॉट फ़ाइल पीसी पर वर्तमान उपयोगकर्ता की निर्देशिका में भी दिखाई देगी।
डिफ़ॉल्ट पथ को कमांड के अंत में जोड़कर मैन्युअल रूप से बदला जा सकता है:
adb exec—out screencap -p > downloads/test/screen.png
— और स्क्रीनशॉट /Users/username/downloads/test/screen.png
फ़ोल्डर में दिखाई देगा।
यदि दिलचस्पी है, तो आप bash_profile
में उपनाम जोड़कर इस प्रक्रिया को थोड़ा स्वचालित भी कर सकते हैं। MacOS में, आप हॉटकी बनाने और सेट करने के लिए Automator Service का उपयोग कर सकते हैं।
वीडियो रिकॉर्ड करने के लिए इस कमांड का उपयोग करें:
adb shell screenrecord device_path
।
उदाहरण:
adb shell screenrecord /sdcard/screenrecord.mp4
— तीन मिनट के लिए डिफॉल्ट सेटिंग्स के आधार पर डिवाइस स्क्रीन को रिकॉर्ड करना शुरू करने के लिए इस कमांड का उपयोग करें, और परिणाम को डिवाइस पर फाइल /sdcard/screenrecord.mp4
में सेव करें।
आप —time—limit time
स्विच (सेकंड में, लेकिन रिकॉर्डिंग की लंबाई अभी भी 180 सेकंड तक सीमित है) का उपयोग करके रिकॉर्डिंग समय को मैन्युअल रूप से निर्दिष्ट कर सकते हैं।
CTRL + C
दबाकर रिकॉर्डिंग को समय से पहले रोका जा सकता है
फ़ाइल को स्क्रीनशॉट प्रक्रिया के समान ही पुल कमांड का उपयोग करके भी कॉपी किया जा सकता है।
आप --help
स्विच का उपयोग करके इस उपयोगिता की अतिरिक्त विशेषताओं को भी देख सकते हैं। संयोग से, यह रिकॉर्डिंग रिज़ॉल्यूशन और बिटरेट को बदलने में सक्षम है, साथ ही बग रिपोर्ट के लिए अतिरिक्त डेटा भी जोड़ सकता है।
-bugreport
स्विच का उपयोग करना सहायक होता है, जो वीडियो में पहले फ्रेम के रूप में रिकॉर्डिंग के लिए उपयोग किए जाने वाले सिस्टम के बारे में जानकारी जोड़ता है।
अब जबकि हमने यह कवर कर लिया है कि डिवाइस से कुछ सामग्री कैसे डाउनलोड की जाए, आइए इस पर थोड़ा ध्यान दें कि इसमें कुछ कैसे अपलोड किया जाए।
हमने इसे अपने पीसी पर खोला, प्रारूप और सामग्री को समायोजित किया, हमारे फोन पर एक डाउनलोड किया, और यह सुनिश्चित करने के लिए जांच की कि एप्लिकेशन अज्ञात प्रारूपों के लिए सही ढंग से प्रतिक्रिया करता है और सीमा को बड़ा करता है। अपने पीसी से अपने फोन पर फाइल अपलोड करने के लिए, आप इस कमांड का उपयोग कर सकते हैं:
adb push /Users/username/file <device_path>
आइए कमांड चलाते हैं:
adb push /Users/username/screen.png sdcard
— यह हमारी screen.png
फाइल को फोन के एसडी कार्ड में कॉपी कर देगा।
अनुभव से एक और उदाहरण यह देखने के लिए जांच से संबंधित है कि सिस्टम द्वारा हटाए जाने के बाद ऐप की स्थिति को बहाल कर दिया गया है या नहीं। एप्लिकेशन को संक्षिप्त करें, प्रक्रिया को मारें - यह क्रिया उस स्थिति का अनुकरण करती है जब सिस्टम प्रक्रिया को रोक देता है क्योंकि पर्याप्त मेमोरी उपलब्ध नहीं है:
adb shell am kill com.myApp
इसे फिर से चलाएं और देखें कि सब कुछ ठीक काम कर रहा है या नहीं।
हम इस परिदृश्य में आए: एक उपयोगकर्ता एक निश्चित स्क्रीन पर एक एप्लिकेशन को छोटा करता है। कुछ समय बाद, सिस्टम प्रक्रिया को धीमा कर देता है और इसकी स्थिति को कैश कर देता है। जब उपयोगकर्ता एप्लिकेशन का विस्तार करने का प्रयास करता है, तो यह क्रैश हो जाता है। यह तब होता है जब कैश से डेटा एक्सेस किया जाता है, क्योंकि टुकड़े अपने स्टैक और स्थिति को बहाल कर रहे हैं, लेकिन कैश पहले से ही खाली है। दुर्भाग्य से, इस बग को परीक्षण चरण के दौरान अनदेखा कर दिया गया था, क्योंकि हमने पहले इसका सामना नहीं किया था, और इसलिए यह उत्पादन में समाप्त हो गया। अब जब आप जानते हैं कि यह संभव है, तो आप यह सुनिश्चित कर सकते हैं कि आप हमारी गलतियों को न दोहराएं।
किसी एप्लिकेशन के क्रैश होने के कारण का पता लगाने का प्रयास करते समय लॉग की जांच करना एक अच्छा विचार है। यदि आप वर्तमान लॉग बफर सामग्री को सहेजना चाहते हैं, तो यह निम्न आदेश का उपयोग करके किया जा सकता है:
adb logcat
— वास्तविक समय में लॉग प्रदर्शित करता है।
adb logcat —d
— डिवाइस पर वास्तविक घटनाओं को जोड़े बिना, कमांड चलाने के समय लॉग जानकारी प्रदर्शित करता है। कमांड का उपयोग करके लॉग को एक अलग फ़ाइल में आउटपुट करना भी संभव है: adb logcat —d > file.log
(फ़ाइल वर्तमान उपयोगकर्ता की निर्देशिका में बनाई गई है)।
और कमांड adb logcat >> file.log
डिवाइस पर सभी वास्तविक घटनाओं को जोड़ते हुए, सीधे फाइल में लॉग लिखेगा।
प्राथमिकता के आरोही क्रम में कई स्तर हैं: वी - वर्बोज़, डी - डीबग, आई - जानकारी, डब्ल्यू - चेतावनी, ई - त्रुटि, एफ - घातक, एस - साइलेंट, उदाहरण के लिए:
adb logcat '*:E'
- त्रुटियों के साथ लॉग आउटपुट करेगा और एक उच्च स्तर।
अब आउटपुट स्वरूपण और फिल्टर पर संक्षेप में ध्यान दें। आप आउटपुट के प्रारूप को -v स्विच का उपयोग करके कंसोल में बदल सकते हैं, उदाहरण के लिए:
adb logcat -v time
- समय बिंदुओं को रिकॉर्ड करके क्रमिक रूप से लॉग आउटपुट करता है।
adb logcat -v color
— लॉग के प्रत्येक स्तर को एक अलग रंग में प्रदर्शित करता है (जो पढ़ते समय सहायक होता है)।
adb logcat -v brief
— प्रक्रिया प्राथमिकता, टैग और PID प्रदर्शित करता है।
प्रत्येक लॉग संदेश में एक टैग और उससे संबंधित प्राथमिकता होती है। आप कंसोल में आउटपुट की मात्रा को कम करने के लिए उनका उपयोग कर सकते हैं:
adb logcat SwrveSDK:I '*:S'
— हमारे द्वारा swrve सेवा के माध्यम से भेजे जाने वाले एनालिटिक्स ईवेंट प्रदर्शित करेगा। *:S (-s)
पैरामीटर इंगित करता है कि लॉग आउटपुट हमारे द्वारा स्पष्ट रूप से निर्दिष्ट फ़िल्टर अभिव्यक्ति तक सीमित है।
और हमेशा की तरह, आप आउटपुट को फ़िल्टर करने के लिए grep उपयोगिता का उपयोग कर सकते हैं:
adb logcat '*:E' —v color | grep com.myApp
परंपरागत रूप से, अधिक जानकारी के लिए, आप हमेशा अपने सहायक adb logcat --help
. की ओर रुख कर सकते हैं
उदाहरण के लिए, यदि डिवाइस कनेक्ट नहीं होने पर बग को पुन: उत्पन्न किया जाता है, तो आप इसे तुरंत कनेक्ट कर सकते हैं और लॉग को फ़ाइल में रीडायरेक्ट कर सकते हैं।
आगे डिबगिंग के लिए, लॉग एकत्र करने से पहले, आप अनावश्यक डेटा को खत्म करने के लिए बग को पुन: उत्पन्न करने से पहले लॉग बफर को पूर्व-साफ़ कर सकते हैं। यह कमांड के माध्यम से किया जा सकता है:
adb logcat —c
, फिर हम बग को पुन: उत्पन्न करते हैं और adb logcat —d
. चलाते हैं
उन लोगों के लिए जो लॉग के ढेर के माध्यम से खोदना पसंद करते हैं, एक और उपकरण पर विचार करना है - एडीबी बग्रेपोर्ट। यह उपकरण आपको सादे पाठ प्रारूप ( .txt
) में पूर्ण डिबगिंग जानकारी के साथ ज़िप संग्रह बनाने की अनुमति देता है।
adb bugreport /Users/username
— निर्दिष्ट निर्देशिका में एक ज़िप संग्रह बनाता है।
डिवाइस के बारे में सभी जानकारी, जैसे कि डंपस्टेट, डंपसिस और लॉगकैट डेटा को निर्दिष्ट फ़ोल्डर में कॉपी करता है। डिफ़ॉल्ट रूप से, त्रुटि रिपोर्ट /bugreports में संग्रहीत की जाती हैं और इन्हें इसके माध्यम से देखा जा सकता है:
adb shell ls /bugreports/
हमारे लिए सबसे महत्वपूर्ण जानकारी bugreport-BUILD_ID-DATE.txt
. में संग्रहित है
क्रैश मॉनिटरिंग और ANR (एप्लिकेशन नॉट रिस्पॉन्डिंग) क्रैश के साथ काम करने के लिए एक और दिलचस्प टूल है। इस आदेश का उपयोग करके इसे चलाएँ:
adb shell am monitor
, और फिर हम अपने क्रैश को पुन: उत्पन्न करते हैं। कंसोल बिना किसी अनावश्यक विवरण के दुर्घटना के बारे में जानकारी प्रदर्शित करेगा और हमारे निगरानी प्रयासों को जारी रखने के लिए तीन विकल्प प्रदर्शित करेगा: (c)ontinue: show crash dialog, (k)ill: immediately kill app, (q)uit: finish monitoring
।
कॉन्फ़िगर किए गए एमुलेटर की सूची प्रदर्शित करना:
emulator -list-avds
हमें जिस एमुलेटर की आवश्यकता है उसे चलाना:
emulator @avdname
एमुलेटर के साथ काम करते समय, कभी-कभी सेवाओं को पुनरारंभ करना आवश्यक होता है, और एमुलेटर शुरू होने के बाद सर्वर को रीसेट करना होगा, लेकिन अक्सर एक कमांड भी पर्याप्त होता है: adb kill-server
। यदि यह मदद नहीं करता है, तो पूरी स्क्रिप्ट चलाएँ:
emulator -list-avds
- कॉन्फ़िगर किए गए एमुलेटर की एक सूची प्रदर्शित करता है।
adb kill-server
- सर्वर को रोकता है।
emulator -avd avdname
(या emulator @avdname
) - जहां avdname
एमुलेटर का नाम है।
adb start—server
— सर्वर को पुनरारंभ करता है।
adb devices
- कनेक्टेड डिवाइस की सूची प्रदर्शित करता है जहां हमारा खोया हुआ एमुलेटर दिखाई देना चाहिए।
आप में से सबसे आलसी के लिए, कमांड लाइन से एक एमुलेटर बनाया जा सकता है। उदाहरण के लिए, निम्न आदेश एपीआई 25 के साथ x86 सिस्टम छवि का उपयोग करके "टेस्ट" नामक एक एमुलेटर बनाता है::
avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"
यदि वांछित छवि उपलब्ध नहीं है, तो आप इसे कमांड के साथ प्री-इंस्टॉल कर सकते हैं:
sdkmanager --install "system—images;android—25;google_apis;x86"
sdkmanager --list | grep system—images
— डाउनलोड के लिए उपलब्ध छवियों की सूची प्रदर्शित करता है
एमुलेटर के साथ, "प्रेत" समस्याएं भी कभी-कभी ऑपरेशन के दौरान होती हैं, और एक अक्सर इस्तेमाल किया जाने वाला कमांड जो यहां मदद करता है, स्वचालित स्नैपशॉट को खींचे बिना एमुलेटर को "कोल्ड-बूट" करना है। आउटपुट पर बनाया गया स्नैपशॉट इस प्रकार होगा:
emulator @avdname —no—snapshot—load
एमुलेटर शुरू करते समय विचार करने के लिए यहां कुछ और उपयोगी स्विच दिए गए हैं:
-no-snapshot-save
- कोई स्वचालित स्नैपशॉट सहेजा नहीं जाएगा
-no-snapshot
- कोई स्नैपशॉट डाउनलोड या सहेजा नहीं जाएगा
यदि एमुलेटर अभी भी ठीक से काम नहीं करता है, तो इसे उस स्विच का उपयोग करके साफ़ किया जा सकता है जो एमुलेटर को उसकी मूल स्थिति में लौटाता है: -wipe-data
डिवाइस की विभिन्न अवस्थाओं को सहेजने के लिए स्नैपशॉट निर्माण एक बहुत ही उपयोगी विशेषता है। मैन्युअल रूप से, यह एमुलेटर सेटिंग्स के माध्यम से या इस कमांड को चलाकर किया जा सकता है:
adb emu avd snapshot save test
- एमुलेटर की स्थिति को बचाता है जहां परीक्षण डिवाइस पर संग्रहीत किए जाने वाले स्नैपशॉट का नाम है
emulator @avdname —snapshot—list
— हमारे @avd नाम के एमुलेटर को चलाता है और कंसोल में स्नैपशॉट सूची प्रदर्शित करता है
इसके बाद, आप इस आदेश का उपयोग करके पहले से सहेजे गए स्नैपशॉट को लोड कर सकते हैं:
adb emu avd snapshot load test
- जहां परीक्षण पहले से सहेजे गए स्नैपशॉट का नाम है
adb emu avd snapshot delete test
- टेस्ट नाम के स्नैपशॉट को हटाता है
हमारे लिए आवश्यक स्नैपशॉट के साथ एमुलेटर को तुरंत चलाना भी संभव है:
emulator @avdname -snapshot test
आप डिवाइस से स्नैपशॉट प्राप्त करने के लिए pull
कमांड का भी उपयोग कर सकते हैं:
adb emu avd snapshot pull test /Users/username/
हमारे एमुलेटर को telnet
कंसोल के माध्यम से संचालित किया जा सकता है। लेकिन पहले आपको इसे इंस्टॉल करना होगा। ऐसा करने का सबसे आसान तरीका brew
पैकेज प्रबंधक के माध्यम से है, यदि आपके पास है। यदि नहीं, तो यह पता लगाने का समय है कि यह क्या है और इसका उपयोग कैसे करना है। तो, कमांड का उपयोग करके telnet
स्थापित करें: brew install telnet.
अगला, हमारे एमुलेटर को चलाएं, और टर्मिनल के दूसरे टैब में, इसे कमांड से कनेक्ट करें: telnet localhost port,
उदाहरण:
telnet localhost 5554
- हमारे एमुलेटर से जुड़ता है जो पोर्ट 5554 . का उपयोग करता है
कमांड को पूरा करने के बाद, हम अपने एमुलेटर के साथ सभी प्रकार की उपयोगी चीजें कर सकते हैं, जिसमें जियो के साथ काम करना शामिल है (उदाहरण के लिए, कमांड geo fix 40.748840 -73.984279
निर्दिष्ट निर्देशांक पर हमारा वांछित स्थान सेट करेगा), नेटवर्क या बैटरी, जबकि ए हमेशा की तरह आदेशों की पूरी सूची मदद के माध्यम से पाई जा सकती है।
उदाहरण के लिए, स्नैपशॉट के साथ समान प्रक्रिया कुछ हद तक सरल है, जबकि पिछले अनुभाग में उल्लिखित कमांड को avd snapshot <command>
में घटा दिया गया है।
विंडो मैनेजर (wm) के पास यह सुनिश्चित करने के लिए कुछ उपयोगी कमांड हैं कि डिवाइस की स्क्रीन पर तत्वों को सही ढंग से प्रदर्शित किया गया है। वे आपको पिक्सेल घनत्व रिज़ॉल्यूशन को समायोजित करने देते हैं ताकि आप स्क्रीन आकार के लिए सभी आवश्यक विकल्पों के माध्यम से जा सकें और देख सकें कि हमारा ऐप उनके अनुकूल कैसे होगा, बिना उचित संख्या में उपकरणों के हाथ में:
adb shell wm size 1080x1920
— कस्टम स्क्रीन रिज़ॉल्यूशन को 1080 की चौड़ाई और 1920 की ऊंचाई के साथ सेट करता है।
adb shell wm size reset
— हमारी सभी बदली हुई सेटिंग्स को रीसेट करता है।
adb shell wm density X
— पिक्सेल डेंसिटी को बदलता है, जहां न्यूनतम मान 72 है। मान जितना बड़ा होगा, स्क्रीन पर तत्व उतने ही बड़े होंगे।
adb shell wm density reset
— हमारी सभी बदली हुई सेटिंग्स को रीसेट करता है।
यदि हम बिना किसी तर्क के अपने आदेश चलाते हैं, तो हम वर्तमान स्क्रीन रिज़ॉल्यूशन और कनेक्टेड डिवाइस/एमुलेटर की पिक्सेल घनत्व वापस प्राप्त करेंगे।
अलग से, हम बंदर का उल्लेख कर सकते हैं - एक उपकरण जो एमुलेटर या डिवाइस पर यादृच्छिक उपयोगकर्ता ईवेंट उत्पन्न करता है, जैसे कि क्लिक, टैप और जेस्चर, साथ ही कई सिस्टम-स्तरीय ईवेंट जो एक मूर्ख बंदर के आंदोलनों से मिलते जुलते हैं। तनाव परीक्षण के लिए बंदर का उपयोग किया जा सकता है।
adb shell monkey
- सभी बंदर पैरामीटर प्रदर्शित करता है।
एक पूर्ण परिदृश्य का उदाहरण:
adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10
--throttle
कुंजी — मिलीसेकंड में क्रियाओं के बीच विलंब सेट करती है। चूंकि बंदर सभी कार्यों को जल्दी से करता है, इस स्विच (कुंजी) का उपयोग आमतौर पर तब किया जाता है जब हम स्क्रीन पर क्या हो रहा है, इसे दृष्टि से नियंत्रित करना चाहते हैं।
--pct-syskeys
कुंजी — सिस्टम बटनों के प्रतिशत को परिभाषित करती है जो एक परिदृश्य के दौरान दबाए जाएंगे। इस उदाहरण में, यह 0 पर सेट है, जिसका अर्थ है कि कोई भी सिस्टम बटन नहीं दबाया जाएगा।
-p
स्विच — प्रेषित किए जा रहे पैकेट का नाम
-v
स्विच - की जाने वाली क्रियाओं की संख्या
आम तौर पर, यहां शामिल संचालन ऐप अनुमतियों को रद्द करने का संकेत देते हैं, क्योंकि अनुमतियां आमतौर पर ऐप अनुरोध के माध्यम से दी जाती हैं - कुछ ऐसा जो जल्दी और आसानी से किया जा सकता है - जबकि सिस्टम सेटिंग्स के माध्यम से अनुमतियों को रद्द करना किया जाता है।
adb shell dumpsys package com.MyApp | grep permission
- उपलब्ध एप्लिकेशन अनुमतियों की एक सूची प्रदर्शित करता है, उदाहरण के लिए, install permissions
करें - अनिवार्य अनुमतियाँ जो एप्लिकेशन को स्थापित करते समय दी जाती हैं, runtime permissions
- अनुमतियाँ जो एक विशिष्ट क्षण में अनुरोध की जाती हैं, जैसे, फ़ाइल भंडारण तक पहुँचने पर। ध्यान दें कि यदि अनुरोधित अनुमति सूची से कोई अनुमति गुम है, तो आप उस तक पहुंच प्रदान नहीं कर पाएंगे।
तो, हमारे आवेदन की अनुमति को रद्द करने के लिए निम्न आदेश चलाना होगा:
adb shell pm revoke packageName permissionName
, उदाहरण:
adb shell pm revoke com.MyApp android.permission.CAMERA
— कैमरे के लिए com.myApp
की एक्सेस को निरस्त करता है। एक बार जब हम एप्लिकेशन पर वापस आ जाते हैं और इसके माध्यम से कैमरे का उपयोग करने का प्रयास करते हैं, तो हमें अनुमति के लिए एक नया अनुरोध दिखाई देगा।
ग्रांट कमांड आवेदन को अनुमति देता है, उदाहरण के लिए:
adb shell pm grant com.myApp android.permission.CAMERA
- हमारे एप्लिकेशन के लिए फोन के कैमरे तक पहुंच प्रदान करता है।
आइए यहां बैटरी और स्टैंडबाय मोड पर एक संक्षिप्त नज़र डालें।
adb shell dumpsys battery
— बैटरी की जानकारी प्रदर्शित करता है।
adb shell dumpsys battery set level X
— बैटरी चार्ज लेवल सेट करता है, जहां X चार्ज का प्रतिशत है।
adb shell dumpsys battery unplug
— एक बैटरी अनप्लग का अनुकरण करता है।
adb shell dumpsys battery reset
— हमारी सभी बदली हुई सेटिंग्स को रीसेट करता है।
अब स्टैंडबाय मोड पर नजर डालते हैं। एंड्रॉइड 6 से शुरू होकर, डोज़ मोड के रूप में जाना जाने वाला फ़ंक्शन है, बैटरी की शक्ति को बचाने और ऐप गतिविधि को सीमित करके बैटरी जीवन का विस्तार करने के लिए जब उपयोगकर्ता ने डिवाइस के साथ कुछ समय तक बातचीत नहीं की है और जब डिवाइस चार्ज नहीं होता है।
लंबित पृष्ठभूमि कार्यों को पूरा करने के लिए सिस्टम समय-समय पर डोज़ मोड से बाहर निकलता है। ऐप स्टैंडबाय एक और समान एंड्रॉइड फीचर है। डोज़ मोड के विपरीत, यह एक विशिष्ट ऐप की स्थिति को ट्रैक करता है जो एक निश्चित अवधि के लिए निष्क्रिय रहा है और फिर स्टैंडबाय मोड को सक्रिय करता है। हमारा काम यह सुनिश्चित करना है कि इन दो पावर सेविंग मोड से बाहर निकलने के बाद ऐप सामान्य रूप से ठीक हो जाए, कि यह क्रैश न हो, सूचनाएं आती रहें, आदि।
डिवाइस को डोज़ मोड में बदलने के लिए, निम्न कमांड चलाएँ:
adb shell dumpsys battery unplug
— बैटरी को अनप्लग करता है।
adb shell dumpsys deviceidle step
— कमांड को प्रदर्शित होने तक कई बार निष्पादित करना पड़ सकता है: Stepped to deep: IDLE
।
सभी रूटीन के बाद हमने बैटरी के साथ पूरा किया है, कमांड को चलाने के लिए सबसे अच्छा है:
adb shell dumpsys battery reset
- जो इसे उसकी मूल स्थिति में लौटाता है।
इस आदेश का उपयोग डिवाइस को डोज़ मोड में बाध्य करने के लिए भी किया जा सकता है:
adb shell dumpsys deviceidle force—idle
— कभी-कभी, इससे पहले, आपको यह आदेश चलाना होगा: adb shell dumpsys deviceidle enable.
आप इसे डोज़ मोड से कमांड के साथ वापस सक्रिय कर सकते हैं:
adb shell dumpsys deviceidle unforce
— और बैटरी की स्थिति को रीसेट करना न भूलें:
adb shell dumpsys battery reset
।
अब थोड़ा ऐप स्टैंडबाय के बारे में। इस मोड में एप्लिकेशन को परिनियोजित करने के लिए, निम्नलिखित कमांड चलाने की आवश्यकता है:
adb shell dumpsys battery unplug
- पिछले मामले की तरह बैटरी को डिस्कनेक्ट करता है।
adb shell am set—inactive com.myApp true
— ऐप स्टैंडबाय मोड में एप्लिकेशन को परिनियोजित करता है।
इसके बाद, इस कमांड का उपयोग करके हमारे एप्लिकेशन को ऐप स्टैंडबाय मोड से बाहर करें:
adb shell am set—inactive com.myApp false
।
आप इस आदेश को चलाकर ऐप की स्थिति की जांच कर सकते हैं:
adb shell am get—inactive com.myApp
adb reboot
— डिवाइस को रीबूट करता है (वास्तविक डिवाइस के लिए भी प्रासंगिक)।
adb shell dumpsys package com.myApp
— एक विशिष्ट एप्लिकेशन के बारे में पूरी जानकारी प्रदर्शित करता है।
adb shell dumpsys meminfo com.myApp
— डिवाइस पर एप्लिकेशन के मेमोरी उपयोग की जांच करने के लिए, इस ऐप द्वारा उपयोग किए गए डेटाबेस को प्रदर्शित करने के लिए लिए गए स्थान से लेकर, साथ ही उनके लिए पथ।
adb shell getprop
— उपलब्ध डिवाइस गुणों (निर्माता, डिवाइस मॉडल, हार्डवेयर विनिर्देशों, आदि) की एक सूची दिखाता है।
उन गतिविधियों की सूची प्रदर्शित करें जो आवेदन के लिए सुलभ हैं:
adb shell dumpsys package com.myApp | grep —i Activity
।
चल रही गतिविधि का नाम प्रदर्शित करें:
adb shell dumpsys window | grep Focused
।
चयनित ऐप गतिविधि चलाएँ:
adb shell am start —n com.myApp/.ActivityClass
— इस तरह आप सिस्टम एप्लिकेशन सहित किसी भी इंस्टॉल किए गए ऐप्स को चला सकते हैं। उदाहरण: adb shell am start -n com.android.settings/.Settings हमारी फोन सेटिंग्स प्रदर्शित करता है।
निर्दिष्ट फ़ोन नंबर पर कॉल करें:
adb shell am start —a android.intent.action.CALL tel:+790900000XX
।
अपने वेब ब्राउज़र में एक पेज खोलें:
adb shell am start —a android.intent.action.VIEW 'https://indriver.com'
मैं यह बताना चाहता हूं कि एंड्रॉइड डिबग ब्रिज की सभी विशेषताओं को एक लेख में समेटना या उनका गहन अध्ययन करना असंभव है। परिवर्तन लगातार हो रहे हैं: आज जो काम करता है वह कल अचानक काम करना बंद कर सकता है, और जब हम विशिष्ट मुद्दों के समाधान की खोज करेंगे तो कुछ उपकरणों के ज्ञान की आवश्यकता पैदा होगी। लेकिन मैं विश्वास के साथ कह सकता हूं कि आज हमने जो सामग्री कवर की है वह आपको शुरू करने के लिए पर्याप्त है और फिर थोड़ी देर के लिए चलते रहें।
आपके प्रयासों में शुभकामनाएँ और मुझे आशा है कि आप सॉफ़्टवेयर परीक्षण की रोमांचक दुनिया में गोता लगाने का आनंद लेंगे!