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

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

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

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

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

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

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

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

वैरिएंट एपीआई स्टेबल

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

हम 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
  }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-dontwarn java.lang.instrument.ClassFileTransformer

आपकी सुविधा के लिए, एजीपी एक ऐसी फ़ाइल जनरेट करेगा जिसमें उन सभी नियमों की जानकारी होगी जो शायद मौजूद नहीं हैं. साथ ही, उन्हें इस पाथ पर लिखा जाएगा: 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 विकल्प जोड़कर, एजीपी 7.0 के व्यवहार को बनाए रखा जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें.

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

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

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

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

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

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

पहले, 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 Multiplatform का इस्तेमाल करने वाले प्रोजेक्ट को Android Gradle प्लगिन 7.0.0 का इस्तेमाल करने के लिए, Kotlin 1.5.0 पर अपडेट करना होगा. इस समस्या को हल करने के लिए, Android Gradle प्लगिन को 4.2.x पर डाउनग्रेड किया जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें.

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

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

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

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

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