हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

इस्तेमाल किए जा सकने वाले टैग की सूची

AndroidTest.xml या ज़्यादा मोटे तौर पर मॉड्यूल कॉन्फ़िगरेशन में सिर्फ़ नीचे दिए गए एक्सएमएल टैग: target_preparer, multi_target_preparer, test और metrics_collector.

हालांकि वह सूची प्रतिबंधित लगती है, फिर भी वह आपको के लिए टेस्ट मॉड्यूल सेटअप की ज़रूरत है.

ध्यान दें: ट्रेड किया गया एक्सएमएल कॉन्फ़िगरेशन देखें ताकि आपको अलग-अलग टैग के बारे में पता चल सके.

अगर build_provider या result_reporter जैसे ऑब्जेक्ट को मॉड्यूल कॉन्फ़िगरेशन के अंदर से चलाने की कोशिश की जाती है, तो ConfigurationException दिखेगा. इसका मकसद, इन ऑब्जेक्ट को किसी मॉड्यूल में कोई टास्क करने से रोकना है.

मॉड्यूल कॉन्फ़िगरेशन का उदाहरण

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

यह कॉन्फ़िगरेशन ऐसे टेस्ट के बारे में बताता है जिसे करने के लिए CtsGestureTestCases.apk की ज़रूरत होती है को इंस्टॉल किया जाएगा और android.gesture.cts के ख़िलाफ़ इंस्ट्रुमेंटेशन चलाएगा पैकेज.

`<include>` और `<template-include>` को शामिल करने से जुड़े टैग

मॉड्यूल कॉन्फ़िगरेशन में <include> और <template-include> का इस्तेमाल इस तरह से किया जा रहा है निराश होकर इस बात की कोई गारंटी नहीं है कि ये उम्मीद के मुताबिक काम करेंगे.

Metrics_collector टैग के लिए खास केस

metrics_collector की अनुमति है, लेकिन यह इन तक ही सीमित है FilePullerLogCollector क्लास का उपयोग करें, ताकि दी गई फ़ाइल या डायरेक्ट्री को मॉड्यूल का इस्तेमाल करना होगा. यह तब काम आता है, जब आपको किसी खास जगह पर लॉग सेव करने हैं और उन्हें अपने-आप वापस पाना है.

कॉन्फ़िगरेशन का उदाहरण:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

बिल्ड की जानकारी या डाउनलोड की क्या स्थिति है?

इस्तेमाल किए जा सकने वाले टैग की परिभाषा से यह गलत धारणा बन सकती है कि किसी मॉड्यूल को बिल्ड की कोई जानकारी नहीं मिलेगी. यह सही नहीं है.

बिल्ड की जानकारी, सुइट लेवल के सेटअप से दी जाती है. इसे सुइट के सभी मॉड्यूल शेयर किए जाते हैं. इससे, सुइट के सभी मॉड्यूल को चलाने के लिए, सुइट के लिए एक टॉप-लेवल सेटअप की अनुमति मिलती है.

उदाहरण के लिए, हर कंपैटिबिलिटी टेस्ट सुइट (CTS) मॉड्यूल के लिए, डिवाइस की जानकारी, टाइप वगैरह के बारे में अलग-अलग क्वेरी करने के बजाय, CTS सुइट-लेवल सेटअप (cts.xml) एक बार में यह काम करता है. साथ ही, अगर कोई मॉड्यूल इस जानकारी का अनुरोध करता है, तो उसे यह जानकारी मिल जाएगी.

मॉड्यूल में मौजूद ऑब्जेक्ट को बिल्ड की जानकारी मिल सके, इसके लिए उन्हें इन चीज़ों की ज़रूरत होती है इसे सामान्य ट्रेडेड कॉन्फ़िगरेशन की तरह ही इस्तेमाल करना चाहिए: अपने IBuildInfo पाने के लिए IBuildReceiver इंटरफ़ेस. यहां जाएं: डिवाइस की मदद से टेस्ट करना देखें.

मेटाडेटा फ़ील्ड

बड़ी संख्या में टेस्ट मॉड्यूल में, metadata की कुछ खास बातें शामिल होती हैं, और हर यूआरएल का अपना अलग लक्ष्य होता है.

उदाहरण:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

कॉम्पोनेंट

component मेटाडेटा, उस सामान्य Android कॉम्पोनेंट के बारे में बताता है जिसे मॉड्यूल से टेस्ट करना है. इसका असर, टेस्ट के लागू होने पर सीधे तौर पर नहीं पड़ता. इसका इस्तेमाल मुख्य रूप से संगठन के कामों के लिए किया जाता है.

सीटीएस के लिए अनुमति वाले कॉम्पोनेंट की अप-टू-डेट सूची यहां उपलब्ध है CtsConfigLoadingTest. अगर किसी ऐसे कॉम्पोनेंट को जोड़ा गया है जो पहले से मौजूद नहीं है, तो यह जांच पहले से सबमिट करने में फ़ेल हो जाती है सीटीएस मॉड्यूल.

कॉम्पोनेंट के हिसाब से, सुइट के रन को फ़िल्टर किया जा सकता है module-metadata-include-filter और module-metadata-exclude-filter.

उदाहरण:

  --module-metadata-include-filter component framework

यह उदाहरण सिर्फ़ framework के साथ एनोटेट किए गए टेस्ट मॉड्यूल को चलाता है कॉम्पोनेंट.

पैरामीटर

parameter मेटाडेटा, जानकारी देने वाला होता है और इससे टेस्ट के लागू होने पर असर पड़ता है. इससे तय होता है कि टेस्ट मॉड्यूल किस Android मोड पर लागू होता है. इस मामले में, मोड सिर्फ़ Android के हाई लेवल मोड पर लागू होते हैं. जैसे, instant apps, secondary users या different abis.

सुइट में चलने के दौरान, अगर टेस्ट पर मोड लागू होता है, तो विज्ञापन दिखाने के अलग-अलग तरीके टेस्ट मॉड्यूल के आधार पर बनाए जाते हैं. हर वैरिएंट, मिलते-जुलते टेस्ट चलाता है, लेकिन अलग-अलग मोड में.

instant_app: अलग-अलग टेस्ट के ऐसे वैरिएशन बनाएं जो APK को इस रूप में इंस्टॉल करें इंस्टैंट ऐप्लिकेशन.
multi_abi: डिवाइस पर काम करने वाले हर एबीआई के लिए, टेस्ट का वैरिएशन बनाएं.
secondary_user: उन टेस्ट का वैरिएशन बनाएं जो APKs इंस्टॉल करते हैं और दूसरे उपयोगकर्ता के तौर पर टेस्ट चलाते हैं.

परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मेट्रिक इकट्ठा करने और पोस्ट-प्रोसेस करने की सुविधा

परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मॉड्यूल-लेवल metrics_collector और metric_post_processor का इस्तेमाल किया जा सकता है, क्योंकि ये परफ़ॉर्मेंस टेस्ट के लिए ज़रूरी हैं. मॉड्यूल-लेवल मेट्रिक कलेक्टर और पोस्ट-प्रोसेसर, मॉड्यूल के हिसाब से हो सकते हैं. हमारा सुझाव है कि पोस्ट-प्रोसेसर को टॉप-लेवल और मॉड्यूल, दोनों लेवल पर न जोड़ें.

परफ़ॉर्मेंस टेस्ट मॉड्यूल कॉन्फ़िगरेशन में, test-type मेटाडेटा के साथ performance वैल्यू शामिल होनी चाहिए. जैसे: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> इसके बिना, अगर किसी टेस्ट कॉन्फ़िगरेशन में FilePullerLogCollector या किसी metric_post_processor के अलावा कोई metric_collector शामिल है, तो टेस्ट सबमिट करने से पहले ही वह पूरा नहीं होता.

परफ़ॉर्मेंस टेस्ट मॉड्यूल के कॉन्फ़िगरेशन का उदाहरण:

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>