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

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

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

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

कस्टम टेस्टिंग करने या Android Compatibility Test Suite (CTS) का इस्तेमाल करने के लिए, Complex Test Configuration का पालन करें.

उदाहरण

यहां दी गई एंट्री, ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल के इस उदाहरण से ली गई हैं: /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 सेटिंग, मौजूदा मॉड्यूल के APK में नाम वाले मॉड्यूल के कॉन्टेंट को शामिल करने के लिए, बिल्ड सिस्टम को निर्देश देती है. इसका मतलब है कि नाम वाले हर मॉड्यूल से एक .jar फ़ाइल बनेगी. साथ ही, इसके कॉन्टेंट का इस्तेमाल, कॉम्पाइल के समय क्लासपथ रेफ़रंस को हल करने के लिए किया जाएगा. साथ ही, इसे APK में शामिल किया जाएगा.

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

अगर कोई नया इंस्ट्रूमेंटेशन मॉड्यूल बनाया जा रहा है, तो आपको हमेशा अपने टेस्ट रनर के तौर पर androidx.test.runner लाइब्रेरी से शुरू करना चाहिए. प्लैटफ़ॉर्म सोर्स ट्री में, ub-uiautomator, mockito-target, easymock वगैरह जैसे अन्य काम के टेस्टिंग फ़्रेमवर्क भी शामिल होते हैं.

    certificate: "platform",

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

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

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

    test_suites: ["device-tests"],

test_suites सेटिंग की मदद से, Trade Federation टेस्ट हार्नेस को टेस्ट आसानी से मिल जाता है. यहां अन्य सुइट भी जोड़े जा सकते हैं, जैसे कि सीटीएस, ताकि इस जांच को शेयर किया जा सके.

${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 सेटिंग से पता चलता है कि टेस्ट कॉन्फ़िगरेशन अपने-आप बनेगा या नहीं. अगर Android.bp के बगल में AndroidTest.xml मौजूद नहीं है, तो इस एट्रिब्यूट को साफ़ तौर पर'सही है' पर सेट करने की ज़रूरत नहीं है.

    require_root: true

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

    test_min_api_level: 29

test_min_api_level सेटिंग, बिल्ड सिस्टम को अपने-आप जनरेट हुए टेस्ट कॉन्फ़िगरेशन में, MinApiLevelModuleController जोड़ने का निर्देश देती है. जब Trade Federation, टेस्ट कॉन्फ़िगरेशन चलाता है, तो अगर ro.product.first_api_level की डिवाइस प्रॉपर्टी < test_min_api_level है, तो टेस्ट को छोड़ दिया जाएगा.