Android 9 में, AOSP की सामान्य सिस्टम इमेज (जीएसआई) पर चलने वाले पार्टनर डिवाइसों पर, वीटीएस, सीटीएस या अन्य टेस्ट के ऑटोमेटेड टेस्टिंग के लिए, Vendor Test Suite (वीटीएस) का इंफ़्रास्ट्रक्चर शामिल है. पहले, इन टेस्ट को रन करना एक मैन्युअल प्रोसेस थी. हालांकि, वीटीएस के नए टेस्ट इंफ़्रास्ट्रक्चर को इस तरह डिज़ाइन किया गया है कि एक से ज़्यादा डिवाइसों पर, दिन में कई बार ऑटोमेटेड टेस्टिंग की जा सके.
वास्तुकला
वीटीएस के ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर में, इस आर्किटेक्चर का इस्तेमाल किया जाता है:
जब कोई टेस्ट ट्रिगर होता है, तो वीटीएस का ऑटोमेटेड टेस्टिंग इंफ़्रास्ट्रक्चर ये काम करता है:
- अलग-अलग जगहों से बिल्ड आर्टफ़ैक्ट और टेस्ट के संसाधन फ़ेच करता है:
- पार्टनर Android बिल्ड (पीएबी). जीएसआई, वीटीएस फ़्रेमवर्क, और कुछ अन्य बिल्ड के लिए.
- लोकल फ़ाइल सिस्टम, Google Cloud Storage या वेंडर के हिसाब से कोई अन्य बिल्ड सिस्टम. उन पार्टनर के लिए जो Google के क्लाउड में बिल्ड सेव नहीं करते.
- कनेक्ट किए गए डिवाइसों पर, बिल्ड आर्टफ़ैक्ट (डिवाइस से) और जीएसआई (AOSP से) फ़्लैश करता है.
- लोकल TradeFed या क्लाउड में मौजूद TradeFed का इस्तेमाल करके, वीटीएस टेस्ट रन करता है.
- वीटीएस डैशबोर्ड पर टेस्ट के नतीजे रिपोर्ट करता है
इस प्रोसेस को वीटीएस होस्ट कंट्रोलर (एचसी) कोऑर्डिनेट करता है. यह लैब में मौजूद एक मशीन है, जो टेस्ट किए जा रहे सभी कनेक्टेड डिवाइसों के व्यवहार को कंट्रोल करती है. एचसी, नए बिल्ड फ़ेच करने, उन्हें डिवाइसों पर फ़्लैश करने, और टेस्ट शुरू करने (लोकल तौर पर या कमांडर के ज़रिए) के लिए ज़िम्मेदार होता है. यह क्लाउड शेड्यूलर से भी कम्यूनिकेट करता है. साथ ही, शेड्यूलर और एचसी पर रन हो रहे TradeFed इंस्टेंस (या किसी अन्य हार्नेस) के बीच ट्रैफ़िक को डायरेक्ट करता है. होस्ट कंट्रोलर के बारे में ज़्यादा जानकारी के लिए, होस्ट कंट्रोलर का आर्किटेक्चर लेख पढ़ें.
संसाधन उपलब्ध कराने वाले टूल
ऑटोमेटेड टेस्टिंग के लिए, सिस्टम बिल्ड, टेस्ट फ़ाइलें, और वीटीएस आर्टफ़ैक्ट जैसे संसाधनों की ज़रूरत होती है. हालांकि, इन्हें सोर्स से बनाया जा सकता है. हालांकि, इन्हें ट्री के टॉप से नियमित तौर पर बनाना और फिर डाउनलोड के लिए आर्टफ़ैक्ट पोस्ट करना ज़्यादा आसान है.
पार्टनर, ऑटोमेशन के संसाधनों को इन जगहों से ऐक्सेस कर सकते हैं:
- पार्टनर Android बिल्ड. हर खाते के हिसाब से, प्रोग्राम के ज़रिए ऐक्सेस दिया जाता है.
- लोकल फ़ाइल सिस्टम (या इसी तरह का कोई अन्य सिस्टम). उन पार्टनर के लिए जो पार्टनर Android बिल्ड का इस्तेमाल नहीं करते.
डिवाइसों को बाद में फ़्लैश करने के लिए, संसाधनों में दोनों विकल्पों के लिए बिल्ड उपलब्ध कराने वाले टूल शामिल होते हैं.
ये टूल, एक ही build_provider.py से एक्सटेंड होते हैं.
यह टूल, बिल्ड को लोकल अस्थायी डायरेक्ट्री में सेव करता है.
पार्टनर Android बिल्ड
Android 8.1 और इससे पहले की रिलीज़ में, Android के पार्टनर को Partner Android Build की वेबसाइट (https://partner.android.com/build) पर जाना पड़ता था. इसके बाद, उन्हें अपने खाते पर जाकर, यूज़र इंटरफ़ेस की मदद से, सिस्टम की नई इमेज फ़ेच करनी पड़ती थी. पार्टनर को इस धीमी और ज़्यादा मेहनत वाली प्रोसेस से बचाने के लिए, Android 9 में, सही क्रेडेंशियल देने पर, इन संसाधनों को पीएबी से अपने-आप डाउनलोड करने की सुविधा शामिल है.
ऐक्सेस सेट अप करना
प्रोग्राम के ज़रिए ऐक्सेस करने के लिए, ज़रूरी आरपीसी को ऐक्सेस करने के लिए, Google की एपीआई पर OAuth2 का इस्तेमाल किया जाता है.
OAuth2 क्रेडेंशियल जनरेट करने के
स्टैंडर्ड
तरीके का इस्तेमाल करके, पार्टनर को Google के साथ
क्लाइंट आईडी/सीक्रेट पेयर सेट अप करना होगा. जब
PartnerAndroidBuildClient को पहली
बार उस सीक्रेट की ओर पॉइंट किया जाता है, तो यह उपयोगकर्ता के लिए ब्राउज़र विंडो खोलता है, ताकि वह अपने Google
खाते में लॉग इन कर सके. इससे, आगे बढ़ने के लिए ज़रूरी OAuth2 क्रेडेंशियल जनरेट होते हैं. क्रेडेंशियल (ऐक्सेस टोकन और रीफ़्रेश टोकन) स्थानीय तौर पर सेव किए जाते हैं. इसका मतलब है कि पार्टनर को सिर्फ़ एक बार लॉग इन करना होगा.
यूआरएल के लिए पोस्ट अनुरोध
पीएबी में किसी संसाधन के लिंक पर क्लिक करने से, एक पोस्ट अनुरोध भेजा जाता है. इसमें उस संसाधन के लिए ज़रूरी डेटा शामिल होता है. जैसे:
- बिल्ड आईडी, बिल्ड टारगेट
- संसाधन का नाम
- ब्रांच
- रिलीज़ कैंडिडेट का नाम और यह जानकारी कि कैंडिडेट, इंटरनल बिल्ड है या नहीं
पोस्ट अनुरोध, downloadBuildArtifact तरीके से मिलता है
buildsvc आरपीसी का. यह एक यूआरएल दिखाता है, जिसका इस्तेमाल संसाधन को ऐक्सेस करने के लिए किया जा सकता है
.
- Clockwork Companion APK के संसाधनों के लिए, यूआरएल एक ऐसा यूआरएल होता है जिसे पढ़ा जा सकता है. यह यूआरएल, पीएबी पर होस्ट किया जाता है. यह यूआरएल, पुष्टि की सुविधा से सुरक्षित होता है और इसे सही OAuth2 क्रेडेंशियल से ऐक्सेस किया जा सकता है.
- अन्य संसाधनों के लिए, यूआरएल, इंटरनल Android के इंटरनल बिल्ड एपीआई से मिला एक लंबा और बिना सुरक्षा वाला यूआरएल होता है. यह यूआरएल, पांच मिनट बाद काम करना बंद कर देता है.
यूआरएल पाना
किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध को रोकने के लिए, buildsvc आरपीसी के लिए ज़रूरी है कि अन्य पैरामीटर के साथ,
XSRF टोकन पोस्ट किया जाए. इस टोकन से प्रोसेस ज़्यादा सुरक्षित हो जाती है. हालांकि, इससे प्रोग्राम के ज़रिए ऐक्सेस करना भी मुश्किल हो जाता है, क्योंकि अब ऐक्सेस के लिए टोकन की भी ज़रूरत होती है. यह टोकन, सिर्फ़ पीएबी पेज के JavaScript में उपलब्ध होता है.
इस समस्या से बचने के लिए, Android 9 में सभी फ़ाइलों (सिर्फ़ APK नहीं) के लिए, यूआरएल
नेमिंग स्कीम को फिर से डिज़ाइन किया गया है. इससे, आर्टफ़ैक्ट की सूचियों और आर्टफ़ैक्ट के यूआरएल को ऐक्सेस करने के लिए, अनुमान के मुताबिक यूआरएल के नाम इस्तेमाल किए जा सकते हैं.
अब पीएबी, यूआरएल के ऐसे फ़ॉर्मैट का इस्तेमाल करता है जिससे पार्टनर, संसाधन डाउनलोड कर सकते हैं.
एचसी स्क्रिप्ट, उन APK को आसानी से डाउनलोड कर सकती हैं, क्योंकि यूआरएल का फ़ॉर्मैट पता होता है. साथ ही, एचसी, XSRF/कुकी की समस्याओं को नज़रअंदाज़ कर सकता है, क्योंकि उसे buildsvc आरपीसी की ज़रूरत नहीं होती.
लोकल फ़ाइल सिस्टम
आर्टफ़ैक्ट की सूची (या zip फ़ाइल) वाली डायरेक्ट्री के लिए, बिल्ड उपलब्ध कराने वाला टूल डायरेक्ट्री में मौजूद कॉन्टेंट के हिसाब से, काम की इमेज सेट करता है. Google Cloud Storage से किसी लोकल डायरेक्ट्री में फ़ाइलें कॉपी करने के लिए, gsutil टूल का इस्तेमाल किया जा सकता है.
बिल्ड फ़्लैश करना
डिवाइस की नई इमेज, होस्ट पर डाउनलोड होने के बाद, उन इमेज को डिवाइसों पर फ़्लैश करना ज़रूरी है. यह काम, स्टैंडर्ड
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.