Android Gradle प्लग इन 3.4.0 (अप्रैल 2019)

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

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

3.4.3 (जुलाई 2020)

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

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

3.4.2 (जुलाई 2019)

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

3.4.1 (मई 2019)

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

नई सुविधाएं

  • लिंट चेक की डिपेंडेंसी के नए कॉन्फ़िगरेशन: lintChecks का व्यवहार बदल गया है. साथ ही, एक नया डिपेंडेंसी कॉन्फ़िगरेशन, lintPublish, पेश किया गया है. इससे आपको यह तय करने का ज़्यादा कंट्रोल मिलेगा कि आपकी Android लाइब्रेरी में कौनसे लिंट चेक पैकेज किए गए हैं.

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

    यहां दिए गए कोड के सैंपल में, लोकल Android लाइब्रेरी प्रोजेक्ट में दोनों डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल किया गया है.

    dependencies {
      // Executes lint checks from the ':lint' project at build time.
      lintChecks project(':lint')
      // Packages lint checks from the ':lintpublish' in the published AAR.
      lintPublish project(':lintpublish')
    }
            
    dependencies {
      // Executes lint checks from the ':lint' project at build time.
      lintChecks(project(":lint"))
      // Packages lint checks from the ':lintpublish' in the published AAR.
      lintPublish(project(":lintpublish"))
        }
            
    • आम तौर पर, पैकेजिंग और साइनिंग के टास्क में, बिल्ड की स्पीड में सुधार होना चाहिए. अगर आपको इन टास्क से जुड़ी परफ़ॉर्मेंस में कोई कमी दिखती है, तो कृपया गड़बड़ी की शिकायत करें.

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

  • Android Instant Apps के फ़ीचर प्लग इन के काम न करने के बारे में चेतावनी: अगर अब भी अपने इंस्टेंट ऐप्लिकेशन को बनाने के लिए com.android.feature प्लग इन का इस्तेमाल किया जा रहा है, तो Android Gradle प्लग इन 3.4.0 आपको इस बारे में चेतावनी देगा. यह पक्का करने के लिए कि प्लगिन के आने वाले वर्शन पर भी झटपट ऐप्लिकेशन बनाया जा सके, अपने झटपट ऐप्लिकेशन को डाइनैमिक फ़ीचर प्लगिन का इस्तेमाल करने के लिए माइग्रेट करें. इससे आपको इंस्टॉल किए गए ऐप्लिकेशन और झटपट ऐप्लिकेशन, दोनों को एक ही Android ऐप्लिकेशन बंडल से पब्लिश करने की सुविधा भी मिलती है.

  • R8 डिफ़ॉल्ट रूप से चालू होता है: R8, एक ही चरण में डिसुगरिंग, श्रिंकिंग, अस्पष्ट करना, ऑप्टिमाइज़ करना, और डेक्सिंग को इंटिग्रेट करता है. इससे बिल्ड परफ़ॉर्मेंस में काफ़ी सुधार होता है. R8 को Android Gradle प्लग इन 3.3.0 में पेश किया गया था. अब यह प्लग इन 3.4.0 और इसके बाद के वर्शन का इस्तेमाल करने वाले ऐप्लिकेशन और Android लाइब्रेरी प्रोजेक्ट, दोनों के लिए डिफ़ॉल्ट रूप से चालू होता है.

नीचे दी गई इमेज में, R8 को लॉन्च करने से पहले कंपाइल करने की प्रोसेस के बारे में खास जानकारी दी गई है.

R8 से पहले, ProGuard, dexing और desugaring से अलग कंपाइलिंग स्टेप था.

अब R8 की मदद से, डिसुगरिंग, श्रिंकिंग, अस्पष्ट करना, ऑप्टिमाइज़ करना, और डेक्सिंग (D8) जैसे सभी काम एक ही चरण में पूरे किए जा सकते हैं. इसके बारे में यहां बताया गया है.

R8 की मदद से, एक ही कंपाइल स्टेप में डिसुगरिंग, श्रिंकिंग, ऑबफ़स्केटिंग, ऑप्टिमाइज़िंग, और डेक्सिंग की जाती है.

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

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

      # Disables R8 for Android Library modules only.
      android.enableR8.libraries = false
      # Disables R8 for all modules.
      android.enableR8 = false
      
    

ध्यान दें: अगर किसी बिल्ड टाइप के लिए, आपने अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में useProguard को false पर सेट किया है, तो Android Gradle प्लग इन, उस बिल्ड टाइप के लिए आपके ऐप्लिकेशन के कोड को छोटा करने के लिए R8 का इस्तेमाल करेगा. भले ही, आपने अपने प्रोजेक्ट की gradle.properties फ़ाइल में R8 को बंद कर दिया हो.

  • ndkCompile अब काम नहीं करता: अगर अब भी ndkBuild का इस्तेमाल करके, अपनी नेटिव लाइब्रेरी को कंपाइल करने की कोशिश की जाती है, तो आपको बिल्ड से जुड़ी गड़बड़ी का मैसेज दिखेगा. इसके बजाय, आपको CMake या ndk-build का इस्तेमाल करके, अपने प्रोजेक्ट में C और C++ कोड जोड़ना चाहिए.

पहले से मालूम समस्याएं

  • फ़िलहाल, यूनीक पैकेज के नामों का सही तरीके से इस्तेमाल करने के लिए, कोई नियम लागू नहीं किया गया है. हालांकि, प्लगिन के बाद के वर्शन में यह नियम ज़्यादा सख्ती से लागू किया जाएगा. Android Gradle प्लगइन 3.4.0 वर्शन पर, यह देखने के लिए ऑप्ट-इन किया जा सकता है कि आपका प्रोजेक्ट, स्वीकार किए जा सकने वाले पैकेज के नाम तय करता है या नहीं. इसके लिए, अपनी gradle.properties फ़ाइल में यहां दी गई लाइन जोड़ें.

              android.uniquePackageNames = true
              
            

    Android Gradle प्लगिन के ज़रिए पैकेज का नाम सेट करने के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन आईडी सेट करना लेख पढ़ें.