Android 9 में वेंडर टेस्ट सुइट (वीटीएस) का इन्फ़्रास्ट्रक्चर शामिल है. इससे, AOSP के सामान्य सिस्टम इमेज (जीएसआई) पर चलने वाले पार्टनर डिवाइसों पर, वीटीएस, सीटीएस या अन्य टेस्ट अपने-आप होने की सुविधा मिलती है. पहले, इन टेस्ट को चलाने का काम मैन्युअल तरीके से करना था. नया वीटीएस टेस्ट इन्फ़्रास्ट्रक्चर इस तरह से डिज़ाइन किया गया है कि उससे कई डिवाइसों पर, दिन में कई बार अपने-आप टेस्टिंग हो सके.
भवन निर्माण
VTS का ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर, इस आर्किटेक्चर का इस्तेमाल करता है:
जब कोई टेस्ट ट्रिगर होता है, तो VTS का ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर ये काम करता है:
- अलग-अलग जगहों से बिल्ड आर्टफ़ैक्ट और टेस्ट संसाधनों को फ़ेच करता है:
- पार्टनर Android बिल्ड (पीएबी). GSI, VTS के लिए फ़्रेमवर्क, और कुछ अन्य बिल्ड.
- लोकल फ़ाइल सिस्टम, Google Cloud Storage या वेंडर के हिसाब से बने अन्य बिल्ड सिस्टम. उन पार्टनर के लिए जो Google के क्लाउड में बिल्ड स्टोर नहीं करते हैं.
- कनेक्ट किए गए डिवाइसों पर, डिवाइस से बने आर्टफ़ैक्ट और AOSP से GSI को फ़्लैश करता है.
- क्लाउड में लोकल ट्रेडएफ़ेड या ट्रेडFed का इस्तेमाल करके वीटीएस टेस्ट करता है.
- VTS डैशबोर्ड पर टेस्ट के नतीजे दिखाता है
इस प्रोसेस को VTS होस्ट कंट्रोलर (एचसी) मैनेज करता है. यह एक ऐसी मशीन है जो लैब में कनेक्ट किए गए सभी डिवाइसों के व्यवहार को कंट्रोल करती है. एचसी की ज़िम्मेदारी, सबसे नए बिल्ड फ़ेच करने, उन्हें डिवाइसों पर फ़्लैश करने, और जांच शुरू करने की होती है. जांच को स्थानीय तौर पर या कमांडर के ज़रिए शुरू किया जा सकता है. यह क्लाउड शेड्यूलर के साथ भी कम्यूनिकेट करता है. साथ ही, यह HC पर चल रहे शेड्यूलर और TradeFed इंस्टेंस (या किसी अन्य हार्नेस) के बीच ट्रैफ़िक को डायरेक्ट करता है. होस्ट कंट्रोलर के बारे में जानकारी पाने के लिए, होस्ट कंट्रोलर का आर्किटेक्चर लेख पढ़ें.
संसाधन देने वाले संगठन
ऑटोमेटेड टेस्टिंग के लिए, सिस्टम बिल्ड, टेस्ट फ़ाइलें, और VTS आर्टफ़ैक्ट जैसे रिसॉर्स की ज़रूरत होती है. इन्हें सोर्स से बनाया जा सकता है. हालांकि, इन्हें नियमित तौर पर टिप-ऑफ़-ट्री से बनाना और फिर आर्टफ़ैक्ट को डाउनलोड करने के लिए पोस्ट करना आसान होता है.
पार्टनर इन जगहों का इस्तेमाल करके, ऑटोमेशन से जुड़े संसाधनों को ऐक्सेस कर सकते हैं:
- पार्टनर का Android बिल्ड. प्रोग्राम के हिसाब से, अपने-आप होने वाली प्रोसेस का ऐक्सेस, हर खाते के हिसाब से दिया जाता है.
- लोकल फ़ाइल सिस्टम (या मिलता-जुलता). उन पार्टनर के लिए जिन्होंने पार्टनर Android बिल्ड का इस्तेमाल नहीं किया है.
बाद में डिवाइसों को फ़्लैश करने के लिए, संसाधनों में दोनों विकल्पों के लिए बाइल्ड उपलब्ध कराने वाली कंपनियां शामिल होती हैं. ये कंपनियां, एक ही 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 टोकन पोस्ट करना ज़रूरी है. यह टोकन, प्रोसेस को ज़्यादा सुरक्षित बनाता है. हालांकि, इससे प्रोग्राम के हिसाब से, अपने-आप होने वाली प्रोसेस को ऐक्सेस करना मुश्किल हो जाता है. ऐसा इसलिए, क्योंकि अब ऐक्सेस के लिए टोकन (जो सिर्फ़ PAB पेज के JavaScript में उपलब्ध होता है) की ज़रूरत होती है.
इस समस्या से बचने के लिए, Android 9 सभी फ़ाइलों (न कि सिर्फ़ APK) के लिए, यूआरएल का नाम रखने की स्कीम को फिर से डिज़ाइन करता है. ऐसा इसलिए किया जाता है, ताकि आर्टफ़ैक्ट की सूचियों और आर्टफ़ैक्ट यूआरएल को ऐक्सेस करने के लिए, यूआरएल के नामों का अनुमान लगाया जा सके. पीएबी अब आसान यूआरएल फ़ॉर्मैट का इस्तेमाल करता है. इसकी मदद से पार्टनर, संसाधनों को डाउनलोड कर सकते हैं. सहायता केंद्र की स्क्रिप्ट उन APK को आसानी से डाउनलोड कर सकती हैं, क्योंकि यूआरएल का फ़ॉर्मैट पहले से मौजूद होता है और HC, XSRF/कुकी से जुड़ी समस्याओं को बायपास कर सकता है. ऐसा इसलिए, क्योंकि इसे buildsvc की ज़रूरत नहीं है.
लोकल फ़ाइल सिस्टम
आर्टफ़ैक्ट की सूची (या ज़िप फ़ाइल) वाली डायरेक्ट्री को देखते हुए, बिल्ड की सेवा देने वाली कंपनी, डायरेक्ट्री में मौजूद चीज़ों के आधार पर काम की इमेज सेट करती है. Google Cloud Storage से किसी लोकल डायरेक्ट्री में फ़ाइलें कॉपी करने के लिए, gsutil टूल का इस्तेमाल किया जा सकता है.
फ़्लैश बिल्ड
होस्ट पर डिवाइस की सबसे नई इमेज डाउनलोड होने के बाद, उन इमेज को डिवाइसों पर फ़्लैश करना ज़रूरी है. ऐसा, स्टैंडर्ड adb और fastboot निर्देशों और Python सबप्रोसेस का इस्तेमाल करके किया जाता है. यह, बिल्ड उपलब्ध कराने वाली कंपनियों के स्टोर किए गए अस्थायी फ़ाइल पाथ के आधार पर किया जाता है.
ये कार्रवाइयां की जा सकती हैं:
- सिर्फ़ जीएसआई को फ़्लैश करना
- मुख्य सिस्टम से अलग-अलग इमेज को फ़्लैश करना (जैसे,
fastboot flash boot boot.img) - मुख्य सिस्टम से सभी इमेज फ़्लैश करना. उदाहरण:
fastboot flashall(डिवाइस में पहले से मौजूदflashallयूटिलिटी का इस्तेमाल करके)fastboot flash(एक बार में एक)
टेस्ट चलाना
Android 9 में, वीटीएस अपने-आप टेस्ट होने की सुविधा सिर्फ़ ट्रेडFed टेस्ट हार्नेस के साथ काम करती है. हालांकि, आने वाले समय में इसे अन्य हार्नेस के साथ काम करने के लिए बढ़ाया जा सकता है.
डिवाइस तैयार होने के बाद, इनमें से किसी एक विकल्प का इस्तेमाल करके जांच शुरू की जा सकती है:
- स्थानीय तौर पर ट्रेडFed का इस्तेमाल करते समय, होस्ट कंट्रोलर में
testकमांड का इस्तेमाल करें. यह वीटीएस टेस्ट प्लान (जैसे किvts-selftest) का नाम लेता है और टेस्ट करता है. - TradeFed क्लस्टर (एमटीटी से कनेक्ट किया जा सकता है) का इस्तेमाल करते समय, होस्ट कंट्रोलर कंसोल में
leaseकमांड का इस्तेमाल करें. यह कमांड, पूरे नहीं किए गए टेस्ट रन को ढूंढता है.
TradeFedCluster का इस्तेमाल करने पर, TradeFed रिमोट मैनेजर के तौर पर स्थानीय तौर पर चलता है. अगर ऐसा नहीं है, तो Python सबप्रोसेस का इस्तेमाल करके टेस्ट शुरू किए जाते हैं.
रिपोर्ट के नतीजे
VtsMultiDeviceTest की मदद से, टेस्ट के नतीजे कुछ VTS डैशबोर्ड प्रोजेक्ट में अपने-आप रिपोर्ट हो जाते हैं.