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