Android Gradle प्लग इन 4.1.0 (अगस्त 2020)

इनके साथ काम करता है

<p>This version of the Android plugin requires the following:</p>
<ul>
  <li>
    <p><a href="https://docs.gradle.org/6.5.1/release-notes.html">Gradle 6.5</a>.
    To learn more, read the section about <a href="#updating-gradle">updating
    Gradle</a>.</p>
  </li>
  <li>
    <p><a href="/studio/releases/build-tools.html#notes">SDK Build Tools
    29.0.2</a> or higher.</p>
  </li>
</ul>
<p>The default NDK version in this release is 21.1.6352462. To install a
different NDK version, see <a href="/studio/projects/install-ndk#specific-version">Install a specific version of the NDK</a>.</p>

नई सुविधाएं

Android Gradle प्लग इन के इस वर्शन में ये नई सुविधाएं शामिल हैं.

Kotlin स्क्रिप्ट डीएसएल के लिए सहायता

Kotlin buildscript के उपयोगकर्ताओं के लिए, बदलाव करने के अनुभव को बेहतर बनाने के लिए, Android Gradle प्लग इन 4.1 के डीएसएल और एपीआई को अब Kotlin इंटरफ़ेस के सेट में, लागू करने वाली क्लास से अलग से तय किया गया है. इसका मतलब है कि:

• Kotlin टाइप के लिए, अब साफ़ तौर पर यह बताया जाता है कि वैल्यू शून्य हो सकती है या नहीं और उसमें बदलाव किया जा सकता है या नहीं.
• इन इंटरफ़ेस से जनरेट किए गए दस्तावेज़, Kotlin API रेफ़रंस में पब्लिश किए गए हैं.
• Android Gradle प्लग इन के एपीआई के बारे में साफ़ तौर पर बताया गया है, ताकि आने वाले समय में Android बिल्ड को आसानी से एक्सटेंड किया जा सके.

अहम जानकारी: अगर आपने पहले से ही KTS बिल्ड स्क्रिप्ट को अपना लिया है या buildSrc में Kotlin का इस्तेमाल किया है, तो कुछ गड़बड़ियों की वजह से सोर्स के साथ काम करने की सुविधा बंद हो सकती है. ये गड़बड़ियां, पिछली रिलीज़ में रन-टाइम गड़बड़ियों के तौर पर दिखती थीं.

डीएसएल में बदलाव करने के लिए डिज़ाइन किए गए कलेक्शन टाइप को अब एक जैसा परिभाषित किया गया है:

val collection: MutableCollectionType

इसका मतलब है कि कुछ ऐसे कलेक्शन के लिए, अब Kotlin स्क्रिप्ट में ये लिखना संभव नहीं है जिनमें पहले यह सुविधा काम करती थी:

collection = collectionTypeOf(...)

हालांकि, कलेक्शन में बदलाव करने की सुविधा एक जैसी है. इसलिए, collection += … और collection.add(...) अब हर जगह काम करेगा.

अगर आपको Android Gradle प्लग इन के Kotlin एपीआई और डीएसएल का इस्तेमाल करने वाले किसी प्रोजेक्ट को अपग्रेड करते समय कोई समस्या आती है, तो कृपया बग की शिकायत करें.

AAR से C/C++ डिपेंडेंसी एक्सपोर्ट करना

Android Gradle प्लग इन 4.0 में, एएआर डिपेंडेंसी में प्रीफ़ैब पैकेज इंपोर्ट करने की सुविधा जोड़ी गई है. AGP 4.1 में, अब Android लाइब्रेरी प्रोजेक्ट के लिए, बाहरी नेटिव बिल्ड से लाइब्रेरी को AAR में एक्सपोर्ट किया जा सकता है.

नेटिव लाइब्रेरी एक्सपोर्ट करने के लिए, अपने लाइब्रेरी प्रोजेक्ट की build.gradle फ़ाइल के android ब्लॉक में ये चीज़ें जोड़ें:

buildFeatures {
    prefabPublishing true
}


prefab {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      

इस उदाहरण में, ndk-build या CMake के बाहरी नेटिव बिल्ड में मौजूद mylibrary और myotherlibrary लाइब्रेरी को, आपके बिल्ड से तैयार किए गए AAR में पैकेज किया जाएगा. साथ ही, हर लाइब्रेरी, तय की गई डायरेक्ट्री से हेडर को अपने डिपेंडेंट में एक्सपोर्ट करेगी.

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

Kotlin मेटाडेटा के लिए R8 की सहायता

Kotlin, Java क्लास फ़ाइलों में कस्टम मेटाडेटा का इस्तेमाल करके, Kotlin भाषा के कॉन्स्ट्रक्ट की पहचान करता है. R8 में अब Kotlin के मेटाडेटा को बनाए रखने और उसे फिर से लिखने की सुविधा है. इससे, kotlin-reflect का इस्तेमाल करके Kotlin लाइब्रेरी और ऐप्लिकेशन को छोटा करने में पूरी मदद मिलती है.

Kotlin मेटाडेटा को बनाए रखने के लिए, Keep के इन नियमों को जोड़ें:

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

यह R8 को निर्देश देगा कि वह उन सभी क्लास के लिए Kotlin मेटाडेटा बनाए रखे जिन्हें सीधे तौर पर रखा गया है.

ज़्यादा जानकारी के लिए, Medium पर R8 के साथ Kotlin रिफ़्लेक्शन का इस्तेमाल करके, Kotlin लाइब्रेरी और ऐप्लिकेशन को छोटा करना{:.external} लेख पढ़ें.

डीबग बिल्ड में एश्योरेशन

Android Gradle Plugin 4.1.0 और उसके बाद के वर्शन का इस्तेमाल करके, अपने ऐप्लिकेशन का डीबग वर्शन बनाने पर, पहले से मौजूद कंपाइलर (D8) आपके ऐप्लिकेशन का कोड फिर से लिख देगा. ऐसा इसलिए किया जाता है, ताकि कंपाइल करने के समय, एश्योरेशन चालू हो सकें. इससे, आपके पास हमेशा एश्योरेशन की जांच करने की सुविधा चालू रहेगी.

उपयोगकर्ता के व्यवहार में बदलाव

Android Gradle प्लग इन के बिल्ड कैश मेमोरी को हटा दिया गया

AGP 4.1 में, AGP बिल्ड कैश मेमोरी हटा दी गई थी. AGP बिल्ड कैश को पहले AGP 2.3 में, Gradle बिल्ड कैश के साथ इस्तेमाल करने के लिए लॉन्च किया गया था. हालांकि, AGP 4.1 में Gradle बिल्ड कैश ने AGP बिल्ड कैश की जगह ले ली. इस बदलाव से, बिल्ड में लगने वाले समय पर कोई असर नहीं पड़ता.

cleanBuildCache टास्क और android.enableBuildCache और android.buildCacheDir प्रॉपर्टी अब काम नहीं करती हैं. साथ ही, इन्हें एजीपी 7.0 में हटा दिया जाएगा. फ़िलहाल, android.enableBuildCache प्रॉपर्टी का कोई असर नहीं पड़ेगा. वहीं, android.buildCacheDir प्रॉपर्टी और cleanBuildCache टास्क, AGP 7.0 के रिलीज़ होने तक काम करेंगे. ऐसा इसलिए, ताकि AGP के किसी भी मौजूदा बिल्ड कैश मेमोरी कॉन्टेंट को मिटाया जा सके.

कोड छोटा करने की सुविधा का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, ऐप्लिकेशन का साइज़ काफ़ी कम हो गया है

इस रिलीज़ से, R क्लास के फ़ील्ड को डिफ़ॉल्ट रूप से नहीं रखा जाता. इसकी वजह से, कोड को छोटा करने की सुविधा चालू करने वाले ऐप्लिकेशन के APK के साइज़ में काफ़ी कमी आ सकती है. इससे तब तक कोई बदलाव नहीं होगा, जब तक कि आप रिफ़्लेक्शन की मदद से R क्लास को ऐक्सेस न कर रहे हों. ऐसे में, उन R क्लास के लिए रखें नियम जोड़ना ज़रूरी है.

android.namespacedRClass प्रॉपर्टी का नाम बदलकर android.nonTransitiveRClass कर दिया गया है

एक्सपेरिमेंटल फ़्लैग android.namespacedRClass का नाम बदलकर android.nonTransitiveRClass कर दिया गया है.

gradle.properties फ़ाइल में सेट किया गया यह फ़्लैग, हर लाइब्रेरी की R क्लास के लिए नेमस्पेस की सुविधा चालू करता है. इससे, R क्लास में सिर्फ़ लाइब्रेरी में बताए गए संसाधन शामिल होते हैं, न कि लाइब्रेरी की डिपेंडेंसी. इससे, उस लाइब्रेरी के लिए R क्लास का साइज़ कम हो जाता है.

Kotlin DSL: coreLibraryDesugaringEnabled का नाम बदला गया

Kotlin DSL कंपाइल करने के विकल्प coreLibraryDesugaringEnabled को बदलकर isCoreLibraryDesugaringEnabled कर दिया गया है. इस फ़्लैग के बारे में ज़्यादा जानने के लिए, Java 8+ एपीआई को डी-सुगर करने की सुविधा (Android Gradle प्लग इन 4.0.0+) देखें.

लाइब्रेरी प्रोजेक्ट में, BuildConfig क्लास से वर्शन प्रॉपर्टी हटाई गईं

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

Android Gradle प्लग इन के आने वाले वर्शन में, लाइब्रेरी के लिए डीएसएल से versionName और versionCode प्रॉपर्टी भी हटा दी जाएंगी. फ़िलहाल, लाइब्रेरी सब-प्रोजेक्ट से ऐप्लिकेशन के वर्शन कोड/नाम को अपने-आप ऐक्सेस करने का कोई तरीका नहीं है.

ऐप्लिकेशन मॉड्यूल के लिए, कोई बदलाव नहीं हुआ है. आपके पास अब भी डीएसएल में versionCode और versionName के लिए वैल्यू असाइन करने का विकल्प है. ये वैल्यू ऐप्लिकेशन के मेनिफ़ेस्ट और BuildConfig फ़ील्ड में दिखेंगी.

NDK पाथ सेट करना

अपने मॉड्यूल की build.gradle फ़ाइल में android.ndkPath प्रॉपर्टी का इस्तेमाल करके, अपने स्थानीय NDK इंस्टॉलेशन का पाथ सेट किया जा सकता है.

android {
  ndkPath "your-custom-ndk-path"
}

android {
  ndkPath = "your-custom-ndk-path"
}

अगर इस प्रॉपर्टी का इस्तेमाल, android.ndkVersion प्रॉपर्टी के साथ किया जाता है, तो इस पाथ में android.ndkVersion से मैच करने वाला NDK वर्शन होना चाहिए.

लाइब्रेरी यूनिट टेस्ट के व्यवहार में बदलाव

हमने लाइब्रेरी यूनिट टेस्ट को कंपाइल और चलाने के तरीके में बदलाव किया है. लाइब्रेरी के यूनिट टेस्ट को अब कंपाइल किया जाता है और लाइब्रेरी की कंपाइल/रनटाइम क्लास के ख़िलाफ़ चलाया जाता है. इस वजह से, यूनिट जांच में लाइब्रेरी का इस्तेमाल बाहरी सब-प्रोजेक्ट की तरह ही किया जाता है. आम तौर पर, इस कॉन्फ़िगरेशन से बेहतर टेस्टिंग होती है.

कुछ मामलों में, डेटा बाइंडिंग का इस्तेमाल करने वाली लाइब्रेरी यूनिट टेस्ट में, DataBindingComponent या BR क्लास मौजूद न होने की समस्या आ सकती है. उन टेस्ट को androidTest प्रोजेक्ट में, इंस्ट्रूमेंट किए गए टेस्ट में पोर्ट करना होगा. ऐसा इसलिए, क्योंकि यूनिट टेस्ट में उन क्लास को कंपाइल और चलाने से गलत आउटपुट मिल सकता है.

io.fabric Gradle प्लग इन का इस्तेमाल बंद कर दिया गया है

io.fabric Gradle प्लग इन का इस्तेमाल नहीं किया जा सकता. यह 'Android Gradle प्लग इन' के 4.1 वर्शन के साथ काम नहीं करता. काम नहीं करने वाले फ़ैब्रिक SDK टूल के बारे में ज़्यादा जानने और Firebase Crashlytics SDK टूल पर माइग्रेट करने के बारे में ज़्यादा जानने के लिए, Firebase Crashlytics SDK टूल पर अपग्रेड करने का लेख पढ़ें.