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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नया डिवाइस कनेक्शन, एसिंक्रोनस इवेंट की एक सीरीज़ को ट्रिगर करता है. ये इवेंट, साफ़ तौर पर नहीं दिखते, लेकिन इन्हें समझना ज़रूरी है.

फ़िज़िकल तौर पर कनेक्ट होना

Tradefed, adb और डिवाइसों के साथ बुनियादी इंटरैक्शन देने के लिए, ddmlib लाइब्रेरी (Java 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 console में दिखती है. ऐसा तब होता है, जब डिवाइसों की लिस्टिंग इनके ज़रिए की जाती है: 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 से आने वाला IDevice हमेशा मुख्य डिवाइस होता है.

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