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

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

सबसे पुराना वर्शन डिफ़ॉल्ट वर्शन नोट
ग्रेडल 5.1.1 5.1.1 ज़्यादा जानकारी के लिए, Gradle को अपडेट करने का तरीका देखें. Gradle 5.0 और इसके बाद के वर्शन का इस्तेमाल करने पर, डिफ़ॉल्ट Gradle डीमन मेमोरी हीप का साइज़ 1 जीबी से घटकर 512 एमबी हो जाता है. इसकी वजह से, बिल्ड की परफ़ॉर्मेंस में गिरावट आ सकती है. इस डिफ़ॉल्ट सेटिंग को बदलने के लिए, अपने प्रोजेक्ट की gradle.properties फ़ाइल में Gradle डीमन हीप का साइज़ तय करें.
SDK Build Tools 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 को कंपाइल करने का तरीका, डेक्सिंग और डिशुगरिंग से अलग था.

अब 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 प्लग-इन की मदद से पैकेज का नाम सेट करने के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन आईडी सेट करना लेख पढ़ें.