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

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

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

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

उदाहरण

नीचे दी गई प्रविष्टियाँ इस उदाहरण ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल से आती हैं: /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 प्रत्यय के साथ, उदाहरण के लिए इस मामले में, परिणामी परीक्षण एपीके को HelloWorldTests.apk नाम दिया गया है। इसके अलावा, यह आपके मॉड्यूल के लिए मेक लक्ष्य नाम को भी परिभाषित करता है, ताकि आप अपने परीक्षण मॉड्यूल और उसकी सभी निर्भरताओं को बनाने के लिए make [options] <HelloWorldTests> उपयोग कर सकें।

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

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

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

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

    certificate: "platform",

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

यदि आप अपने घटक के लिए एक इंस्ट्रुमेंटेशन लिख रहे हैं जो सिस्टम सर्वर के बाहर रहता है, यानी, यह लगभग एक नियमित ऐप एपीके की तरह पैक किया गया है, सिवाय इसके कि यह सिस्टम छवि में बनाया गया है और एक विशेषाधिकार प्राप्त ऐप हो सकता है, संभावना है कि आपका इंस्ट्रुमेंटेशन होगा अपने घटक के ऐप पैकेज (मैनिफ़ेस्ट के बारे में नीचे अनुभाग देखें) को लक्षित करें। इस मामले में, आपके एप्लिकेशन मेकफ़ाइल की अपनी 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 की डिवाइस प्रॉपर्टी होने पर परीक्षण छोड़ दिया जाएगा।