Tradefed में डिवाइस की पहचान करना

किसी नए डिवाइस को कनेक्ट करने पर, एसिंक्रोनस इवेंट की एक सीरीज़ ट्रिगर होती है. इनके बारे में अभी तक ज़्यादा जानकारी नहीं है, लेकिन इनके बारे में जानना ज़रूरी है.

फ़िज़िकल तौर पर कनेक्ट किया गया

Tradefed, ddmlib लाइब्रेरी (Java adb लाइब्रेरी) का इस्तेमाल करता है, ताकि adb और डिवाइसों के साथ बुनियादी इंटरैक्शन किया जा सके. इस समाधान का एक हिस्सा IDeviceChangeListener इंटरफ़ेस है. इसकी मदद से, नए डिवाइस इवेंट को स्वीकार किया जा सकता है. जैसे:

• deviceConnected: जब adb को कोई नया डिवाइस दिखता है
• deviceDisconnected: जब कोई डिवाइस, adb को डेटा भेजना बंद कर देता है
• deviceChanged: जब डिवाइस की स्थिति में कोई बड़ा बदलाव होता है, जैसे कि डिवाइस ऑफ़लाइन हो गया है या डिवाइस ऑनलाइन हो गया है

डिवाइस कनेक्ट है, ऑनलाइन है या ऑफ़लाइन है, यह तय करने के लिए adb लेवल पर ये इवेंट काफ़ी हैं. हालांकि, टेस्ट हार्नेस के लिए हमें इससे ज़्यादा बेहतर स्थिति की ज़रूरत होती है, ताकि यह पक्का किया जा सके कि डिवाइस, टेस्ट चलाने के लिए पूरी तरह से तैयार है. साथ ही, यह नई स्थिति में कनेक्ट किए गए डिवाइस की वजह से होने वाली संभावित गड़बड़ियों से प्रभावित नहीं होना चाहिए.

Tradefed में इवेंट का क्रम इस तरह होता है:

1. डिवाइस को deviceConnected के तौर पर पहचाना गया है और यह adb से सामान्य इवेंट के लिए उपलब्ध है

2. एक इंटरनल Tradefed इवेंट बनाया जाता है. इससे ये काम किए जाते हैं:

   • देखें कि डिवाइस पहले से जाना-पहचाना है या नहीं. Tradefed, कुछ डिवाइसों (खास तौर पर, फ़िलहाल असाइन किए गए और टेस्ट चलाने वाले डिवाइसों) का इंटरनल रेफ़रंस रखता है, ताकि TF उन्हें रैंडम तरीके से ट्रैक न करे.
   • देखें कि डिवाइस ONLINE या OFFLINE है या नहीं.

3. अगर डिवाइस है:

   • OFFLINE: डिवाइस को Tradefed CONNECTED_OFFLINE स्टेट पर स्विच कर दिया जाएगा. इस स्टेट में, डिवाइस पर अब तक टेस्ट नहीं किए जा सकते. अगर डिवाइस बाद में ऑनलाइन होता है, तो यह ONLINE साइकल से गुज़रेगा. अगर हमें deviceDisconnect इवेंट मिलता है, तो डिवाइस को सूची से हटा दिया जाएगा.

   • ONLINE (adb के मुताबिक): डिवाइस को CONNECTED_ONLINE स्थिति में रखा जाएगा. साथ ही, टेस्ट के लिए डिवाइस की उपलब्धता की जांच की जाएगी: checking_availability.

4. अगर availability की जांच सफल होती है, तो डिवाइस को टेस्ट के लिए उपलब्ध के तौर पर मार्क किया जाएगा. इस पर टेस्ट किए जा सकेंगे. अगर ऐसा नहीं होता है, तो डिवाइस को unavailable के तौर पर मार्क किया जाएगा. साथ ही, इसे कोई भी टेस्ट नहीं मिल पाएगा.

डिवाइसों को इन तरीकों से लिस्ट करते समय, ये सभी स्थितियां Tradefed कंसोल में दिखती हैं: tf> list devices

यह ध्यान रखना ज़रूरी है कि जब डिवाइस को किसी टेस्ट के लिए असाइन किया जाता है, तब ऊपर बताई गई ज़्यादातर कार्रवाइयां नहीं होंगी. साथ ही, Tradefed डिवाइस की स्थिति का पता अंदरूनी तौर पर लगाएगा. इसलिए, ऐसा हो सकता है कि कोई डिवाइस adb devices से हट जाए, लेकिन Tradefed में अब भी उसकी जानकारी दिख रही हो. ऐसा तब हो सकता है, जब कोई टेस्ट डिवाइस को रीबूट कर रहा हो. उदाहरण के लिए.

adb connect से कनेक्ट किया गया वर्चुअल डिवाइस

रिमोट वर्चुअल डिवाइस बनाने पर, Tradefed adb connect का इस्तेमाल करके उससे कनेक्ट होता है. इससे आम तौर पर, adb devices में डिवाइस <some ip>:<port number> के तौर पर दिखने लगेगा. साथ ही, यह उसी क्रम में दिखेगा जिस क्रम में डिवाइसों को फ़िज़िकली कनेक्ट किया जाता है.

deviceConnected इवेंट होने पर डिवाइस को ट्रैक करना

जब deviceConnected होता है, तब ddmlib एक नया रेफ़रंस IDevice बनाता है, ताकि नए कनेक्ट किए गए डिवाइस को ट्रैक किया जा सके.

Tradefed उस रेफ़रंस का इस्तेमाल करता है और उसे डिवाइस इंटरफ़ेस ITestDevice के अपने तरीके से लागू करता है, ताकि बेहतर सेवा दी जा सके. हालांकि, आईडीवाइस हमेशा ddmlib से मिलता है.

इसका मतलब है कि अगर कोई नया डिवाइस कनेक्ट किया जाता है, तो एक नया ITestDevice बनाया जाता है और उसे IDevice से जोड़ दिया जाता है. ऐसा होने पर, अगर ITestDevice का इस्तेमाल किया जा रहा है, तो आईडीवाइस को बदल दिया जाता है, ताकि टेस्टिंग सही रेफ़रंस पर की जा सके. जब भी कोई डिवाइस डिसकनेक्ट/रीकनेक्ट होता है, तब यह प्रोसेस अपने-आप होती है. उदाहरण के लिए, रीबूट के दौरान.