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

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

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

नई सुविधाएं

• बेहतर क्लासपाथ सिंक्रोनाइज़ेशन: 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 फ़ाइलों में बिल्ड टूल वर्शन को मैन्युअल तरीके से सेट नहीं करना पड़ेगा