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

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

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

3.3.3 (जुलाई 2020)

इस छोटे से अपडेट में, Android 11 में पैकेज की जानकारी देखने की सुविधा के लिए, नई डिफ़ॉल्ट सेटिंग और सुविधाओं के साथ काम करने की सुविधा जोड़ी गई है.

ज़्यादा जानकारी के लिए, 4.0.1 के रिलीज़ नोट देखें.

3.3.2 (मार्च 2019)

इस छोटे अपडेट में, Android Studio 3.3.2 के साथ काम करने की सुविधा है. साथ ही, इसमें कई गड़बड़ियां ठीक की गई हैं और परफ़ॉर्मेंस में सुधार किया गया है. गड़बड़ियों को ठीक करने से जुड़ी अहम जानकारी देखने के लिए, रिलीज़ अपडेट ब्लॉग पर इससे जुड़ी पोस्ट पढ़ें.

3.3.1 (फ़रवरी 2019)

इस छोटे अपडेट में Android Studio 3.3.1 के लिए सहायता उपलब्ध है. साथ ही, इसमें कई गड़बड़ियां ठीक की गई हैं और परफ़ॉर्मेंस में सुधार किया गया है.

नई सुविधाएं

• बेहतर क्लासपाथ सिंक्रनाइज़ेशन: रनटाइम और कंपाइल टाइम क्लासपाथ पर डिपेंडेंसी हल करते समय, 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 issue 8194 की वजह से, यह Gradle 5.1 के साथ काम नहीं करती.

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

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

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

    android.enableSeparateAnnotationProcessing=true
                

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

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

            android.debug.obsoleteApi=true
          

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

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

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

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

  Variants API में कुछ पुराने तरीकों को कॉल करने पर, टास्क कॉन्फ़िगरेशन अब भी लागू हो सकता है. जैसे, 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 ऐप्लिकेशन बंडल बनाते समय, Android 6.0 (एपीआई लेवल 23) या उसके बाद के वर्शन को टारगेट करने वाले उस ऐप्लिकेशन बंडल से जनरेट किए गए APK में, अब डिफ़ॉल्ट रूप से आपकी नेटिव लाइब्रेरी के बिना कंप्रेस किए गए वर्शन शामिल होते हैं. इस ऑप्टिमाइज़ेशन से, डिवाइस को लाइब्रेरी की कॉपी बनाने की ज़रूरत नहीं पड़ती. इसलिए, आपके ऐप्लिकेशन का ऑन-डिस्क साइज़ कम हो जाता है. अगर आपको इस ऑप्टिमाइज़ेशन को बंद करना है, तो अपनी gradle.properties फ़ाइल में यह जोड़ें:

  android.bundle.enableUncompressedNativeLibs = false
          

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

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

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

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

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

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

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

• Android Gradle प्लग इन 3.3.0 में, इन समस्याओं को ठीक किया गया है:

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