Android Gradle प्लगिन 3.0.0 (अक्टूबर 2017)

Android Gradle प्लगिन 3.0.0 में कई बदलाव किए गए हैं. इनका मकसद, बड़े प्रोजेक्ट की परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करना है.

उदाहरण के लिए, ~130 मॉड्यूल और बड़ी संख्या में बाहरी डिपेंडेंसी वाले सैंपल स्केलेटन प्रोजेक्ट (जिसमें कोई कोड या संसाधन नहीं है) पर, आपको परफ़ॉर्मेंस में ये सुधार दिख सकते हैं:

इनमें से कुछ बदलावों की वजह से, मौजूदा बिल्ड टूट जाते हैं. इसलिए, नए प्लगिन का इस्तेमाल करने से पहले, आपको अपने प्रोजेक्ट को माइग्रेट करने के
लिए लगने वाली मेहनत के बारे में सोचना चाहिए.

अगर आपको ऊपर बताए गए परफ़ॉर्मेंस में सुधार नहीं दिखते हैं, कृपया गड़बड़ी की शिकायत करें साथ ही, Gradle Profiler का इस्तेमाल करके, अपने बिल्ड का ट्रेस शामिल करें.

Android प्लगिन के इस वर्शन के लिए, ये ज़रूरी शर्तें हैं:

	सबसे पुराना वर्शन	डिफ़ॉल्ट वर्शन	नोट
ग्रेडल	4.1	4.1	ज़्यादा जानकारी के लिए, Gradle को अपडेट करने का तरीका देखें.
एसडीके बिल्ड टूल	26.0.2	26.0.2	इंस्टॉल करें या कॉन्फ़िगर करें एसडीके बिल्ड टूल. इस अपडेट के बाद, आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. प्लगिन, डिफ़ॉल्ट रूप से ज़रूरी सबसे पुराने वर्शन का इस्तेमाल करता है. इसलिए, अब android.buildToolsVersion प्रॉपर्टी को हटाया जा सकता है.

ऑप्टिमाइज़ेशन

• मल्टी-मॉड्यूल प्रोजेक्ट के लिए, बेहतर पैरललिज़म. इसके लिए, टास्क ग्राफ़ का इस्तेमाल किया जाता है.
• डिपेंडेंसी में बदलाव करने पर, Gradle तेज़ी से बिल्ड करता है. ऐसा इसलिए, क्योंकि यह उन मॉड्यूल को फिर से कंपाइल नहीं करता जिनके पास उस डिपेंडेंसी के एपीआई का ऐक्सेस नहीं होता. आपको Gradle के नए डिपेंडेंसी कॉन्फ़िगरेशन: implementation, api, compileOnly, और runtimeOnly का इस्तेमाल करके, यह तय करना चाहिए कि किन डिपेंडेंसी के एपीआई, दूसरे मॉड्यूल के साथ शेयर किए जा सकते हैं.
• क्लास के हिसाब से डेक्सिंग की वजह से, इंक्रीमेंटल बिल्ड की स्पीड बेहतर हुई है. अब हर क्लास को अलग-अलग DEX फ़ाइलों में कंपाइल किया जाता है. साथ ही, सिर्फ़ उन क्लास को फिर से डेक्स किया जाता है जिनमें बदलाव किया गया है. आपको उन ऐप्लिकेशन के लिए भी बिल्ड की स्पीड बेहतर होने की उम्मीद करनी चाहिए जिनमें minSdkVersion को 20 या उससे कम पर सेट किया गया है. साथ ही, जिनमें लेगसी मल्टी-डेक्स का इस्तेमाल किया गया है.
• कैश किए गए आउटपुट का इस्तेमाल करने के लिए, कुछ टास्क को ऑप्टिमाइज़ करके बिल्ड की स्पीड बेहतर की गई है. इस ऑप्टिमाइज़ेशन का फ़ायदा पाने के लिए, आपको सबसे पहले Gradle बिल्ड कैश चालू करना होगा.
• AAPT2 का इस्तेमाल करके, इंक्रीमेंटल रिसॉर्स प्रोसेसिंग को बेहतर किया गया है. यह अब डिफ़ॉल्ट रूप से चालू है. अगर आपको AAPT2 का इस्तेमाल करते समय समस्याएं आ रही हैं, कृपया गड़बड़ी की शिकायत करें. आपके पास AAPT2 को बंद करने का विकल्प भी है. इसके लिए, अपनी gradle.properties फ़ाइल में android.enableAapt2=false सेट करें. इसके बाद, कमांड लाइन से ./gradlew --stop चलाकर, Gradle डेमॉन को रीस्टार्ट करें.

नई सुविधाएं

• वैरिएंट के हिसाब से डिपेंडेंसी मैनेज करना. किसी मॉड्यूल के किसी वैरिएंट को बिल्ड करते समय, प्लगिन अब स्थानीय लाइब्रेरी मॉड्यूल डिपेंडेंसी के वैरिएंट को, आपके बिल्ड किए जा रहे मॉड्यूल के वैरिएंट से अपने-आप मैच करता है.
• इसमें, Android Instant Apps और Android Instant Apps SDK (जिसे एसडीके मैनेजर का इस्तेमाल करके डाउनलोड किया जा सकता है) के लिए, एक नया फ़ीचर मॉड्यूल प्लगिन शामिल है. नए प्लगिन की मदद से, फ़ीचर मॉड्यूल बनाने के बारे में ज़्यादा जानने के लिए, एक से ज़्यादा फ़ीचर वाले झटपट ऐप्लिकेशन का स्ट्रक्चर पढ़ें.
• Java 8 की कुछ भाषा सुविधाओं और Java 8 लाइब्रेरी का इस्तेमाल करने के लिए, पहले से मौजूद सहायता. Jack अब बंद हो गया है और इसकी ज़रूरत नहीं है. साथ ही, डिफ़ॉल्ट टूलचेन में शामिल, बेहतर Java 8 सहायता का इस्तेमाल करने के लिए, आपको सबसे पहले Jack को बंद करना होगा. ज़्यादा जानकारी के लिए, Java 8 की भाषा सुविधाओं का इस्तेमाल करना लेख पढ़ें.

• Android Test Orchestrator की मदद से टेस्ट चलाने की सुविधा जोड़ी गई है. इससे, आपके ऐप्लिकेशन के हर टेस्ट को, इंस्ट्रुमेंटेशन के अपने-अपने इनवोकेशन में चलाया जा सकता है. हर टेस्ट, इंस्ट्रुमेंटेशन के अपने-अपने इंस्टेंस में चलता है. इसलिए, टेस्ट के बीच शेयर की गई कोई भी स्थिति, आपके डिवाइस के सीपीयू या मेमोरी पर इकट्ठा नहीं होती. साथ ही, अगर कोई टेस्ट क्रैश हो जाता है, तो वह सिर्फ़ इंस्ट्रुमेंटेशन के अपने इंस्टेंस को बंद करता है. इसलिए, आपके अन्य टेस्ट अब भी चलते रहते हैं.

  • डिवाइस पर टेस्ट ऑर्केस्ट्रेशन का इस्तेमाल करना है या नहीं, यह तय करने के लिए testOptions.execution जोड़ा गया है. अगर आपको use Android Test Orchestrator का इस्तेमाल करना है, तो आपको ANDROID_TEST_ORCHESTRATOR तय करना होगा. जैसा कि नीचे दिखाया गया है. डिफ़ॉल्ट रूप से, इस प्रॉपर्टी को HOST पर सेट किया जाता है. इससे डिवाइस पर ऑर्केस्ट्रेशन बंद हो जाता है. साथ ही, यह टेस्ट चलाने का स्टैंडर्ड तरीका है.

  शानदार

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

• नई androidTestUtil डिपेंडेंसी कॉन्फ़िगरेशन की सुविधा से, इंस्ट्रुमेंटेशन टेस्ट चलाने से पहले, टेस्ट हेल्पर का कोई दूसरा APK इंस्टॉल किया जा सकता है. जैसे, Android Test Orchestrator:

  शानदार

          dependencies {
            androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
            ...
          }
          

  Kotlin

          dependencies {
            androidTestUtil("com.android.support.test:orchestrator:1.0.0")
            ...
          }
          

• testOptions.unitTests.includeAndroidResources जोड़ा गया है. इससे, यूनिट टेस्ट के लिए सहायता मिलती है. इन टेस्ट के लिए, Android के संसाधनों की ज़रूरत होती है. जैसे, Roboelectric. जब इस प्रॉपर्टी को true पर सेट किया जाता है, तो प्लगिन, यूनिट टेस्ट चलाने से पहले, संसाधन, ऐसेट, और मेनिफ़ेस्ट को मर्ज करता है. इसके बाद, आपके टेस्ट, क्लासपाथ पर मौजूद com/android/tools/test_config.properties में, इन कुंजियों की जांच कर सकते हैं:

  • android_merged_assets: मर्ज किए गए ऐसेट डायरेक्ट्री का पूरा पाथ.

    ध्यान दें: लाइब्रेरी मॉड्यूल के लिए, मर्ज किए गए ऐसेट में डिपेंडेंसी के ऐसेट शामिल नहीं होते (समस्या #65550419 देखें).

  • android_merged_manifest: मर्ज की गई मेनिफ़ेस्ट फ़ाइल का पूरा पाथ.

  • android_merged_resources: मर्ज किए गए संसाधन डायरेक्ट्री का पूरा पाथ. इसमें मॉड्यूल और उसकी सभी डिपेंडेंसी के सभी संसाधन शामिल होते हैं.

  • android_custom_package: फ़ाइनल R क्लास का पैकेज नाम. अगर ऐप्लिकेशन आईडी में डाइनैमिक तरीके से बदलाव किया जाता है, तो हो सकता है कि यह पैकेज नाम, ऐप्लिकेशन के मेनिफ़ेस्ट में मौजूद package एट्रिब्यूट से मैच न करे.

• फ़ॉन्ट को संसाधनों के तौर पर इस्तेमाल करने की सुविधा. यह Android 8.0 (एपीआई लेवल 26) में जोड़ी गई नई सुविधा है.
• Android Instant Apps SDK 1.1 और इसके बाद के वर्शन के साथ, भाषा के हिसाब से APK के लिए सहायता.

• अब अपने बाहरी नेटिव बिल्ड प्रोजेक्ट के लिए, आउटपुट डायरेक्ट्री बदली जा सकती है. जैसा कि नीचे दिखाया गया है:

  शानदार

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory "./outputs/cmake"
                  }
              }
          }
          

  Kotlin

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory = "./outputs/cmake"
                  }
              }
          }
          

• Android Studio से नेटिव प्रोजेक्ट बनाते समय, अब CMake 3.7 या इसके बाद के वर्शन का इस्तेमाल किया जा सकता है.

• नई lintChecks डिपेंडेंसी कॉन्फ़िगरेशन की सुविधा से, ऐसा JAR बनाया जा सकता है जिसमें कस्टम लिंट नियम तय किए गए हों. साथ ही, इसे अपने AAR और APK प्रोजेक्ट में पैकेज किया जा सकता है.

  आपके कस्टम लिंट नियम, किसी अलग प्रोजेक्ट के होने चाहिए. इस प्रोजेक्ट से, सिर्फ़ एक JAR आउटपुट होना चाहिए. साथ ही, इसमें सिर्फ़ compileOnlyडिपेंडेंसी शामिल होनी चाहिए. इसके बाद, अन्य ऐप्लिकेशन और लाइब्रेरी मॉड्यूल, lintChecks कॉन्फ़िगरेशन का इस्तेमाल करके, आपके लिंट प्रोजेक्ट पर निर्भर हो सकते हैं:

  शानदार

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks project(':lint-checks')
          }
          

  Kotlin

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks(project(":lint-checks"))
          }
          

व्यवहार में हुए बदलाव

• Android प्लगिन 3.0.0 में, कुछ एपीआई हटा दिए गए हैं. अगर उनका इस्तेमाल किया जाता है, तो आपका बिल्ड टूट जाएगा . उदाहरण के लिए, अब वैरिएंट के हिसाब से outputFile() ऑब्जेक्ट ऐक्सेस करने के लिए, Variants API का इस्तेमाल नहीं किया जा सकता. साथ ही, हर वैरिएंट के लिए मेनिफ़ेस्ट फ़ाइल पाने के लिए, processManifest.manifestOutputFile() का इस्तेमाल नहीं किया जा सकता. ज़्यादा जानने के लिए, एपीआई में हुए बदलाव लेख पढ़ें.
• अब आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. इसलिए, अब प्रॉपर्टी को हटाया जा सकता है.android.buildToolsVersion डिफ़ॉल्ट रूप से, प्लगिन, Android प्लगिन के उस वर्शन के लिए, ज़रूरी सबसे पुराने बिल्ड टूल वर्शन का इस्तेमाल अपने-आप करता है जिसका इस्तेमाल किया जा रहा है.
• अब buildTypes ब्लॉक में, पीएनजी क्रंचिंग को चालू/बंद किया जा सकता है. जैसा कि नीचे दिखाया गया है. डीबग बिल्ड को छोड़कर, सभी बिल्ड के लिए पीएनजी क्रंचिंग डिफ़ॉल्ट रूप से चालू होती है ऐसा इसलिए, क्योंकि इससे उन प्रोजेक्ट के लिए बिल्ड में लगने वाला समय बढ़ जाता है जिनमें कई पीएनजी फ़ाइलें शामिल होती हैं. इसलिए, अन्य बिल्ड टाइप के लिए बिल्ड में लगने वाला समय बेहतर करने के लिए, आपको पीएनजी क्रंचिंग को बंद करना चाहिए या अपनी इमेज को WebP में बदलना चाहिए.

  शानदार

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              crunchPngs false
            }
          }
        }
        

  Kotlin

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              isCrunchPngs = false
            }
          }
        }
        

• Android प्लगिन अब उन एक्ज़ीक्यूटेबल टारगेट को अपने-आप बिल्ड करता है जिन्हें आपने अपने बाहरी CMake प्रोजेक्ट में कॉन्फ़िगर किया है.
• अब आपको एनोटेशन प्रोसेसर को प्रोसेसर क्लासपाथ में जोड़ने के लिए annotationProcessor डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल करना होगा.
• अब बंद हो चुके ndkCompile का इस्तेमाल करने पर ज़्यादा पाबंदियां हैं. इसके बजाय, आपको CMake या ndk-build का इस्तेमाल करके, नेटिव कोड को कंपाइल करने के लिए माइग्रेट करना चाहिए. इस कोड को अपने APK में पैकेज किया जा सकता है. ज़्यादा जानने के लिए, ndkcompile से माइग्रेट करना लेख पढ़ें.