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

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

	सबसे पुराना वर्शन	डिफ़ॉल्ट वर्शन	नोट
ग्रेडल	4.10.1	4.10.1	ज़्यादा जानकारी के लिए, Gradle को अपडेट करने का तरीका देखें. Gradle 5.0 और इसके बाद के वर्शन का इस्तेमाल करने पर, डिफ़ॉल्ट Gradle डीमन मेमोरी हीप का साइज़ 1 जीबी से घटकर 512 एमबी हो जाता है. इससे बिल्ड की परफ़ॉर्मेंस में गिरावट आ सकती है. इस डिफ़ॉल्ट सेटिंग को बदलने के लिए, अपने प्रोजेक्ट की gradle.properties फ़ाइल में Gradle डीमन हीप का साइज़ तय करें.
एसडीके बिल्ड टूल	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 के नए टास्क क्रिएशन एपीआई का इस्तेमाल करता है. इससे उन टास्क को शुरू और कॉन्फ़िगर करने से बचा जा सकता है जिनकी ज़रूरत, मौजूदा बिल्ड को पूरा करने के लिए नहीं होती. साथ ही, उन टास्क को भी शुरू और कॉन्फ़िगर करने से बचा जा सकता है जो एक्ज़ीक्यूशन टास्क ग्राफ़ पर नहीं होते. उदाहरण के लिए, अगर आपके पास “रिलीज़” और “डीबग” जैसे कई बिल्ड वैरिएंट हैं और “डीबग” वर्शन बनाया जा रहा है, तो प्लग इन, “रिलीज़” वर्शन के लिए टास्क को शुरू और कॉन्फ़िगर नहीं करता.

  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 ऐप्लिकेशन बंडल' बनाते समय, उस ऐप्लिकेशन बंडल से जनरेट किए गए APK में, 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 सिंक, इंटरनल तौर पर पूरे वैरिएंट का इस्तेमाल करता है.

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

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

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

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