Android Gradle प्लग इन 7.0.0 (जुलाई 2021)

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

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

AGP 7.0 चलाने के लिए, JDK 11 की ज़रूरत है

अपना ऐप्लिकेशन बनाने के लिए, Android Gradle plugin 7.0 का इस्तेमाल करने पर, Gradle को चलाने के लिए अब JDK 11 की ज़रूरत होगी. Android Studio Arctic Fox में JDK 11 बंडल किया गया है और इसे डिफ़ॉल्ट रूप से इस्तेमाल करने के लिए, Gradle को कॉन्फ़िगर किया गया है. इसका मतलब है कि Android Studio के ज़्यादातर उपयोगकर्ताओं को अपने प्रोजेक्ट में कॉन्फ़िगरेशन में कोई बदलाव करने की ज़रूरत नहीं है.

अगर आपको Android Studio में AGP टूल के इस्तेमाल किए जाने वाले JDK वर्शन को मैन्युअल तरीके से सेट करना है, तो आपको JDK 11 या उसके बाद के वर्शन का इस्तेमाल करना होगा.

Android Studio के बिना AGP का इस्तेमाल करते समय, JDK वर्शन को अपग्रेड करें. इसके लिए, JAVA_HOME एनवायरमेंट वैरिएबल या -Dorg.gradle.java.home कमांड-लाइन विकल्प को JDK 11 की इंस्टॉलेशन डायरेक्ट्री पर सेट करें.

ध्यान दें कि SDK टूल के पुराने पैकेज में मौजूद SDK मैनेजर और AVD मैनेजर,JDK 11 के साथ काम नहीं करते. AGP 7.0 और उसके बाद के वर्शन के साथ SDK मैनेजर और AVD मैनेजर का इस्तेमाल जारी रखने के लिए, आपको मौजूदा Android SDK कमांड-लाइन टूल्स पैकेज में टूल के नए वर्शन पर स्विच करना होगा.

Variant API का स्टेबल वर्शन

Variant API का नया वर्शन अब स्टेबल है. com.android.build.api.variant पैकेज में नए इंटरफ़ेस और gradle-recipes GitHub प्रोजेक्ट में उदाहरण देखें. Variant API के नए वर्शन के तहत, हमने कई इंटरमीडियरी फ़ाइलें उपलब्ध कराई हैं. इन्हें आर्टफ़ैक्ट कहा जाता है. इन्हें आर्टफ़ैक्ट इंटरफ़ेस के ज़रिए ऐक्सेस किया जा सकता है. मर्ज किए गए मेनिफ़ेस्ट जैसे आर्टफ़ैक्ट को सुरक्षित तरीके से हासिल किया जा सकता है और तीसरे पक्ष के प्लग इन और कोड का इस्तेमाल करके, उन्हें पसंद के मुताबिक बनाया जा सकता है.

हम वैरिएंट एपीआई में नई सुविधाएं जोड़ते रहेंगे और उन इंटरमीडिएट आर्टफ़ैक्ट की संख्या बढ़ाते रहेंगे जिन्हें हम पसंद के मुताबिक बनाने के लिए उपलब्ध कराते हैं.

Lint के काम करने के तरीके में बदलाव

इस सेक्शन में, Android Gradle प्लग इन 7.0.0 में Lint के काम करने के तरीके में हुए कई बदलावों के बारे में बताया गया है.

लाइब्रेरी डिपेंडेंसी के लिए बेहतर लिंट

checkDependencies = true के साथ लिंट चलाने की प्रोसेस अब पहले से ज़्यादा तेज़ हो गई है. लाइब्रेरी डिपेंडेंसी वाले ऐप्लिकेशन वाले Android प्रोजेक्ट के लिए, हमारा सुझाव है कि आप checkDependencies को यहां दिखाए गए तरीके से true पर सेट करें. साथ ही, ./gradlew :app:lint के ज़रिए lint चलाएं. इससे, सभी डिपेंडेंसी मॉड्यूल का एक साथ विश्लेषण किया जाएगा और ऐप्लिकेशन और उसकी सभी डिपेंडेंसी से जुड़ी समस्याओं वाली एक रिपोर्ट जनरेट होगी.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

अब लिंट टास्क अप-टू-डेट किए जा सकते हैं

अगर किसी मॉड्यूल के सोर्स और संसाधनों में बदलाव नहीं हुआ है, तो मॉड्यूल के लिए, लिंट विश्लेषण का टास्क फिर से चलाने की ज़रूरत नहीं है. ऐसा होने पर, Gradle के आउटपुट में टास्क के लागू होने की स्थिति "अप-टू-डेट" के तौर पर दिखती है. इस बदलाव के बाद, checkDependencies = true के साथ किसी ऐप्लिकेशन मॉड्यूल पर लिंट चलाने पर, सिर्फ़ उन मॉड्यूल का विश्लेषण करना होगा जिनमें बदलाव किए गए हैं. इस वजह से, Lint ज़्यादा तेज़ी से काम कर सकता है.

अगर लिंट रिपोर्ट के इनपुट में कोई बदलाव नहीं हुआ है, तो उस टास्क को भी चलाने की ज़रूरत नहीं है. इससे जुड़ी एक पहचानी गई समस्या यह है कि जब लिंट टास्क अप-टू-डेट हो, तो स्टैंडर्ड आउटपुट पर कोई लिंट टेक्स्ट आउटपुट नहीं दिखता (समस्या #191897708).

डाइनैमिक-फ़ीचर मॉड्यूल पर लिंट चलाना

AGP अब डाइनैमिक-फ़ीचर मॉड्यूल से लिंट चलाने की सुविधा नहीं देता. संबंधित ऐप्लिकेशन मॉड्यूल से लिंट चलाने पर, उसके डाइनैमिक-फ़ीचर मॉड्यूल पर भी लिंट चलेगा. साथ ही, ऐप्लिकेशन की लिंट रिपोर्ट में सभी समस्याएं शामिल होंगी. इससे जुड़ी एक पहले से मौजूद समस्या यह है कि ऐप्लिकेशन मॉड्यूल से checkDependencies = true के साथ lint को चलाने पर, डाइनैमिक-फ़ीचर लाइब्रेरी की डिपेंडेंसी की जांच तब तक नहीं की जाती, जब तक वे ऐप्लिकेशन की डिपेंडेंसी भी न हों (समस्या #191977888).

सिर्फ़ डिफ़ॉल्ट वैरिएंट पर लिंट चलाना

./gradlew :app:lint को चलाने पर, अब सिर्फ़ डिफ़ॉल्ट वैरिएंट के लिए लिंट की प्रोसेस शुरू होती है. AGP के पिछले वर्शन में, यह सभी वैरिएंट के लिए लिंट चलाता था.

R8 श्रिंकर में क्लास की चेतावनियां मौजूद नहीं हैं

R8, मौजूद न होने वाली क्लास और -dontwarn विकल्प को ज़्यादा सटीक और लगातार मैनेज करता है. इसलिए, आपको R8 के ज़रिए दी गई, क्लास की उन चेतावनियों का आकलन करना शुरू करना चाहिए जो मौजूद नहीं हैं.

जब R8 को किसी ऐसे क्लास रेफ़रंस का पता चलता है जो आपके ऐप्लिकेशन या उसकी किसी डिपेंडेंसी में तय नहीं किया गया है, तो वह एक चेतावनी जारी करेगा. यह चेतावनी, आपके बिल्ड आउट में दिखेगी. उदाहरण के लिए:

R8: Missing class: java.lang.instrument.ClassFileTransformer

इस चेतावनी का मतलब है कि आपके ऐप्लिकेशन के कोड का विश्लेषण करते समय, क्लास की परिभाषा java.lang.instrument.ClassFileTransformer नहीं मिली. आम तौर पर, इसका मतलब है कि कोई गड़बड़ी है. हालांकि, ऐसा हो सकता है कि आप इस चेतावनी को अनदेखा करना चाहें. चेतावनी को अनदेखा करने की दो सामान्य वजहें ये हैं:

1. JVM और छूटी हुई क्लास को टारगेट करने वाली लाइब्रेरी, JVM लाइब्रेरी टाइप की होती हैं (जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है).

2. आपकी किसी डिपेंडेंसी में, सिर्फ़ कंपाइल के समय काम करने वाले एपीआई का इस्तेमाल किया जाता है.

proguard-rules.pro फ़ाइल में -dontwarn नियम जोड़कर, क्लास मौजूद न होने की चेतावनी को अनदेखा किया जा सकता है. उदाहरण के लिए:

-dontwarn java.lang.instrument.ClassFileTransformer

आपकी सुविधा के लिए, AGP एक फ़ाइल जनरेट करेगा जिसमें ऐसे सभी नियम शामिल होंगे जो शायद मौजूद न हों. साथ ही, उन्हें इस तरह के फ़ाइल पाथ में लिखा जाएगा: app/build/outputs/mapping/release/missing_rules.txt. चेतावनियों को अनदेखा करने के लिए, अपनी proguard-rules.pro फ़ाइल में नियम जोड़ें.

AGP 7.0 में, क्लास के मैसेज न मिलने पर चेतावनियां दिखेंगी. इन्हें गड़बड़ियों में बदलने के लिए, gradle.properties में android.r8.failOnMissingClasses = true सेट करें. AGP 8.0 में, ये चेतावनियां ऐसी गड़बड़ियां बन जाएंगी जिनकी वजह से आपका बिल्ड पूरा नहीं होगा. proguard-rules.pro फ़ाइल में -ignorewarnings विकल्प जोड़कर, AGP 7.0 के व्यवहार को बनाए रखा जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें.

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

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

AGP 7.0 में, android.enableBuildCache प्रॉपर्टी, android.buildCacheDir प्रॉपर्टी, और cleanBuildCache टास्क हटा दिए गए हैं.

अपने प्रोजेक्ट में Java 11 सोर्स कोड का इस्तेमाल करना

अब अपने ऐप्लिकेशन के प्रोजेक्ट में, Java 11 तक के सोर्स कोड को कॉम्पाइल किया जा सकता है. इससे, आपको भाषा की नई सुविधाओं का इस्तेमाल करने में मदद मिलेगी. जैसे, निजी इंटरफ़ेस के तरीके, अनाम क्लास के लिए डायमंड ऑपरेटर, और लैंब्डा पैरामीटर के लिए स्थानीय वैरिएबल सिंटैक्स.

इस सुविधा को चालू करने के लिए, compileOptions को अपने पसंदीदा Java वर्शन पर सेट करें और compileSdkVersion को 30 या उससे ज़्यादा पर सेट करें:

// build.gradle
android {
  compileSdkVersion 30
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_11
    targetCompatibility JavaVersion.VERSION_11
  }
  // For Kotlin projects
  kotlinOptions {
    jvmTarget = "11"
  }
}

// build.gradle.kts
android {
  compileSdkVersion(30)
  compileOptions {
    sourceCompatibility(JavaVersion.VERSION_11)
    targetCompatibility(JavaVersion.VERSION_11)
  }
  kotlinOptions {
    jvmTarget = "11"
  }
}

डिपेंडेंसी कॉन्फ़िगरेशन हटाए गए

AGP 7.0 में, ये कॉन्फ़िगरेशन (या डिपेंडेंसी स्कोप) हटा दिए गए हैं:

• compile
  इस्तेमाल के उदाहरण के आधार पर, इसे api या implementation से बदल दिया गया है.
  यह *Compile वैरिएंट पर भी लागू होता है. उदाहरण के लिए: debugCompile.
• provided
  इसे compileOnly से बदल दिया गया है.
  यह *उपलब्ध वैरिएंट पर भी लागू होता है. उदाहरण के लिए: releaseProvided.
• apk
  इसे runtimeOnly से बदल दिया गया है.
• publish
  इसे runtimeOnly से बदल दिया गया है.

ज़्यादातर मामलों में, AGP Upgrade Assistant आपके प्रोजेक्ट को नए कॉन्फ़िगरेशन पर अपने-आप माइग्रेट कर देगा.

Android Gradle प्लग इन के साथ कंपाइल करते समय, क्लासपाथ में बदलाव

अगर Android Gradle प्लग इन के लिए कॉम्पाइल किया जा रहा है, तो आपका compile classpath बदल सकता है. AGP अब अंदरूनी तौर पर api/implementation कॉन्फ़िगरेशन का इस्तेमाल करता है. इसलिए, हो सकता है कि आपके कंपाइल किए गए क्लासपाथ से कुछ आर्टफ़ैक्ट हटा दिए जाएं. अगर कंपाइल के समय AGP डिपेंडेंसी का इस्तेमाल किया जाता है, तो उसे साफ़ तौर पर डिपेंडेंसी के तौर पर जोड़ना न भूलें.

Java संसाधन फ़ोल्डर में नेटिव लाइब्रेरी जोड़ने की सुविधा उपलब्ध नहीं है

पहले, किसी Java रिसॉर्स फ़ोल्डर में नेटिव लाइब्रेरी जोड़ी जा सकती थी और android.sourceSets.main.resources.srcDirs का इस्तेमाल करके फ़ोल्डर को रजिस्टर किया जा सकता था, ताकि नेटिव लाइब्रेरी को निकाला जा सके और उसे फ़ाइनल APK में जोड़ा जा सके. AGP 7.0 से, यह सुविधा काम नहीं करती. साथ ही, Java रिसॉर्स फ़ोल्डर में मौजूद नेटिव लाइब्रेरी को अनदेखा कर दिया जाता है. इसके बजाय, नेटिव लाइब्रेरी के लिए बने डीएसएल तरीके का इस्तेमाल करें, android.sourceSets.main.jniLibs.srcDirs. ज़्यादा जानकारी के लिए, सोर्स सेट को कॉन्फ़िगर करने का तरीका देखें.

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

इस सेक्शन में, Android Gradle प्लग इन के 7.0.0 वर्शन में मौजूद समस्याओं के बारे में बताया गया है.

Kotlin Multiplatform प्लग इन के 1.4.x वर्शन के साथ काम नहीं करता

Android Gradle प्लग इन 7.0.0, Kotlin मल्टीप्लैटफ़ॉर्म प्लग इन 1.5.0 और इसके बाद के वर्शन के साथ काम करता है. Kotlin के मल्टीप्लैटफ़ॉर्म के साथ काम करने की सुविधा का इस्तेमाल करने वाले प्रोजेक्ट को, Android Gradle प्लग इन 7.0.0 का इस्तेमाल करने के लिए, Kotlin 1.5.0 पर अपडेट करना होगा. इस समस्या को हल करने के लिए, 'Android Gradle प्लग इन' को 4.2.x पर डाउनग्रेड किया जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें.

ज़्यादा जानकारी के लिए, KT-43944 देखें.

लिंट आउटपुट मौजूद नहीं है

अगर लिंट टास्क अप-टू-डेट है, तो स्टैंडर्ड आउटपुट पर कोई लिंट टेक्स्ट आउटपुट नहीं दिखता (समस्या #191897708). ज़्यादा जानकारी के लिए, lint की सुविधा के काम करने के तरीके में हुए बदलाव देखें. इस समस्या को Android Gradle प्लग इन 7.1 में ठीक कर दिया जाएगा.

डाइनैमिक-फ़ीचर लाइब्रेरी की सभी डिपेंडेंसी की जांच, लिंट की मदद से नहीं की जाती

ऐप्लिकेशन मॉड्यूल से checkDependencies = true के साथ lint चलाने पर, डाइनैमिक-फ़ीचर लाइब्रेरी डिपेंडेंसी की जांच तब तक नहीं की जाती, जब तक वे ऐप्लिकेशन डिपेंडेंसी भी न हों (समस्या #191977888). इस समस्या को हल करने के लिए, उन लाइब्रेरी पर लिंट टास्क चलाया जा सकता है. ज़्यादा जानकारी के लिए, lint की सुविधा के काम करने के तरीके में हुए बदलाव देखें.