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