Android Gradle प्लग इन 3.3.0 (जनवरी 2019)

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

	कम से कम वर्शन	डिफ़ॉल्ट वर्शन	नोट
Gradle	4.10.1	4.10.1	ज़्यादा जानने के लिए, Gradle को अपडेट करना लेख पढ़ें. Gradle 5.0 और उसके बाद के वर्शन का इस्तेमाल करने पर, Gradle डेमन मेमोरी हेप का डिफ़ॉल्ट साइज़ 1 जीबी से घटकर 512 एमबी हो जाता है. इससे, बिल्ड की परफ़ॉर्मेंस में गिरावट आ सकती है. इस डिफ़ॉल्ट सेटिंग को बदलने के लिए, अपने प्रोजेक्ट की gradle.properties फ़ाइल में Gradle डेमन हेप का साइज़ तय करें.
SDK टूल के लिए बिल्ड टूल	28.0.3	28.0.3	SDK Build Tools को इंस्टॉल या कॉन्फ़िगर करें.

नई सुविधाएं

• बेहतर क्लासपाथ सिंक्रोनाइज़ेशन: रनटाइम और कॉम्पाइल टाइम क्लासपाथ पर डिपेंडेंसी को हल करते समय, Android Gradle प्लग इन, एक से ज़्यादा क्लासपाथ में दिखने वाली डिपेंडेंसी के लिए, डाउनस्ट्रीम वर्शन के कुछ विरोधों को ठीक करने की कोशिश करता है.

  उदाहरण के लिए, अगर रनटाइम क्लासपाथ में लाइब्रेरी A का वर्शन 2.0 और संकलन क्लासपाथ में लाइब्रेरी A का वर्शन 1.0 शामिल है, तो गड़बड़ियों से बचने के लिए, प्लग इन अपने-आप संकलन क्लासपाथ पर लाइब्रेरी A के वर्शन 2.0 पर डिपेंडेंसी को अपडेट कर देता है.

  हालांकि, अगर रनटाइम क्लासपाथ में लाइब्रेरी A का वर्शन 1.0 शामिल है और संकलन में लाइब्रेरी A का वर्शन 2.0 शामिल है, तो प्लग इन, संकलन क्लासपाथ पर लाइब्रेरी A के वर्शन 1.0 पर डिपेंडेंसी को डाउनग्रेड नहीं करता. साथ ही, आपको गड़बड़ी का मैसेज दिखेगा. ज़्यादा जानने के लिए, क्लासपथ के बीच के संघर्षों को ठीक करना लेख पढ़ें.

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

  ध्यान दें: यह सुविधा Gradle 4.10.1 और इसके बाद के वर्शन के साथ काम करती है. हालांकि, Gradle के 8194 से जुड़ी समस्या की वजह से, यह सुविधा Gradle 5.1 के साथ काम नहीं करती.

  • Kapt का इस्तेमाल करने वाले प्रोजेक्ट के लिए (सिर्फ़ Kotlin वाले ज़्यादातर प्रोजेक्ट और Kotlin-Java हाइब्रिड प्रोजेक्ट): डेटा बाइंडिंग या रिट्रो-लैम्ब्डा प्लग इन का इस्तेमाल करने पर भी, Java का इंक्रीमेंटल कंपाइलेशन चालू होता है. Kapt टास्क की मदद से एनोटेशन प्रोसेस करने की सुविधा अभी तक इंक्रीमेंटल नहीं है.

  • Kapt का इस्तेमाल न करने वाले प्रोजेक्ट (सिर्फ़ Java प्रोजेक्ट) के लिए: अगर इस्तेमाल किए जा रहे सभी एनोटेशन प्रोसेसर, इंक्रीमेंटल एनोटेशन प्रोसेसिंग के साथ काम करते हैं, तो इंक्रीमेंटल Java कंपाइलेशन डिफ़ॉल्ट रूप से चालू होता है. एनोटेशन प्रोसेसर के इस्तेमाल में बढ़ोतरी पर नज़र रखने के लिए, Gradle की समस्या 5277 देखें.

    हालांकि, अगर एक या एक से ज़्यादा एनोटेशन प्रोसेसर, इंक्रीमेंटल बिल्ड के साथ काम नहीं करते, तो इंक्रीमेंटल Java कंपाइलेशन की सुविधा चालू नहीं होती. इसके बजाय, अपनी gradle.properties फ़ाइल में यह फ़्लैग शामिल किया जा सकता है:

    android.enableSeparateAnnotationProcessing=true
                

    इस फ़्लैग को शामिल करने पर, Android Gradle प्लग इन एनोटेशन प्रोसेसर को एक अलग टास्क में चलाता है. साथ ही, Java कंपाइलेशन टास्क को धीरे-धीरे चलाने की अनुमति देता है.

• पुराने एपीआई का इस्तेमाल करते समय, डीबग करने से जुड़ी बेहतर जानकारी: जब प्लग इन को पता चलता है कि आपने ऐसे एपीआई का इस्तेमाल किया है जो अब काम नहीं करता, तो वह अब ज़्यादा जानकारी दे सकता है. इससे आपको यह पता लगाने में मदद मिलती है कि उस एपीआई का इस्तेमाल कहां किया जा रहा है. ज़्यादा जानकारी देखने के लिए, आपको अपने प्रोजेक्ट की gradle.properties फ़ाइल में ये शामिल करने होंगे:

            android.debug.obsoleteApi=true
          

  कमांड लाइन से -Pandroid.debug.obsoleteApi=true डालकर भी फ़्लैग को चालू किया जा सकता है.

• कमांड लाइन से, फ़ीचर मॉड्यूल पर इंस्ट्रुमेंटेशन टेस्ट चलाए जा सकते हैं.

उपयोगकर्ता के व्यवहार में बदलाव

• टास्क को धीरे-धीरे कॉन्फ़िगर करना: अब प्लग इन, Gradle के टास्क बनाने वाले नए एपीआई का इस्तेमाल करता है. इससे, उन टास्क को शुरू और कॉन्फ़िगर करने से बचा जा सकता है जो मौजूदा बिल्ड को पूरा करने के लिए ज़रूरी नहीं हैं या जो टास्क, टास्क के ग्राफ़ में नहीं हैं. उदाहरण के लिए, अगर आपके पास “रिलीज़” और “डीबग” जैसे कई बिल्ड वैरिएंट हैं और आप अपने ऐप्लिकेशन का “डीबग” वर्शन बना रहे हैं, तो प्लग इन आपके ऐप्लिकेशन के “रिलीज़” वर्शन के लिए, टास्क को शुरू और कॉन्फ़िगर करने से बचता है.

  वैरिएंट एपीआई में कुछ पुराने तरीकों को कॉल करने पर, जैसे कि variant.getJavaCompile(), हो सकता है कि टास्क कॉन्फ़िगरेशन को फिर से लागू करना पड़े. यह पक्का करने के लिए कि आपका बिल्ड, टास्क के लेज़ी कॉन्फ़िगरेशन के लिए ऑप्टिमाइज़ किया गया है, ऐसे नए तरीके लागू करें जो variant.getJavaCompileProvider() जैसे TaskProvider ऑब्जेक्ट दिखाते हों.

  अगर कस्टम बिल्ड टास्क चलाए जाते हैं, तो Gradle के नए टास्क बनाने वाले एपीआई के साथ काम करने का तरीका जानें.

• किसी खास बिल्ड टाइप के लिए, useProguard false सेट करते समय, प्लग इन अब आपके ऐप्लिकेशन के कोड और संसाधनों को छोटा करने और उन्हें अस्पष्ट करने के लिए, ProGuard के बजाय R8 का इस्तेमाल करता है. R8 के बारे में ज़्यादा जानने के लिए, Android डेवलपर ब्लॉग पर मौजूद यह ब्लॉग पोस्ट पढ़ें.

• लाइब्रेरी प्रोजेक्ट के लिए R क्लास तेज़ी से जनरेट करना: पहले, Android Gradle प्लग इन आपके हर प्रोजेक्ट की डिपेंडेंसी के लिए एक R.java फ़ाइल जनरेट करता था. इसके बाद, उन R क्लास को आपके ऐप्लिकेशन की अन्य क्लास के साथ कंपाइल करता था. अब प्लग इन, आपके ऐप्लिकेशन की कंपाइल की गई R क्लास वाला एक JAR जनरेट करता है. इसमें, इंटरमीडिएट R.java क्लास को पहले बनाने की ज़रूरत नहीं होती. इस ऑप्टिमाइज़ेशन से, उन प्रोजेक्ट के लिए बिल्ड की परफ़ॉर्मेंस काफ़ी बेहतर हो सकती है जिनमें कई लाइब्रेरी सब-प्रोजेक्ट और डिपेंडेंसी शामिल हैं. साथ ही, Android Studio में इंडेक्स करने की स्पीड भी बेहतर हो सकती है.

• Android ऐप्लिकेशन बंडल बनाते समय, Android 6.0 (एपीआई लेवल 23) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन बंडल से जनरेट किए गए APK में, अब डिफ़ॉल्ट रूप से आपकी नेटिव लाइब्रेरी के बिना कंप्रेस किए गए वर्शन शामिल होते हैं. इस ऑप्टिमाइज़ेशन की मदद से, डिवाइस को लाइब्रेरी की कॉपी बनाने की ज़रूरत नहीं पड़ती. इससे, आपके ऐप्लिकेशन का डिस्क साइज़ कम हो जाता है. अगर आपको यह ऑप्टिमाइज़ेशन बंद करना है, तो अपनी gradle.properties फ़ाइल में ये चीज़ें जोड़ें:

  android.bundle.enableUncompressedNativeLibs = false
          

• यह प्लग इन, तीसरे पक्ष के कुछ प्लग इन के कम से कम वर्शन लागू करता है.

• सिंगल-वैरिएंट प्रोजेक्ट सिंक करना: अपने प्रोजेक्ट को अपने बिल्ड कॉन्फ़िगरेशन के साथ सिंक करना, Android Studio को यह समझने में मदद करने के लिए एक अहम चरण है कि आपके प्रोजेक्ट का स्ट्रक्चर कैसा है. हालांकि, बड़े प्रोजेक्ट के लिए, इस प्रोसेस में समय लग सकता है. अगर आपके प्रोजेक्ट में एक से ज़्यादा बिल्ड वैरिएंट का इस्तेमाल किया जाता है, तो अब प्रोजेक्ट सिंक को ऑप्टिमाइज़ किया जा सकता है. इसके लिए, सिंक को सिर्फ़ उस वैरिएंट तक सीमित करें जिसे आपने फ़िलहाल चुना है.

  इस ऑप्टिमाइज़ेशन को चालू करने के लिए, आपको Android Studio 3.3 या इसके बाद के वर्शन के साथ Android Gradle प्लग इन 3.3.0 या इसके बाद के वर्शन का इस्तेमाल करना होगा. इन ज़रूरी शर्तों को पूरा करने पर, प्रोजेक्ट सिंक करते समय IDE आपको इस ऑप्टिमाइज़ेशन को चालू करने के लिए कहता है. ऑप्टिमाइज़ेशन की सुविधा, नए प्रोजेक्ट में भी डिफ़ॉल्ट रूप से चालू होती है.

  इस ऑप्टिमाइज़ेशन को मैन्युअल तरीके से चालू करने के लिए, फ़ाइल > सेटिंग > एक्सपेरिमेंटल > Gradle (Mac पर Android Studio > प्राथमिकताएं > एक्सपेरिमेंटल > Gradle) पर क्लिक करें और सिर्फ़ चालू वैरिएंट सिंक करें चेकबॉक्स को चुनें.

  ध्यान दें: यह ऑप्टिमाइज़ेशन, उन प्रोजेक्ट के साथ पूरी तरह काम करता है जिनमें Java और C++ भाषाएं शामिल होती हैं. साथ ही, यह Kotlin के साथ भी कुछ हद तक काम करता है. Kotlin कॉन्टेंट वाले प्रोजेक्ट के लिए ऑप्टिमाइज़ेशन चालू करने पर, Gradle सिंक फिर से अंदरूनी तौर पर पूरे वैरिएंट का इस्तेमाल करने लगता है.

• SDK टूल के मौजूद न होने पर, उन्हें अपने-आप डाउनलोड होने की सुविधा: इस सुविधा को NDK के साथ काम करने के लिए बेहतर बनाया गया है. ज़्यादा जानने के लिए, पढ़ें Gradle की मदद से, मौजूद न होने वाले पैकेज अपने-आप डाउनलोड होने की सुविधा.

गड़बड़ियां ठीक की गईं

• Android Gradle प्लग इन 3.3.0 में ये समस्याएं ठीक की गई हैं:

  • Jetifier चालू होने के बावजूद, बिल्ड प्रोसेस में AndroidX वर्शन के बजाय android.support.v8.renderscript.RenderScript को कॉल किया जा रहा है
  • स्टैटिक तौर पर बंडल किए गए annotation.AnyRes के साथ androidx-rs.jar की वजह से होने वाली गड़बड़ियां
  • RenderScript का इस्तेमाल करते समय, अब आपको अपनी build.gradle फ़ाइलों में, Build Tools का वर्शन मैन्युअल तरीके से सेट करने की ज़रूरत नहीं है