टेस्ट सेटअप

टेस्ट सुइट

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

test_suites: ["vts"],

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

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

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

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

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

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

अपने-आप जनरेट हुई टेस्ट कॉन्फ़िगरेशन फ़ाइल ढूंढने के लिए, सबसे पहले कॉन्फ़िगरेशन बनाने के लिए 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"/>

टेस्ट के दौरान फ़्रेमवर्क को रोकना

कई वीटीएस टेस्ट को चलाने के लिए, 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>

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

कुछ वीटीएस टेस्ट सिर्फ़ उन डिवाइसों पर चलाए जा सकते हैं जिनमें कम से कम एपीआई लेवल हो. अगर टेस्ट कॉन्फ़िगरेशन फ़ाइल अपने-आप जनरेट होती है, तो 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) के लाइफ़टाइम के लिए स्थायी होती है.

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 process सेट करता है.

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 के लिए वेंडर की ज़रूरी शर्तों से बाहर रखा जा सकता है जिनके लिए वेंडर की इमेज को अपग्रेड करना ज़रूरी है. इसके लिए, इस प्रॉपर्टी का इस्तेमाल किया जा सकता है.

वीटीएस का इस्तेमाल करके शार्डिंग की प्रोसेस

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

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

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

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

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