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

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

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

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

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

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

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

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

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

नई सुविधाएं

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

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

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

  Groovy

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

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

  Groovy

          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 के लिए सहायता.

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

  Groovy

          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 कॉन्फ़िगरेशन का इस्तेमाल करके, आपके lint प्रोजेक्ट पर निर्भर हो सकते हैं:

  Groovy

          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() ऑब्जेक्ट को ऐक्सेस करने के लिए, वैरिएंट एपीआई का इस्तेमाल नहीं किया जा सकता. इसके अलावा, हर वैरिएंट के लिए मेनिफ़ेस्ट फ़ाइल पाने के लिए, processManifest.manifestOutputFile() का इस्तेमाल भी नहीं किया जा सकता. ज़्यादा जानने के लिए, पढ़ें एपीआई में हुए बदलाव.
• अब आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. इसलिए, अब आपके पास android.buildToolsVersion प्रॉपर्टी को हटाने का विकल्प है. डिफ़ॉल्ट रूप से, प्लग इन आपके इस्तेमाल किए जा रहे Android प्लग इन के वर्शन के लिए, कम से कम ज़रूरी बिल्ड टूल के वर्शन का इस्तेमाल अपने-आप करता है.
• अब buildTypes ब्लॉक में, PNG क्रंचिंग की सुविधा को चालू/बंद किया जा सकता है. इसके लिए, नीचे दिया गया तरीका अपनाएं. डीबग बिल्ड को छोड़कर, सभी बिल्ड के लिए PNG क्रंचिंग डिफ़ॉल्ट रूप से चालू होती है. ऐसा इसलिए होता है, क्योंकि जिन प्रोजेक्ट में कई PNG फ़ाइलें शामिल होती हैं उनके लिए बिल्ड करने में ज़्यादा समय लगता है. इसलिए, दूसरे टाइप के बिल्ड के लिए बिल्ड होने में लगने वाले समय को कम करने के लिए, आपको PNG क्रंचिंग की सुविधा बंद करनी चाहिए या अपनी इमेज को WebP में बदलना चाहिए.

  Groovy

        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 से माइग्रेट करना लेख पढ़ें.