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 Manager और AVD Manager, JDK 11 के साथ काम नहीं करते. AGP 7.0 और इसके बाद के वर्शन के साथ SDK Manager और AVD Manager का इस्तेमाल जारी रखने के लिए, आपको Android SDK Command-Line Tools package के मौजूदा वर्शन में मौजूद टूल के नए वर्शन पर स्विच करना होगा.

Variant API stable

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

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

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

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

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

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

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

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

अब Lint टास्क को UP-TO-DATE के तौर पर मार्क किया जा सकता है

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

अगर इनपुट में कोई बदलाव नहीं हुआ है, तो Lint रिपोर्ट टास्क को चलाने की भी ज़रूरत नहीं है. इससे जुड़ी एक ज्ञात समस्या यह है कि जब लिंट टास्क UP-TO-DATE होता है, तब stdout में कोई लिंट टेक्स्ट आउटपुट प्रिंट नहीं होता (समस्या #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 में, क्लास के मौजूद न होने पर दिखने वाले मैसेज, चेतावनियों के तौर पर दिखेंगे. साथ ही, android.r8.failOnMissingClasses = true में gradle.properties सेट करके, उन्हें गड़बड़ियों में बदला जा सकता है. AGP 8.0 में, ये चेतावनियां ऐसी गड़बड़ियों में बदल जाएंगी जिनकी वजह से आपका बिल्ड रुक जाएगा. proguard-rules.pro फ़ाइल में -ignorewarnings विकल्प जोड़कर, AGP 7.0 के व्यवहार को बनाए रखा जा सकता है. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता.

Android Gradle प्लग इन का बिल्ड कैश हटा दिया गया है

AGP 4.1 में, AGP की बिल्ड कैश मेमोरी को हटा दिया गया था. AGP 2.3 में, Gradle की बिल्ड कैश मेमोरी के साथ काम करने के लिए, AGP की बिल्ड कैश मेमोरी को पेश किया गया था. हालांकि, AGP 4.1 में AGP की बिल्ड कैश मेमोरी को पूरी तरह से 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 अपग्रेड असिस्टेंट आपके प्रोजेक्ट को नए कॉन्फ़िगरेशन पर अपने-आप माइग्रेट कर देगा.

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

अगर Android Gradle प्लगिन के ख़िलाफ़ कंपाइल किया जा रहा है, तो आपका कंपाइल क्लाथपाथ बदल सकता है. 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 Multiplatform plugin 1.5.0 और इसके बाद के वर्शन के साथ काम करता है. जिन प्रोजेक्ट में Kotlin Multiplatform का इस्तेमाल किया जाता है उन्हें Android Gradle Plugin 7.0.0 का इस्तेमाल करने के लिए, Kotlin 1.5.0 पर अपडेट करना होगा. इसके लिए, Android Gradle प्लग इन को 4.2.x पर डाउनग्रेड किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता है.

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

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

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

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

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