टेस्ट सेटअप

टेस्ट सुइट

किसी टेस्ट को वीटीएस का हिस्सा बनाने के लिए, Android.bp में यह सेटिंग होनी चाहिए.

test_suites: ["vts"],

इसके अलावा, टेस्ट को सुइट general-tests में जोड़ने से, इसे टेस्ट मैपिंग सुइट का हिस्सा बनाया जा सकता है. इसका इस्तेमाल, सबमिट करने से पहले की जाने वाली जांच में किया जाता है.

टेस्ट कॉन्फ़िगरेशन

ज़्यादातर मामलों में, जांच का कॉन्फ़िगरेशन, बिल्ड के दौरान अपने-आप जनरेट होता है. यह एक एक्सएमएल फ़ाइल होती है, जिसका इस्तेमाल Trade Federation, वीटीएस जांच चलाने के लिए करता है. हालांकि, जांच के कॉन्फ़िगरेशन को पसंद के मुताबिक बनाया जा सकता है.

पसंद के मुताबिक टेस्ट कॉन्फ़िगरेशन फ़ाइल बनाना

नई टेस्ट एक्सएमएल फ़ाइल बनाना मुश्किल हो सकता है, क्योंकि इसमें टेस्ट हार्नेस के काम करने के तरीके के साथ-साथ, हर टेस्ट रनर के बीच के अंतर को समझना शामिल है. अपने-आप जनरेट हुई टेस्ट कॉन्फ़िगरेशन फ़ाइल को इस प्रोसेस को आसान बनाने के लिए डिज़ाइन किया गया है.

अगर आपको टेस्ट एक्सएमएल फ़ाइल को पसंद के मुताबिक बनाना है, तो अपने-आप जनरेट हुई फ़ाइल का इस्तेमाल शुरुआती बिंदु के तौर पर किया जा सकता है.

अपने-आप जनरेट हुई टेस्ट कॉन्फ़िगरेशन फ़ाइल ढूंढने के लिए, सबसे पहले कॉन्फ़िगरेशन बनाने के लिए make कमांड चलाएं, जैसा कि यहां दिखाया गया है.

$ m VtsHalUsbV1_1TargetTest

अपनी बिल्ड आउट डायरेक्ट्री में, मॉड्यूल के नाम के आधार पर कॉन्फ़िगरेशन फ़ाइल को खोजा जा सकता है. इसका तरीका यहां बताया गया है.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

फ़ाइल की कई कॉपी हो सकती हैं और उनमें से किसी भी कॉपी का इस्तेमाल किया जा सकता है. .config फ़ाइल को उस डायरेक्ट्री में कॉपी करें जहां Android.bp फ़ाइल मौजूद है.

अगर Android.bp फ़ाइल में सिर्फ़ एक टेस्ट मॉड्यूल है, तो एक्सएमएल फ़ाइल का नाम बदलकर AndroidTest.xml किया जा सकता है. ऐसा करने पर, बिल्ड सिस्टम अपने-आप उस फ़ाइल को टेस्ट मॉड्यूल की कॉन्फ़िगरेशन फ़ाइल के तौर पर इस्तेमाल करता है. अगर ऐसा नहीं है, तो मॉड्यूल में test_config एट्रिब्यूट जोड़ें, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है.

test_config: "VtsHalUsbV1_1TargetTest.xml",

अब आपके पास टेस्ट कॉन्फ़िगरेशन फ़ाइल है, जिससे आपको पसंद के मुताबिक बदलाव करने में मदद मिलेगी.

adb root की मदद से टेस्ट को ज़बरदस्ती चलाना

ज़्यादातर वीटीएस टेस्ट को चलाने के लिए, रूट प्रिविलेज की ज़रूरत होती है. अगर जांच की कॉन्फ़िगरेशन फ़ाइल अपने-आप जनरेट होती है, तो Android.bp में यह एट्रिब्यूट जोड़ा जा सकता है.

require_root: true,

अगर टेस्ट कॉन्फ़िगरेशन फ़ाइल को पसंद के मुताबिक बनाया गया है, तो टेस्ट एक्सएमएल फ़ाइल में ये जोड़ें.

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

जांच के दौरान फ़्रेमवर्क को रोकना

कई VTS टेस्ट के लिए, Android फ़्रेमवर्क की ज़रूरत नहीं होती. साथ ही, फ़्रेमवर्क के बंद होने पर टेस्ट को चलाने से, डिवाइस के फ़्लेक का असर पड़े बिना, टेस्ट को स्थिरता के साथ चलाया जा सकता है. अगर जांच की कॉन्फ़िगरेशन फ़ाइल अपने-आप जनरेट होती है, तो Android.bp में यह एट्रिब्यूट जोड़ा जा सकता है.

disable_framework: true,

अगर टेस्ट कॉन्फ़िगरेशन फ़ाइल को पसंद के मुताबिक बनाया गया है, तो टेस्ट एक्सएमएल फ़ाइल में ये जोड़ें.

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

टेस्ट के लिए अतिरिक्त आर्ग्युमेंट जोड़ना

कुछ gtest टेस्ट को चलने में ज़्यादा समय लग सकता है. ऐसे मामलों में, एक्सएमएल फ़ाइल में टेस्ट रनर के विकल्प जोड़े जा सकते हैं.

उदाहरण के लिए, नीचे दी गई एंट्री में native-test-timeout सेटिंग की मदद से, जांच को डिफ़ॉल्ट तौर पर एक मिनट के बजाय, तीन मिनट के टाइम आउट के साथ चलाया जा सकता है.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

कम से कम एपीआई लेवल की ज़रूरत है

कुछ VTS टेस्ट, सिर्फ़ कम से कम एपीआई लेवल वाले डिवाइसों पर चलाए जा सकते हैं. अगर जांच की कॉन्फ़िगरेशन फ़ाइल अपने-आप जनरेट होती है, तो Android.bp में यह एट्रिब्यूट जोड़ा जा सकता है.

min_shipping_api_level: 29,

या

vsr_min_shipping_api_level: 202404,

अगर टेस्ट कॉन्फ़िगरेशन फ़ाइल को पसंद के मुताबिक बनाया गया है, तो टेस्ट एक्सएमएल फ़ाइल में यह कमांड जोड़ें.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

या

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="vsr-min-api-level" value="202404" />
   </object>

एपीआई लेवल की प्रॉपर्टी

Android 12 में ro.board.first_api_level और ro.board.api_level प्रॉपर्टी की जानकारी दी गई है, ताकि इन डिवाइसों पर वेंडर इमेज का एपीआई लेवल दिखाया जा सके. इन प्रॉपर्टी को ro.product.first_api_level के साथ जोड़कर, टेस्ट सुइट डिवाइसों के लिए सही टेस्ट केस चुनते हैं.

Android 13 में ro.vendor.api_level की जानकारी दी गई है. यह ro.product.first_api_level, ro.board.first_api_level, और ro.board.api_level प्रॉपर्टी का इस्तेमाल करके, ज़रूरी वेंडर एपीआई लेवल का हिसाब लगाकर अपने-आप सेट हो जाता है.

ज़्यादा जानकारी के लिए, वेंडर एपीआई लेवल देखें.

ro.board.first_api_level

ro.board.first_api_level प्रॉपर्टी, एपीआई लेवल तब होती है, जब वेंडर फ़्रीज़ की ज़रूरी शर्तें पूरी करने वाले SoC के लिए, वेंडर इमेज को पहली बार इस प्रॉपर्टी के साथ रिलीज़ किया जाता है. यह डिवाइस के लॉन्चिंग एपीआई लेवल पर निर्भर नहीं करता, बल्कि सिर्फ़ SoC के पहले एपीआई लेवल पर निर्भर करता है. यह वैल्यू, SoC के लाइफ़टाइम के लिए हमेशा के लिए सेट होती है.

ro.board.first_api_level सेट करने के लिए, डिवाइस बनाने वाली कंपनियां अपनी device.mk फ़ाइल में BOARD_SHIPPING_API_LEVEL तय कर सकती हैं. उदाहरण के लिए:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

इससे, डिवाइस पर ro.board.first_api_level प्रॉपर्टी अपने-आप vendor/build.prop पर सेट हो जाएगी. यह प्रॉपर्टी, वेंडर की init प्रोसेस से सेट की जाती है.

ro.board.api_level

ro.board.api_level प्रॉपर्टी, वेंडर इमेज का मौजूदा वेंडर एपीआई लेवल है. इन इमेज का YYYYMM फ़ॉर्मैट होता है, जिसमें वेंडर एपीआई को फ़्रीज़ किया गया था. इसे बिल्ड सिस्टम अपने-आप सेट करता है.

ro.vendor.api_level

ro.vendor.api_level प्रॉपर्टी को Android 13 में इसलिए जोड़ा गया था, ताकि यह पता चल सके कि वेंडर इमेज के लिए कौनसा एपीआई लेवल ज़रूरी है. यह एट्रिब्यूट अपने-आप ro.product.first_api_level पर सेट होता है. अगर ro.board.first_api_level मौजूद है और ro.board.api_level को ro.product.first_api_level से पहले के एपीआई लेवल पर सेट किया गया है, तो यह एट्रिब्यूट ro.board.api_level पर सेट होता है. अगर वर्शन को ro.product.first_api_level से 35 या उससे ज़्यादा के वर्शन पर सेट किया गया है, तो उस वर्शन को वेंडर के एपीआई लेवल से बदल दिया जाएगा. इस प्रॉपर्टी का रेफ़रंस देकर, वेंडर के लागू किए गए ऐसे टेस्ट को SoC के लिए वेंडर की ज़रूरी शर्तों से बाहर रखा जा सकता है जिनके लिए वेंडर इमेज को अपग्रेड करना ज़रूरी है.

VTS का इस्तेमाल करके, डेटा को अलग-अलग हिस्सों में बांटने की प्रोसेस

Android के 10 या उसके बाद के वर्शन के लिए, एक से ज़्यादा डिवाइसों पर, टारगेट किए गए डिवाइसों के ग्रुप बनाने की प्रोसेस की जा सकती है. इसके लिए, यहां दिए गए निर्देशों का पालन करें. साथ ही, VTS और CTS-on-GSI, दोनों प्लान के साथ टेस्टिंग करें.

run vts --shard-count <number of devices> -s <device serial> ...

यह कमांड, VTS प्लान को कई हिस्सों में बांटता है और उन्हें कई डिवाइसों पर चलाता है.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

यह कमांड, GSI पर चलने वाले CTS प्लान को स्HARD में बांटता है और उन्हें कई डिवाइसों पर चलाता है.