टेस्ट सेटअप

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

टेस्ट सुइट

वीटीएस का हिस्सा बनने के लिए टेस्ट में, नीचे दी गई सेटिंग होनी चाहिए 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"/>

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

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

disable_framework: true,

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

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

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

कुछ gtest टेस्ट को चलने में ज़्यादा समय लग सकता है. ऐसे मामलों में, आपके पास परीक्षण रनर विकल्पों की जांच करें.

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

   <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 को सेट करने के लिए, डिवाइस बनाने वाली कंपनियां इसे सेट कर सकती हैं BOARD_SHIPPING_API_LEVEL की device.mk फ़ाइल में, जैसा कि यहां दिखाया गया है उदाहरण:

  # 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.api_level अगर ro.board.first_api_level मौजूद है और ro.board.api_level ro.product.first_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 में बांटता है और उन्हें कई डिवाइसों पर चलाता है.