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

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

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

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

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

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

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

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

वैरिएंट एपीआई अब स्थिर है

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

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

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

इस सेक्शन में, 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).

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

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

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

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

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

सुविधा के लिए, 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 से बदल दिया गया है.
  यह *Provided वैरिएंट पर भी लागू होता है. उदाहरण के लिए: 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 प्लगिन 1.5.0 और इसके बाद वाले वर्शन के साथ काम करता है. Android Gradle प्लगिन 7.0.0 का इस्तेमाल करने के लिए, Kotlin Multiplatform की सुविधा का इस्तेमाल करने वाले प्रोजेक्ट को Kotlin 1.5.0 पर अपडेट करना होगा. इसके बजाय, Android Gradle प्लगिन को 4.2.x पर डाउनग्रेड किया जा सकता है . हालांकि, ऐसा करने का सुझाव नहीं दिया जाता.

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

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

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

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

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