सरल निर्माण विन्यास

मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए प्रत्येक नए परीक्षण मॉड्यूल में कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। Android अब सरल परीक्षण कॉन्फ़िगरेशन के लिए सूंग बिल्ड सिस्टम का उपयोग करता है।

सूंग ब्लूप्रिंट या .bp फ़ाइलों का उपयोग करता है, जो बनाने के लिए मॉड्यूल के JSON-जैसे सरल घोषणात्मक विवरण हैं। यह प्रारूप पिछले रिलीज़ में उपयोग किए गए मेक-आधारित सिस्टम को प्रतिस्थापित करता है। पूर्ण विवरण के लिए सतत एकीकरण डैशबोर्ड पर सूंग संदर्भ फ़ाइलें देखें।

कस्टम परीक्षण को समायोजित करने या Android संगतता परीक्षण सूट (CTS) का उपयोग करने के लिए, इसके बजाय जटिल परीक्षण कॉन्फ़िगरेशन का पालन करें।

उदाहरण

नीचे दी गई प्रविष्टियाँ इस उदाहरण ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल से आती हैं: /platform_testing/tests/example/instrumentation/Android.bp

सुविधा के लिए यहां एक स्नैपशॉट शामिल किया गया है:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

ध्यान दें कि शुरुआत में android_test घोषणा इंगित करती है कि यह एक परीक्षण है। android_app सहित इसके विपरीत यह इंगित करेगा कि यह एक बिल्ड पैकेज है।

समायोजन

निम्नलिखित सेटिंग्स स्पष्टीकरण प्राप्त करती हैं:

    name: "HelloWorldTests",

android_test मॉड्यूल प्रकार निर्दिष्ट होने पर (ब्लॉक की शुरुआत में) name सेटिंग की आवश्यकता होती है। यह आपके मॉड्यूल को एक नाम देता है, और परिणामी APK को वही नाम दिया जाएगा और एक .apk प्रत्यय के साथ, उदाहरण के लिए इस मामले में, परिणामी परीक्षण APK को HelloWorldTests.apk नाम दिया गया है। इसके अलावा, यह आपके मॉड्यूल के लिए एक लक्ष्य नाम भी परिभाषित करता है, ताकि आप अपने परीक्षण मॉड्यूल और इसकी सभी निर्भरताओं को बनाने के लिए make [options] <HelloWorldTests> उपयोग कर सकें।

    static_libs: ["androidx.test.runner"],

static_libs सेटिंग वर्तमान मॉड्यूल के परिणामी एपीके में नामित मॉड्यूल की सामग्री को शामिल करने के लिए बिल्ड सिस्टम को निर्देश देती है। इसका मतलब है कि प्रत्येक नामित मॉड्यूल से एक .jar फ़ाइल बनाने की अपेक्षा की जाती है, और इसकी सामग्री का उपयोग संकलन समय के दौरान क्लासपाथ संदर्भों को हल करने के लिए किया जाएगा, साथ ही परिणामी एपीके में शामिल किया जाएगा।

androidx.test.runner मॉड्यूल AndroidX टेस्ट रनर लाइब्रेरी के लिए पहले से बनाया गया है, जिसमें टेस्ट रनर AndroidJUnitRunner शामिल है। AndroidJUnitRunner JUnit4 परीक्षण ढांचे का समर्थन करता है और Android 10 में InstrumentationTestRunner प्रतिस्थापित करता है । Android पर परीक्षण ऐप्स पर Android ऐप्स के परीक्षण के बारे में और पढ़ें।

यदि आप एक नया इंस्ट्रूमेंटेशन मॉड्यूल बना रहे हैं, तो आपको हमेशा अपने टेस्ट रनर के रूप में androidx.test.runner लाइब्रेरी से शुरुआत करनी चाहिए। प्लेटफ़ॉर्म सोर्स ट्री में अन्य उपयोगी परीक्षण ढाँचे भी शामिल हैं जैसे कि ub-uiautomator , mockito-target , easymock और बहुत कुछ।

    certificate: "platform",

certificate सेटिंग बिल्ड सिस्टम को कोर प्लेटफॉर्म के समान सर्टिफिकेट के साथ एपीके पर हस्ताक्षर करने का निर्देश देती है। यह आवश्यक है यदि आपका परीक्षण हस्ताक्षर संरक्षित अनुमति या एपीआई का उपयोग करता है। ध्यान दें कि यह प्लेटफ़ॉर्म निरंतर परीक्षण के लिए उपयुक्त है, लेकिन इसका उपयोग CTS परीक्षण मॉड्यूल में नहीं किया जाना चाहिए। ध्यान दें कि यह उदाहरण केवल चित्रण के उद्देश्य से इस प्रमाणपत्र सेटिंग का उपयोग करता है: उदाहरण के परीक्षण कोड को विशेष प्लेटफ़ॉर्म प्रमाणपत्र के साथ हस्ताक्षर करने के लिए वास्तव में परीक्षण एपीके की आवश्यकता नहीं होती है।

यदि आप अपने कंपोनेंट के लिए एक इंस्ट्रूमेंटेशन लिख रहे हैं जो सिस्टम सर्वर के बाहर रहता है, यानी, इसे नियमित ऐप एपीके की तरह कम या ज्यादा पैक किया जाता है, सिवाय इसके कि यह सिस्टम इमेज में बनाया गया है और एक विशेषाधिकार प्राप्त ऐप हो सकता है, संभावना है कि आपका इंस्ट्रूमेंटेशन होगा अपने घटक के ऐप पैकेज (मेनिफ़ेस्ट के बारे में नीचे अनुभाग देखें) को लक्षित करें। इस मामले में, आपके एप्लिकेशन मेकफ़ाइल की अपनी certificate सेटिंग हो सकती है, और आपके इंस्ट्रूमेंटेशन मॉड्यूल को उसी सेटिंग को बनाए रखना चाहिए। ऐसा इसलिए है क्योंकि परीक्षण के तहत ऐप पर आपके इंस्ट्रूमेंटेशन को लक्षित करने के लिए, आपके टेस्ट एपीके और ऐप एपीके को एक ही प्रमाणपत्र के साथ हस्ताक्षरित होना चाहिए।

अन्य मामलों में, आपको इस सेटिंग की बिल्कुल भी आवश्यकता नहीं है: बिल्ड सिस्टम इसे बिल्ड संस्करण के आधार पर एक डिफ़ॉल्ट अंतर्निहित प्रमाणपत्र के साथ बस साइन करेगा, और इसे आमतौर पर dev-keys कहा जाता है।

    test_suites: ["device-tests"],

test_suites सेटिंग ट्रेड फेडरेशन टेस्ट हार्नेस द्वारा परीक्षण को आसानी से खोजने योग्य बनाती है। अन्य सुइट्स को यहां जोड़ा जा सकता है जैसे सीटीएस ताकि यह परीक्षण साझा किया जा सके।

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

वैकल्पिक सेटिंग्स

निम्नलिखित वैकल्पिक सेटिंग्स स्पष्टीकरण प्रदान करती हैं:

    test_config: "path/to/hello_world_test.xml"

test_config सेटिंग बिल्ड सिस्टम को निर्देश देती है कि आपके परीक्षण लक्ष्य को एक विशिष्ट कॉन्फ़िगरेशन की आवश्यकता है। डिफ़ॉल्ट रूप से, Android.bp बगल में एक AndroidTest.xml कॉन्फ़िगरेशन के साथ जुड़ा हुआ है।

    auto_gen_config: true

auto_gen_config सेटिंग इंगित करती है कि टेस्ट कॉन्फ़िग को स्वचालित रूप से बनाना है या नहीं। यदि AndroidTest.xml Android.bp बगल में मौजूद नहीं है, तो इस विशेषता को स्पष्ट रूप से सत्य पर सेट करने की आवश्यकता नहीं है।

    require_root: true

require_root सेटिंग ऑटो जनरेटेड टेस्ट कॉन्फ़िगरेशन में RootTargetPreparer को जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। यह रूट अनुमतियों के साथ परीक्षण चलाने की गारंटी देता है।

    test_min_api_level: 29

test_min_api_level सेटिंग स्वचालित रूप से उत्पन्न परीक्षण कॉन्फ़िगरेशन में MinApiLevelModuleController जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। जब ट्रेड फ़ेडरेशन परीक्षण कॉन्फ़िगरेशन चलाता है, तो परीक्षण को छोड़ दिया जाएगा यदि ro.product.first_api_level < test_min_api_level की डिवाइस संपत्ति।

,

मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए प्रत्येक नए परीक्षण मॉड्यूल में कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। Android अब सरल परीक्षण कॉन्फ़िगरेशन के लिए सूंग बिल्ड सिस्टम का उपयोग करता है।

सूंग ब्लूप्रिंट या .bp फ़ाइलों का उपयोग करता है, जो बनाने के लिए मॉड्यूल के JSON-जैसे सरल घोषणात्मक विवरण हैं। यह प्रारूप पिछले रिलीज़ में उपयोग किए गए मेक-आधारित सिस्टम को प्रतिस्थापित करता है। पूर्ण विवरण के लिए सतत एकीकरण डैशबोर्ड पर सूंग संदर्भ फ़ाइलें देखें।

कस्टम परीक्षण को समायोजित करने या Android संगतता परीक्षण सूट (CTS) का उपयोग करने के लिए, इसके बजाय जटिल परीक्षण कॉन्फ़िगरेशन का पालन करें।

उदाहरण

नीचे दी गई प्रविष्टियाँ इस उदाहरण ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल से आती हैं: /platform_testing/tests/example/instrumentation/Android.bp

सुविधा के लिए यहां एक स्नैपशॉट शामिल किया गया है:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

ध्यान दें कि शुरुआत में android_test घोषणा इंगित करती है कि यह एक परीक्षण है। android_app सहित इसके विपरीत यह इंगित करेगा कि यह एक बिल्ड पैकेज है।

समायोजन

निम्नलिखित सेटिंग्स स्पष्टीकरण प्राप्त करती हैं:

    name: "HelloWorldTests",

android_test मॉड्यूल प्रकार निर्दिष्ट होने पर (ब्लॉक की शुरुआत में) name सेटिंग की आवश्यकता होती है। यह आपके मॉड्यूल को एक नाम देता है, और परिणामी APK को वही नाम दिया जाएगा और एक .apk प्रत्यय के साथ, उदाहरण के लिए इस मामले में, परिणामी परीक्षण APK को HelloWorldTests.apk नाम दिया गया है। इसके अलावा, यह आपके मॉड्यूल के लिए एक लक्ष्य नाम भी परिभाषित करता है, ताकि आप अपने परीक्षण मॉड्यूल और इसकी सभी निर्भरताओं को बनाने के लिए make [options] <HelloWorldTests> उपयोग कर सकें।

    static_libs: ["androidx.test.runner"],

static_libs सेटिंग वर्तमान मॉड्यूल के परिणामी एपीके में नामित मॉड्यूल की सामग्री को शामिल करने के लिए बिल्ड सिस्टम को निर्देश देती है। इसका मतलब है कि प्रत्येक नामित मॉड्यूल से एक .jar फ़ाइल बनाने की अपेक्षा की जाती है, और इसकी सामग्री का उपयोग संकलन समय के दौरान क्लासपाथ संदर्भों को हल करने के लिए किया जाएगा, साथ ही परिणामी एपीके में शामिल किया जाएगा।

androidx.test.runner मॉड्यूल AndroidX टेस्ट रनर लाइब्रेरी के लिए पहले से बनाया गया है, जिसमें टेस्ट रनर AndroidJUnitRunner शामिल है। AndroidJUnitRunner JUnit4 परीक्षण ढांचे का समर्थन करता है और Android 10 में InstrumentationTestRunner प्रतिस्थापित करता है । Android पर परीक्षण ऐप्स पर Android ऐप्स के परीक्षण के बारे में और पढ़ें।

यदि आप एक नया इंस्ट्रूमेंटेशन मॉड्यूल बना रहे हैं, तो आपको हमेशा अपने टेस्ट रनर के रूप में androidx.test.runner लाइब्रेरी से शुरुआत करनी चाहिए। प्लेटफ़ॉर्म सोर्स ट्री में अन्य उपयोगी परीक्षण ढाँचे भी शामिल हैं जैसे कि ub-uiautomator , mockito-target , easymock और बहुत कुछ।

    certificate: "platform",

certificate सेटिंग बिल्ड सिस्टम को कोर प्लेटफॉर्म के समान सर्टिफिकेट के साथ एपीके पर हस्ताक्षर करने का निर्देश देती है। यह आवश्यक है यदि आपका परीक्षण हस्ताक्षर संरक्षित अनुमति या एपीआई का उपयोग करता है। ध्यान दें कि यह प्लेटफ़ॉर्म निरंतर परीक्षण के लिए उपयुक्त है, लेकिन इसका उपयोग CTS परीक्षण मॉड्यूल में नहीं किया जाना चाहिए। ध्यान दें कि यह उदाहरण केवल चित्रण के उद्देश्य से इस प्रमाणपत्र सेटिंग का उपयोग करता है: उदाहरण के परीक्षण कोड को विशेष प्लेटफ़ॉर्म प्रमाणपत्र के साथ हस्ताक्षर करने के लिए वास्तव में परीक्षण एपीके की आवश्यकता नहीं होती है।

यदि आप अपने कंपोनेंट के लिए एक इंस्ट्रूमेंटेशन लिख रहे हैं जो सिस्टम सर्वर के बाहर रहता है, यानी, इसे नियमित ऐप एपीके की तरह कम या ज्यादा पैक किया जाता है, सिवाय इसके कि यह सिस्टम इमेज में बनाया गया है और एक विशेषाधिकार प्राप्त ऐप हो सकता है, संभावना है कि आपका इंस्ट्रूमेंटेशन होगा अपने घटक के ऐप पैकेज (मेनिफ़ेस्ट के बारे में नीचे अनुभाग देखें) को लक्षित करें। इस मामले में, आपके एप्लिकेशन मेकफ़ाइल की अपनी certificate सेटिंग हो सकती है, और आपके इंस्ट्रूमेंटेशन मॉड्यूल को उसी सेटिंग को बनाए रखना चाहिए। ऐसा इसलिए है क्योंकि परीक्षण के तहत ऐप पर आपके इंस्ट्रूमेंटेशन को लक्षित करने के लिए, आपके टेस्ट एपीके और ऐप एपीके को एक ही प्रमाणपत्र के साथ हस्ताक्षरित होना चाहिए।

अन्य मामलों में, आपको इस सेटिंग की बिल्कुल भी आवश्यकता नहीं है: बिल्ड सिस्टम इसे बिल्ड संस्करण के आधार पर एक डिफ़ॉल्ट अंतर्निहित प्रमाणपत्र के साथ बस साइन करेगा, और इसे आमतौर पर dev-keys कहा जाता है।

    test_suites: ["device-tests"],

test_suites सेटिंग ट्रेड फेडरेशन टेस्ट हार्नेस द्वारा परीक्षण को आसानी से खोजने योग्य बनाती है। अन्य सुइट्स को यहां जोड़ा जा सकता है जैसे सीटीएस ताकि यह परीक्षण साझा किया जा सके।

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

वैकल्पिक सेटिंग्स

निम्नलिखित वैकल्पिक सेटिंग्स स्पष्टीकरण प्रदान करती हैं:

    test_config: "path/to/hello_world_test.xml"

test_config सेटिंग बिल्ड सिस्टम को निर्देश देती है कि आपके परीक्षण लक्ष्य को एक विशिष्ट कॉन्फ़िगरेशन की आवश्यकता है। डिफ़ॉल्ट रूप से, Android.bp बगल में एक AndroidTest.xml कॉन्फ़िगरेशन के साथ जुड़ा हुआ है।

    auto_gen_config: true

auto_gen_config सेटिंग इंगित करती है कि टेस्ट कॉन्फ़िग को स्वचालित रूप से बनाना है या नहीं। यदि AndroidTest.xml Android.bp बगल में मौजूद नहीं है, तो इस विशेषता को स्पष्ट रूप से सत्य पर सेट करने की आवश्यकता नहीं है।

    require_root: true

require_root सेटिंग ऑटो जनरेटेड टेस्ट कॉन्फ़िगरेशन में RootTargetPreparer को जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। यह रूट अनुमतियों के साथ परीक्षण चलाने की गारंटी देता है।

    test_min_api_level: 29

test_min_api_level सेटिंग स्वचालित रूप से उत्पन्न परीक्षण कॉन्फ़िगरेशन में MinApiLevelModuleController जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। जब ट्रेड फ़ेडरेशन परीक्षण कॉन्फ़िगरेशन चलाता है, तो परीक्षण को छोड़ दिया जाएगा यदि ro.product.first_api_level < test_min_api_level की डिवाइस संपत्ति।

,

मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए प्रत्येक नए परीक्षण मॉड्यूल में कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। Android अब सरल परीक्षण कॉन्फ़िगरेशन के लिए सूंग बिल्ड सिस्टम का उपयोग करता है।

सूंग ब्लूप्रिंट या .bp फ़ाइलों का उपयोग करता है, जो बनाने के लिए मॉड्यूल के JSON-जैसे सरल घोषणात्मक विवरण हैं। यह प्रारूप पिछले रिलीज़ में उपयोग किए गए मेक-आधारित सिस्टम को प्रतिस्थापित करता है। पूर्ण विवरण के लिए सतत एकीकरण डैशबोर्ड पर सूंग संदर्भ फ़ाइलें देखें।

कस्टम परीक्षण को समायोजित करने या Android संगतता परीक्षण सूट (CTS) का उपयोग करने के लिए, इसके बजाय जटिल परीक्षण कॉन्फ़िगरेशन का पालन करें।

उदाहरण

नीचे दी गई प्रविष्टियाँ इस उदाहरण ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल से आती हैं: /platform_testing/tests/example/instrumentation/Android.bp

सुविधा के लिए यहां एक स्नैपशॉट शामिल किया गया है:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

ध्यान दें कि शुरुआत में android_test घोषणा इंगित करती है कि यह एक परीक्षण है। android_app सहित इसके विपरीत यह इंगित करेगा कि यह एक बिल्ड पैकेज है।

समायोजन

निम्नलिखित सेटिंग्स स्पष्टीकरण प्राप्त करती हैं:

    name: "HelloWorldTests",

android_test मॉड्यूल प्रकार निर्दिष्ट होने पर (ब्लॉक की शुरुआत में) name सेटिंग की आवश्यकता होती है। यह आपके मॉड्यूल को एक नाम देता है, और परिणामी APK को वही नाम दिया जाएगा और एक .apk प्रत्यय के साथ, उदाहरण के लिए इस मामले में, परिणामी परीक्षण APK को HelloWorldTests.apk नाम दिया गया है। इसके अलावा, यह आपके मॉड्यूल के लिए एक लक्ष्य नाम भी परिभाषित करता है, ताकि आप अपने परीक्षण मॉड्यूल और इसकी सभी निर्भरताओं को बनाने के लिए make [options] <HelloWorldTests> उपयोग कर सकें।

    static_libs: ["androidx.test.runner"],

static_libs सेटिंग वर्तमान मॉड्यूल के परिणामी एपीके में नामित मॉड्यूल की सामग्री को शामिल करने के लिए बिल्ड सिस्टम को निर्देश देती है। इसका मतलब है कि प्रत्येक नामित मॉड्यूल से एक .jar फ़ाइल बनाने की अपेक्षा की जाती है, और इसकी सामग्री का उपयोग संकलन समय के दौरान क्लासपाथ संदर्भों को हल करने के लिए किया जाएगा, साथ ही परिणामी एपीके में शामिल किया जाएगा।

androidx.test.runner मॉड्यूल AndroidX टेस्ट रनर लाइब्रेरी के लिए पहले से बनाया गया है, जिसमें टेस्ट रनर AndroidJUnitRunner शामिल है। AndroidJUnitRunner JUnit4 परीक्षण ढांचे का समर्थन करता है और Android 10 में InstrumentationTestRunner प्रतिस्थापित करता है । Android पर परीक्षण ऐप्स पर Android ऐप्स के परीक्षण के बारे में और पढ़ें।

यदि आप एक नया इंस्ट्रूमेंटेशन मॉड्यूल बना रहे हैं, तो आपको हमेशा अपने टेस्ट रनर के रूप में androidx.test.runner लाइब्रेरी से शुरुआत करनी चाहिए। प्लेटफ़ॉर्म सोर्स ट्री में अन्य उपयोगी परीक्षण ढाँचे भी शामिल हैं जैसे कि ub-uiautomator , mockito-target , easymock और बहुत कुछ।

    certificate: "platform",

certificate सेटिंग बिल्ड सिस्टम को कोर प्लेटफॉर्म के समान सर्टिफिकेट के साथ एपीके पर हस्ताक्षर करने का निर्देश देती है। यह आवश्यक है यदि आपका परीक्षण हस्ताक्षर संरक्षित अनुमति या एपीआई का उपयोग करता है। ध्यान दें कि यह प्लेटफ़ॉर्म निरंतर परीक्षण के लिए उपयुक्त है, लेकिन इसका उपयोग CTS परीक्षण मॉड्यूल में नहीं किया जाना चाहिए। ध्यान दें कि यह उदाहरण केवल चित्रण के उद्देश्य से इस प्रमाणपत्र सेटिंग का उपयोग करता है: उदाहरण के परीक्षण कोड को विशेष प्लेटफ़ॉर्म प्रमाणपत्र के साथ हस्ताक्षर करने के लिए वास्तव में परीक्षण एपीके की आवश्यकता नहीं होती है।

यदि आप अपने कंपोनेंट के लिए एक इंस्ट्रूमेंटेशन लिख रहे हैं जो सिस्टम सर्वर के बाहर रहता है, यानी, इसे नियमित ऐप एपीके की तरह कम या ज्यादा पैक किया जाता है, सिवाय इसके कि यह सिस्टम इमेज में बनाया गया है और एक विशेषाधिकार प्राप्त ऐप हो सकता है, संभावना है कि आपका इंस्ट्रूमेंटेशन होगा अपने घटक के ऐप पैकेज (मेनिफ़ेस्ट के बारे में नीचे अनुभाग देखें) को लक्षित करें। इस मामले में, आपके एप्लिकेशन मेकफ़ाइल की अपनी certificate सेटिंग हो सकती है, और आपके इंस्ट्रूमेंटेशन मॉड्यूल को उसी सेटिंग को बनाए रखना चाहिए। ऐसा इसलिए है क्योंकि परीक्षण के तहत ऐप पर आपके इंस्ट्रूमेंटेशन को लक्षित करने के लिए, आपके टेस्ट एपीके और ऐप एपीके को एक ही प्रमाणपत्र के साथ हस्ताक्षरित होना चाहिए।

अन्य मामलों में, आपको इस सेटिंग की बिल्कुल भी आवश्यकता नहीं है: बिल्ड सिस्टम इसे बिल्ड संस्करण के आधार पर एक डिफ़ॉल्ट अंतर्निहित प्रमाणपत्र के साथ बस साइन करेगा, और इसे आमतौर पर dev-keys कहा जाता है।

    test_suites: ["device-tests"],

test_suites सेटिंग ट्रेड फेडरेशन टेस्ट हार्नेस द्वारा परीक्षण को आसानी से खोजने योग्य बनाती है। अन्य सुइट्स को यहां जोड़ा जा सकता है जैसे सीटीएस ताकि यह परीक्षण साझा किया जा सके।

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

वैकल्पिक सेटिंग्स

निम्नलिखित वैकल्पिक सेटिंग्स स्पष्टीकरण प्रदान करती हैं:

    test_config: "path/to/hello_world_test.xml"

test_config सेटिंग बिल्ड सिस्टम को निर्देश देती है कि आपके परीक्षण लक्ष्य को एक विशिष्ट कॉन्फ़िगरेशन की आवश्यकता है। डिफ़ॉल्ट रूप से, Android.bp बगल में एक AndroidTest.xml कॉन्फ़िगरेशन के साथ जुड़ा हुआ है।

    auto_gen_config: true

auto_gen_config सेटिंग इंगित करती है कि टेस्ट कॉन्फ़िग को स्वचालित रूप से बनाना है या नहीं। यदि AndroidTest.xml Android.bp बगल में मौजूद नहीं है, तो इस विशेषता को स्पष्ट रूप से सत्य पर सेट करने की आवश्यकता नहीं है।

    require_root: true

require_root सेटिंग ऑटो जनरेटेड टेस्ट कॉन्फ़िगरेशन में RootTargetPreparer को जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। यह रूट अनुमतियों के साथ परीक्षण चलाने की गारंटी देता है।

    test_min_api_level: 29

test_min_api_level सेटिंग स्वचालित रूप से उत्पन्न परीक्षण कॉन्फ़िगरेशन में MinApiLevelModuleController जोड़ने के लिए बिल्ड सिस्टम को निर्देश देती है। जब ट्रेड फ़ेडरेशन परीक्षण कॉन्फ़िगरेशन चलाता है, तो परीक्षण को छोड़ दिया जाएगा यदि ro.product.first_api_level < test_min_api_level की डिवाइस संपत्ति।