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

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

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

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

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

उदाहरण

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

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

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

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

समायोजन

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

    name: "HelloWorldTests",

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

    static_libs: ["android-support-test"],

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

इस उदाहरण में, वे चीज़ें जो आमतौर पर परीक्षणों के लिए उपयोगी हो सकती हैं:

android-support-test एंड्रॉइड टेस्ट सपोर्ट लाइब्रेरी के लिए प्रीबिल्ट है, जिसमें नया टेस्ट रनर शामिल है AndroidJUnitRunner : JUnit4 टेस्टिंग फ्रेमवर्क के समर्थन के साथ अब बहिष्कृत बिल्ट-इन InstrumentationTestRunner के लिए एक प्रतिस्थापन। Android पर टेस्ट ऐप्स पर और पढ़ें।

यदि आप एक नया इंस्ट्रूमेंटेशन मॉड्यूल बना रहे हैं, तो आपको हमेशा अपने टेस्ट रनर के रूप में android-support-test लाइब्रेरी से शुरुआत करनी चाहिए। प्लेटफ़ॉर्म सोर्स ट्री में अन्य उपयोगी परीक्षण ढाँचे भी शामिल हैं जैसे 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 की डिवाइस संपत्ति होने पर परीक्षण छोड़ दिया जाएगा।