टेस्ट सेटअप

टेस्ट सुइट

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

test_suites: ["vts"],

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

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

ज़्यादातर मामलों में, टेस्ट कॉन्फ़िगरेशन, जो कि एक एक्सएमएल फ़ाइल होती है और जिसका इस्तेमाल 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 रूट के साथ टेस्ट को रन करना

ज़्यादातर VTS टेस्ट को रन करने के लिए, रूट के तौर पर काम करने की अनुमति की ज़रूरत होती है. अगर टेस्ट कॉन्फ़िगरेशन फ़ाइल अपने-आप जनरेट हुई है, तो 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

इससे डिवाइस पर, vendor/build.prop के लिए ro.board.first_api_level प्रॉपर्टी अपने-आप तय हो जाएगी. यह प्रॉपर्टी, वेंडर की 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 ...

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