सेटअप की जांच करें

टेस्ट सुइट

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

test_suites: ["vts"],

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

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

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

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

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

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

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

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

कई 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>

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

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

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