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

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

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

कस्टम परीक्षण को समायोजित या Android का उपयोग करने के सुसंगति परीक्षण सुइट (सीटीएस), का पालन परिसर टेस्ट विन्यास बजाय।

उदाहरण

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

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

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

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

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

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

    certificate: "platform",

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

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

    auto_gen_config: true

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

    require_root: true

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

    test_min_api_level: 29

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