Android 9 में वेंडर टेस्ट सुइट (वीटीएस) का इन्फ़्रास्ट्रक्चर शामिल है. इससे, AOSP जनरिक सिस्टम इमेज (जीएसआई) पर काम करने वाले पार्टनर डिवाइसों पर, वीटीएस, सीटीएस या अन्य टेस्ट अपने-आप होने की सुविधा मिलती है. पहले, इन जांचों को मैन्युअल तरीके से चलाना पड़ता था. हालांकि, नए वर्चुअल टेस्टिंग सिस्टम (वीटीएस) के इन्फ़्रास्ट्रक्चर को इस तरह से डिज़ाइन किया गया है कि यह एक दिन में कई डिवाइसों पर, अपने-आप कई बार जांच कर सके.
भवन निर्माण
VTS का ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर, इस आर्किटेक्चर का इस्तेमाल करता है:
जब कोई टेस्ट ट्रिगर होता है, तो VTS का ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर ये काम करता है:
- अलग-अलग जगहों से बिल्ड आर्टफ़ैक्ट और टेस्ट संसाधनों को फ़ेच करता है:
- पार्टनर Android बिल्ड (पीएबी). GSI, VTS के लिए फ़्रेमवर्क, और कुछ अन्य बिल्ड.
- लोकल फ़ाइल सिस्टम, Google Cloud Storage या वेंडर के हिसाब से बने अन्य बिल्ड सिस्टम. उन पार्टनर के लिए जिन्होंने Google के क्लाउड में बिल्ड सेव नहीं किए हैं.
- कनेक्ट किए गए डिवाइसों पर, डिवाइस से बने आर्टफ़ैक्ट और AOSP से GSI को फ़्लैश करता है.
- यह स्थानीय TradeFed या क्लाउड में मौजूद TradeFed का इस्तेमाल करके, वीटीएस टेस्ट चलाता है.
- VTS डैशबोर्ड पर टेस्ट के नतीजे दिखाता है
इस प्रोसेस को VTS होस्ट कंट्रोलर (एचसी) मैनेज करता है. यह एक ऐसी मशीन है जो लैब में, टेस्ट किए जा रहे सभी कनेक्ट किए गए डिवाइसों के व्यवहार को कंट्रोल करती है. एचसी की ज़िम्मेदारी, सबसे नए बिल्ड फ़ेच करने, उन्हें डिवाइसों पर फ़्लैश करने, और जांच शुरू करने की होती है. जांच को स्थानीय तौर पर या कमांडर के ज़रिए शुरू किया जा सकता है. यह क्लाउड शेड्यूलर के साथ भी कम्यूनिकेट करता है. साथ ही, यह शेड्यूलर और एचसी पर चल रहे TradeFed इंस्टेंस (या किसी अन्य हार्नेस) के बीच ट्रैफ़िक को डायरेक्ट करता है. होस्ट कंट्रोलर के बारे में जानकारी पाने के लिए, होस्ट कंट्रोलर का आर्किटेक्चर लेख पढ़ें.
संसाधन उपलब्ध कराने वाली कंपनियां
ऑटोमेटेड टेस्टिंग के लिए, सिस्टम बिल्ड, टेस्ट फ़ाइलें, और VTS आर्टफ़ैक्ट जैसे रिसॉर्स की ज़रूरत होती है. इन्हें सोर्स से बनाया जा सकता है. हालांकि, इन्हें नियमित तौर पर टिप-ऑफ़-ट्री से बनाना और फिर आर्टफ़ैक्ट को डाउनलोड करने के लिए पोस्ट करना आसान होता है.
पार्टनर, यहां दी गई जगहों का इस्तेमाल करके ऑटोमेशन संसाधनों को ऐक्सेस कर सकते हैं:
- पार्टनर का Android बिल्ड. प्रोग्राम के हिसाब से, अपने-आप होने वाली प्रोसेस का ऐक्सेस, हर खाते के हिसाब से दिया जाता है.
- लोकल फ़ाइल सिस्टम (या इससे मिलता-जुलता). उन पार्टनर के लिए जिन्होंने पार्टनर Android Build का इस्तेमाल नहीं किया है.
बाद में डिवाइसों को फ़्लैश करने के लिए, संसाधनों में दोनों विकल्पों के लिए बाइल्ड उपलब्ध कराने वाली कंपनियां शामिल होती हैं. ये कंपनियां, एक build_provider.py से शुरू होती हैं, जो बाइल्ड को स्थानीय अस्थायी डायरेक्ट्री में सेव करती हैं.
पार्टनर का Android बिल्ड
Android 8.1 और उससे पहले के वर्शन में, Android पार्टनर को Partner Android Build की वेबसाइट (https://partner.android.com/build) पर जाना होता था. इसके बाद, उन्हें अपने खाते पर जाना होता था और यूज़र इंटरफ़ेस की मदद से, सबसे नई सिस्टम इमेज फ़ेच करनी होती थी. पार्टनर को इस धीमी और मुश्किल प्रोसेस से बचाने के लिए, Android 9 में PAB से इन रिसॉर्स को अपने-आप डाउनलोड करने की सुविधा शामिल की गई है. इसके लिए, ज़रूरी क्रेडेंशियल देने होंगे.
ऐक्सेस सेट अप करना
प्रोग्राम के हिसाब से ऐक्सेस करने के लिए, ज़रूरी आरपीसी को ऐक्सेस करने के लिए, Google API पर OAuth2 का इस्तेमाल किया जाता है.
OAuth2 क्रेडेंशियल जनरेट करने के लिए, पार्टनर को स्टैंडर्ड तरीके का इस्तेमाल करके, Google के साथ क्लाइंट आईडी/सीक्रेट जोड़ा जाना चाहिए. जब PartnerAndroidBuildClient को पहली बार उस सीक्रेट पर ले जाया जाता है, तो उपयोगकर्ता के लिए एक ब्राउज़र विंडो खुलती है. इसकी मदद से, वह अपने Google खाते में लॉग इन कर सकता है. यह विंडो, आगे की प्रोसेस के लिए ज़रूरी OAuth2 क्रेडेंशियल जनरेट करती है. क्रेडेंशियल (ऐक्सेस टोकन और रीफ़्रेश टोकन) को डिवाइस में सेव किया जाता है. इसका मतलब है कि पार्टनर को सिर्फ़ एक बार लॉगिन करना होगा.
यूआरएल के लिए पोस्ट अनुरोध
पीएबी में किसी संसाधन के लिंक पर क्लिक करने से, एक पोस्ट अनुरोध भेजा जाता है. इसमें उस संसाधन के लिए ज़रूरी डेटा शामिल होता है. जैसे:
- बिल्ड आईडी, बिल्ड टारगेट
- संसाधन का नाम
- शाखा
- रिलीज़ कैंडिडेट का नाम और यह जानकारी कि कैंडिडेट, इंटरनल बिल्ड है या नहीं
POST अनुरोध, buildsvc आरपीसी के downloadBuildArtifact तरीके से मिलता है. यह एक यूआरएल दिखाता है, जिसका इस्तेमाल संसाधन को ऐक्सेस करने के लिए किया जा सकता है.
- Clockwork Companion APK के संसाधनों के लिए, यूआरएल एक ऐसा यूआरएल होता है जिसे पढ़ा जा सकता है और जिसे PAB पर होस्ट किया जाता है. यह यूआरएल, पुष्टि के ज़रिए सुरक्षित होता है और इसे सही OAuth2 क्रेडेंशियल की मदद से ऐक्सेस किया जा सकता है.
- अन्य संसाधनों के लिए, यूआरएल लंबा और Android के इंटरनल Build API से मिला ऐसा यूआरएल होता है जिसे सुरक्षित नहीं किया गया है. यह यूआरएल पांच मिनट के बाद अमान्य हो जाता है.
यूआरएल पाना
किसी दूसरी साइट से किए जाने वाले फ़र्ज़ी अनुरोध से बचने के लिए, buildsvc आरपीसी के लिए, अन्य पैरामीटर के साथ एक
XSRF टोकन पोस्ट करना ज़रूरी है. यह टोकन, प्रोसेस को ज़्यादा सुरक्षित बनाता है. हालांकि, प्रोग्राम के ज़रिए ऐक्सेस करना अब ज़्यादा मुश्किल हो गया है. ऐसा इसलिए है, क्योंकि अब ऐक्सेस करने के लिए टोकन की ज़रूरत होती है. यह टोकन, सिर्फ़ पीएबी पेज के JavaScript में उपलब्ध होता है.
इस समस्या से बचने के लिए, Android 9 ने सभी फ़ाइलों (सिर्फ़ APK फ़ाइलों के लिए नहीं) के लिए यूआरएल के नाम तय करने की स्कीम को फिर से डिज़ाइन किया है. इससे आर्टफ़ैक्ट की सूचियों और आर्टफ़ैक्ट के यूआरएल को ऐक्सेस करने के लिए, अनुमानित यूआरएल के नाम इस्तेमाल किए जा सकते हैं. अब PAB, यूआरएल के सुविधाजनक फ़ॉर्मैट का इस्तेमाल करता है. इससे पार्टनर, संसाधनों को डाउनलोड कर सकते हैं. HC स्क्रिप्ट, उन APK को आसानी से डाउनलोड कर सकती हैं, क्योंकि यूआरएल का फ़ॉर्मैट पता होता है. साथ ही, HC, XSRF/कुकी से जुड़ी समस्याओं को बायपास कर सकता है, क्योंकि उसे buildsvc आरपीसी की ज़रूरत नहीं होती.
लोकल फ़ाइल सिस्टम
आर्टफ़ैक्ट की सूची (या ज़िप फ़ाइल) वाली डायरेक्ट्री के आधार पर, बिल्ड की सेवा देने वाली कंपनी, डायरेक्ट्री में मौजूद जानकारी के हिसाब से काम की इमेज सेट करती है. Google Cloud Storage से फ़ाइलों को किसी लोकल डायरेक्ट्री में कॉपी करने के लिए, gsutil टूल का इस्तेमाल किया जा सकता है.
फ़्लैश बिल्ड
होस्ट पर डिवाइस की सबसे नई इमेज डाउनलोड होने के बाद, उन इमेज को डिवाइसों पर फ़्लैश करना ज़रूरी है. ऐसा, स्टैंडर्ड adb और fastboot निर्देशों और Python सबप्रोसेस का इस्तेमाल करके किया जाता है. यह, बिल्ड प्रोवाइडर के स्टोर किए गए अस्थायी फ़ाइल पाथ के आधार पर होता है.
ये कार्रवाइयां की जा सकती हैं:
- सिर्फ़ जीएसआई को फ़्लैश करना
- मुख्य सिस्टम से अलग-अलग इमेज फ़्लैश करना (उदाहरण के लिए,
fastboot flash boot boot.img) - मुख्य सिस्टम से सभी इमेज फ़्लैश करना. उदाहरण:
fastboot flashall(डिवाइस में पहले से मौजूदflashallयूटिलिटी का इस्तेमाल करके)fastboot flash(एक बार में एक)
टेस्ट चलाना
Android 9 में, VTS ऑटोमेटेड टेस्टिंग इन्फ़्रास्ट्रक्चर सिर्फ़ TradeFed टेस्ट हार्नेस के साथ काम करता है. हालांकि, आने वाले समय में इसे अन्य हार्नेस के साथ काम करने के लिए भी इस्तेमाल किया जा सकता है.
डिवाइस तैयार होने के बाद, इनमें से किसी एक विकल्प का इस्तेमाल करके जांच शुरू की जा सकती है:
- स्थानीय तौर पर TradeFed का इस्तेमाल करते समय, होस्ट कंट्रोलर में
testकमांड का इस्तेमाल करें. यह कमांड, किसी VTS टेस्ट प्लान (उदाहरण के लिए,vts-selftest) का नाम लेता है और टेस्ट चलाता है. - TradeFed क्लस्टर (एमटीटी से कनेक्ट किया जा सकता है) का इस्तेमाल करते समय, होस्ट कंट्रोलर कंसोल में
leaseकमांड का इस्तेमाल करें. यह कमांड, पूरे नहीं किए गए टेस्ट रन को ढूंढता है.
TradeFedCluster का इस्तेमाल करने पर, TradeFed रिमोट मैनेजर के तौर पर स्थानीय तौर पर चलता है. अगर ऐसा नहीं है, तो टेस्ट को Python सबप्रोसेस का इस्तेमाल करके शुरू किया जाता है.
रिपोर्ट के नतीजे
VtsMultiDeviceTest की मदद से, टेस्ट के नतीजे कुछ VTS डैशबोर्ड प्रोजेक्ट में अपने-आप रिपोर्ट हो जाते हैं.