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 की इंस्टॉलेशन डायरेक्ट्री पर सेट करके अपग्रेड करें.

ध्यान दें कि बंद किए जा चुके एसडीके टूल पैकेज में मौजूद एसडीके मैनेजर और AVD मैनेजर, जेडीके 11 के साथ काम नहीं करते. AGP 7.0 और इसके बाद वाले वर्शन के साथ एसडीके मैनेजर और AVD मैनेजर का इस्तेमाल जारी रखने के लिए, आपको मौजूदा 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
  }
}

Lint के टास्क अब UP-TO-DATE हो सकते हैं

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

अगर Lint रिपोर्ट के इनपुट में कोई बदलाव नहीं हुआ है, तो Lint रिपोर्ट टास्क को भी चलाने की ज़रूरत नहीं है. **पहले से मालूम** एक समस्या यह है कि जब लिंट टास्क UP-TO-DATE होता है, तो 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 रिसॉर्स फ़ोल्डर में मौजूद नेटिव लाइब्रेरी को नज़रअंदाज़ कर दिया जाता है. इसके बजाय, नेटिव लाइब्रेरी के लिए बने DSL तरीके, 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). इस समस्या को हल करने के लिए, इन लाइब्रेरी पर लिंट टास्क चलाया जा सकता है. ज़्यादा जानकारी के लिए, लिंट के व्यवहार में बदलाव देखें.