Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

सरल बिल्ड कॉन्फ़िगरेशन

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

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

कस्टम परीक्षण को समायोजित करने या 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",

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

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

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

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

android-support-test टेस्ट-सपोर्ट लाइब्रेरी के लिए android-support-test का AndroidJUnitRunner , जिसमें नया टेस्ट रनर AndroidJUnitRunner : AndroidJUnitRunner टेस्टिंग फ्रेमवर्क के समर्थन के साथ अब AndroidJUnitRunner बिल्ट-इन InstrumentationTestRunner AndroidJUnitRunner लिए एक प्रतिस्थापन। Android पर टेस्ट ऐप्स अधिक पढ़ें।

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

    certificate: "platform",

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

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

    test_min_api_level: 29

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