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

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

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

नई सुविधाएं

• क्लासपाथ को सिंक करने की बेहतर सुविधा: 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(). यह पक्का करने के लिए कि आपका बिल्ड, लेज़ी टास्क कॉन्फ़िगरेशन के लिए ऑप्टिमाइज़ किया गया है, नए तरीके लागू करें. ये तरीके, TaskProvider ऑब्जेक्ट दिखाते हैं, जैसे कि variant.getJavaCompileProvider().

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

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

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

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

  android.bundle.enableUncompressedNativeLibs = false
          

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

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

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

  इस ऑप्टिमाइज़ेशन को मैन्युअल तरीके से चालू करने के लिए, File > Settings > Experimental > Gradle (Mac पर Android Studio > Preferences > Experimental > Gradle) पर क्लिक करें. इसके बाद, Only sync the active variant चेकबॉक्स को चुनें.

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

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

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

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

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