टेस्ट सेटअप

टेस्ट सुइट

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

test_suites: ["vts"],

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

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

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

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

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

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

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

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

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 प्लान को कई हिस्सों में बांट दिया जाता है और उन्हें कई डिवाइसों पर चलाया जाता है.