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

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

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

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

    नीचे दिए गए कोड सैंपल में, किसी लोकल 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 कोड को डीकोड करने और शुगर को हटाने के बाद, कॉम्पाइल करने का एक अलग चरण था.

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

R8 के साथ, डेसुगरिंग, छोटा करना, गुप्त करना, ऑप्टिमाइज़ करना, और डिकोड करना, ये सभी काम एक ही कंपाइल चरण में किए जाते हैं.

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

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

      # 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 का इस्तेमाल करने पर आपको बिल्ड करने से जुड़ी गड़बड़ी का मैसेज दिखेगा. इसके बजाय, अपने प्रोजेक्ट में C और C++ कोड जोड़ने के लिए, आपको CMake या ndk-build का इस्तेमाल करना चाहिए.

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

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

              android.uniquePackageNames = true

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