Android Gradle प्लग इन 7.1.0 (जनवरी 2022)

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

7.1.3 (अप्रैल 2022)

इस छोटे अपडेट में ये गड़बड़ियां ठीक की गई हैं:

  • R8 ने डुप्लीकेट क्लास से जुड़ी समस्याओं की शिकायत की है

इस रिलीज़ में शामिल गड़बड़ियों को ठीक करने के बारे में पूरी जानकारी पाने के लिए, Android Studio Bumblebee पैच 3 ब्लॉग पोस्ट देखें.

7.1.2 (फ़रवरी 2022)

इस छोटे अपडेट में, गड़बड़ियों को ठीक किया गया है:

  • Android Gradle प्लग इन 7.1.0-rc01, यूनिट टेस्ट के दौरान ASM बाइटकोड ट्रांसफ़ॉर्मेशन नहीं कर पाता
  • "क्लास 'com.android.build.api.extension.AndroidcomponentsExtension' को लोड नहीं किया जा सका" की वजह से ग्रेडल सिंक नहीं हो पाता है.
  • Android Gradle प्लग इन 7.0.0 में, कुछ नए डीएसएल ब्लॉक, ग्रूवी डीएसएल से इस्तेमाल नहीं किए जा सकते
  • AGP 7.1 का नया पब्लिशिंग एपीआई: बनाए गए javadoc jar पर हस्ताक्षर नहीं होता
  • ClassesDataSourceCache को Asm के नए वर्शन का इस्तेमाल करना चाहिए
  • Android Studio BumbleBee हमेशा नए बदलावों को डिप्लॉय नहीं करता

इस रिलीज़ में शामिल बग ठीक करने की पूरी सूची देखने के लिए, Android Studio Bumblebee पैच 2 ब्लॉग पोस्ट देखें.

7.1.1 (फ़रवरी 2022)

यह मामूली अपडेट, Android Studio Bumblebee Patch 1 के रिलीज़ होने से जुड़ा है.

इस रिलीज़ में शामिल गड़बड़ियों को ठीक करने के बारे में जानने के लिए, Android Studio Bumblebee पैच 1 ब्लॉग पोस्ट देखें.

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

कम से कम वर्शन डिफ़ॉल्ट वर्शन नोट
Gradle 7.2 7.2 ज़्यादा जानने के लिए, Gradle को अपडेट करना लेख पढ़ें.
SDK टूल के लिए बिल्ड टूल 30.0.3 30.0.3 SDK Build Tools को इंस्टॉल या कॉन्फ़िगर करें.
एनडीके लागू नहीं 21.4.7075529 एनडीके के किसी दूसरे वर्शन को इंस्टॉल करें या कॉन्फ़िगर करें.
JDK 11 11 ज़्यादा जानने के लिए, JDK वर्शन सेट करना देखें.

लिंट विश्लेषण टास्क अब कैश किया जा सकता है

AndroidLintAnalysisTask अब Gradle के बिल्ड कैश मेमोरी के साथ काम करता है. अगर आपने अपनी gradle.properties फ़ाइल में org.gradle.caching=true को सेट करके, बिल्ड कैश मेमोरी को चालू किया है, तो लिंट विश्लेषण टास्क को जब भी संभव होगा, तब बिल्ड कैश मेमोरी से उसका आउटपुट मिलेगा.

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

C/C++ मॉड्यूल अब एक ही प्रोजेक्ट में अन्य C/C++ मॉड्यूल का रेफ़रंस दे सकते हैं

C/C++ कोड के साथ Gradle Android मॉड्यूल को, अब किसी दूसरे Gradle मॉड्यूल में हेडर फ़ाइलों और लाइब्रेरी कोड का रेफ़रंस देने के लिए सेट अप किया जा सकता है. प्रीफ़ैब प्रोटोकॉल का इस्तेमाल, Gradle मॉड्यूल के बीच हेडर और लाइब्रेरी का डेटा भेजने के लिए किया जाता है.

ज़रूरी शर्तें

  • इस्तेमाल करने वाला मॉड्यूल CMake होना चाहिए, न कि ndk-build. एनडीके-बिल्ड के साथ काम करने के लिए, आने वाले समय में एनडीके से जुड़ा अपडेट करना होगा. पब्लिश करने वाला मॉड्यूल CMake या ndk-build हो सकता है.

  • इस्तेमाल करने वाले मॉड्यूल की मदद से, build.gradle फ़ाइल में prefab चालू होना चाहिए.

android {
  buildFeatures {
    prefab true
  }
}
  • पब्लिश करने वाले मॉड्यूल को build.gradle फ़ाइल में prefabPublishing को चालू करना होगा.
android {
  buildFeatures {
    prefabPublishing true
  }
}
  • इस्तेमाल करने वाले मॉड्यूल को build.gradle फ़ाइल dependencies ब्लॉक में एक लाइन जोड़कर, पब्लिश करने वाले मॉड्यूल का रेफ़रंस देना होगा. उदाहरण के लिए:
dependencies {
  implementation project(':mylibrary')
}
  • पब्लिश करने वाले मॉड्यूल को prefab सेक्शन का इस्तेमाल करके, पैकेज को एक्सपोज़ करना होगा. उदाहरण के लिए:
android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}
  • डेटा का इस्तेमाल करने वाले मॉड्यूल की CMakeLists.txt फ़ाइल, डेटा जनरेट करने वाले मॉड्यूल से पब्लिश किए गए पैकेज का पता लगाने के लिए, find_package() का इस्तेमाल कर सकती है. उदाहरण के लिए:
find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
  myapplication
  mylibrary::mylibrary)
  • पूरे ऐप्लिकेशन के लिए एक एसटीएल होना चाहिए. उदाहरण के लिए, डेटा का इस्तेमाल करने वाले और डेटा पब्लिश करने वाले, दोनों मॉड्यूल में C++ के शेयर किए गए STL का इस्तेमाल किया जा सकता है.
   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

AGP के साथ नेटिव AAR कंज्यूमर और प्रोड्यूसर को कॉन्फ़िगर करने के तरीके के बारे में ज़्यादा जानने के लिए, AGP के साथ नेटिव डिपेंडेंसी देखें.

settings.gradle फ़ाइल में डेटा स्टोर करने की जगह की सेटिंग

Android Studio Bumblebee में नया प्रोजेक्ट बनाने पर, टॉप-लेवल build.gradle फ़ाइल में plugins ब्लॉक होता है. इसके बाद, आपकी बिल्ड डायरेक्ट्री को खाली करने के लिए कोड होता है:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

पहले, रिपॉज़िटरी की सेटिंग, सबसे ऊपर मौजूद build.gradle फ़ाइल में होती थीं. अब ये सेटिंग settings.gradle फ़ाइल में मौजूद हैं:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}
dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

मॉड्यूल-लेवल की build.gradle फ़ाइल में कोई बदलाव नहीं हुआ है. इसलिए, अपने प्रोजेक्ट के सभी मॉड्यूल पर लागू होने वाले बिल्ड कॉन्फ़िगरेशन तय करने के लिए, टॉप-लेवल build.gradle फ़ाइल और settings.gradle फ़ाइल का इस्तेमाल करें. इसके अलावा, Gradle पर लागू होने वाली रिपॉज़िटरी और डिपेंडेंसी तय करने के लिए भी इनका इस्तेमाल करें. साथ ही, अपने प्रोजेक्ट के किसी मॉड्यूल के लिए खास तौर पर लागू होने वाले बिल्ड कॉन्फ़िगरेशन तय करने के लिए, मॉड्यूल-लेवल build.gradle फ़ाइल का इस्तेमाल करें.

बेहतर रिसॉर्स शंकर

Android Studio Bumblebee में, रिसॉर्स को छोटा करने के लिए बेहतर टूल उपलब्ध कराया गया है. इससे ऐप्लिकेशन का साइज़ कम किया जा सकता है.

डाइनैमिक सुविधाओं वाले ऐप्लिकेशन के लिए सहायता

Android संसाधन को छोटा करने वाले टूल को डिफ़ॉल्ट रूप से लागू करने की सुविधा को, Android Gradle प्लग इन 7.1.0-alpha09 में अपडेट किया गया है. नए तरीके से लागू करने पर, डाइनैमिक फ़ीचर की मदद से ऐप्लिकेशन के साइज़ को कम किया जा सकता है.

एक्सपेरिमेंट के तौर पर उपलब्ध ऐप्लिकेशन के साइज़ में और कमी

रिसॉर्स को छोटा करने वाले नए टूल की मदद से, आपके ऐप्लिकेशन का साइज़ और भी कम किया जा सकता है. इसके लिए, रिसॉर्स टेबल में बदलाव करके, इस्तेमाल नहीं किए गए वैल्यू रिसॉर्स और इस्तेमाल नहीं किए गए फ़ाइल रिसॉर्स के रेफ़रंस हटाए जाते हैं. संसाधन को छोटा करने वाला नया टूल, इस्तेमाल न किए गए फ़ाइल संसाधनों को पूरी तरह से मिटा सकता है. इससे आपके ऐप्लिकेशन का साइज़ भी कम हो जाता है. यह सुविधा अब तक डिफ़ॉल्ट रूप से चालू नहीं है. हालांकि, इसे आज़माने के लिए, अपने प्रोजेक्ट की gradle.properties फ़ाइल में, प्रयोग के तौर पर उपलब्ध विकल्प android.experimental.enableNewResourceShrinker.preciseShrinking=true को जोड़कर ऑप्ट-इन किया जा सकता है.

अगर आपको संसाधन को छोटा करने वाले नए टूल या प्रयोग के तौर पर उपलब्ध फ़्लैग से जुड़ी कोई समस्या आती है, तो कृपया उसकी शिकायत करें. समस्याओं का पता लगाने या कुछ समय के लिए समस्या हल करने के लिए, अपने प्रोजेक्ट के gradle.properties में android.enableNewResourceShrinker=false जोड़कर, पहले से लागू किए गए तरीके पर वापस स्विच किया जा सकता है. नया रिसॉर्स श्रिंकर, इस्तेमाल न किए गए फ़ाइल-आधारित रिसॉर्स को, रिसॉर्स श्रिंकर की पिछली सुविधा की तुलना में थोड़ी अलग और कम फ़ाइलों से बदल देता है. हालांकि, ऐसा होने पर भी रनटाइम पर कोई असर नहीं पड़ेगा.

लागू किए गए पुराने वर्शन को, 'Android Gradle प्लग इन 8.0.0' से हटाने के लिए शेड्यूल किया गया है.

वैरिएंट पब्लिश करने की सुविधा बनाएं

'Android Gradle प्लग इन 7.1.0' और इसके बाद के वर्शन की मदद से, यह कॉन्फ़िगर किया जा सकता है कि Apache Maven रिपॉज़िटरी में पब्लिश करने के लिए कौनसे बिल्ड वैरिएंट को इस्तेमाल करना है. AGP, पब्लिश करने के नए DSL के आधार पर, एक या एक से ज़्यादा बिल्ड वैरिएंट वाला कॉम्पोनेंट बनाता है. इसका इस्तेमाल, मेवन रिपॉज़िटरी में किसी पब्लिकेशन को पसंद के मुताबिक बनाने के लिए किया जा सकता है. पिछले वर्शन की तुलना में, इससे ग़ैर-ज़रूरी काम भी नहीं करना पड़ता, क्योंकि डिफ़ॉल्ट रूप से कोई कॉम्पोनेंट नहीं बनेगा. ज़्यादा जानने के लिए, कोड सैंपल पब्लिश करने का पेज देखें.

Javadoc JAR पब्लिश करें

AGP 7.1.0 और इसके बाद के वर्शन की मदद से, Java और Kotlin के सोर्स से Javadoc जनरेट किया जा सकता है. साथ ही, लाइब्रेरी प्रोजेक्ट के लिए AAR के साथ-साथ Javadoc JAR फ़ाइलें पब्लिश की जा सकती हैं. Javadoc को POM और Gradle मॉड्यूल मेटाडेटा{:.external} फ़ाइलों में जोड़ा जाता है. इस सुविधा को चालू करने के लिए, singleVariant या multipleVariants पब्लिशिंग ब्लॉक में withJavadocJar() जोड़ें. ज़्यादा जानने के लिए, पब्लिश करने के विकल्पों के लिए कोड सैंपल देखें.

सोर्स JAR पब्लिश करना

AGP 7.1.0 और इसके बाद के वर्शन की मदद से, लाइब्रेरी प्रोजेक्ट के लिए AAR के साथ-साथ Java और Kotlin सोर्स JAR फ़ाइलें भी पब्लिश की जा सकती हैं. सोर्स को POM और Gradle मॉड्यूल मेटाडेटा{:.external} फ़ाइलों में जोड़ा जाता है. इस सुविधा को चालू करने के लिए, singleVariant या multipleVariants पब्लिश करने वाले ब्लॉक में withSourcesJar() जोड़ें. ज़्यादा जानने के लिए, पब्लिश करने के विकल्पों के लिए कोड सैंपल देखें.

लिंट ब्लॉक में सिमेंटिक बदलाव

लिंट के ऐसे सभी तरीके जो किसी समस्या की गंभीरता के लेवल को बदलते हैं—enable, disable/ignore, informational, warning, error, fatal—अब कॉन्फ़िगरेशन के क्रम का पालन करते हैं. उदाहरण के लिए, finalizeDsl() में किसी समस्या को गंभीर के तौर पर सेट करने से, अब उसे मुख्य डीएसएल में बंद कर दिया जाता है. ज़्यादा जानकारी के लिए, lint{} ब्लॉक रेफ़रंस दस्तावेज़ और Android बिल्ड फ़्लो और एक्सटेंशन पॉइंट देखें.

नेविगेशन के लिए Safe Args Gradle प्लग इन पर काम करने वाले AGP एपीआई हटा दिए गए हैं. AGP 7.1, नेविगेशन सेफ़ आर्ग्युमेंट के 2.4.0-rc1 या 2.4.0 वर्शन के साथ काम नहीं करता. हालांकि, यह 2.5.0-alpha01 और 2.4.1 वर्शन के साथ काम करेगा. इस बीच, समस्या को हल करने के लिए, नेविगेशन के Safe Args के स्नैपशॉट बिल्ड, नेविगेशन 2.5.0-SNAPSHOT के साथ AGP 7.1 का इस्तेमाल किया जा सकता है. स्नैपशॉट बिल्ड का इस्तेमाल करने के लिए, बिल्ड आईडी #8054565 के साथ स्नैपशॉट के लिए दिए गए निर्देशों का पालन करें.

इसके अलावा, नेविगेशन Safe Args वर्शन 2.4.1 और 2.5.0 अब AGP 4.2 के साथ काम नहीं करेंगे; Safe Args के इन वर्शन का इस्तेमाल करने के लिए, आपको AGP 7.0 और इसके बाद के वर्शन का इस्तेमाल करना होगा.

अपने-आप कॉम्पोनेंट बनने की सुविधा बंद करना

AGP 8.0 से, अपने-आप कॉम्पोनेंट बनाने की सुविधा डिफ़ॉल्ट रूप से बंद हो जाएगी. फ़िलहाल, AGP 7.1 हर बिल्ड वैरिएंट के लिए अपने-आप एक कॉम्पोनेंट बनाता है. इसका नाम बिल्ड वैरिएंट के नाम जैसा ही होता है. साथ ही, एक all कॉम्पोनेंट भी बनाता है जिसमें सभी बिल्ड वैरिएंट शामिल होते हैं. अपने-आप कॉम्पोनेंट बनने की सुविधा बंद कर दी जाएगी. नई सुविधा पर जाने के लिए, आपको मैन्युअल तरीके से कॉम्पोनेंट अपने-आप बनने की सुविधा को बंद करना होगा. इसके लिए, android.disableAutomaticComponentCreation पर true. सेट करें. ज़्यादा जानकारी के लिए, Maven पब्लिश प्लगिन का इस्तेमाल करना देखें.

Firebase Performance Monitoring के साथ काम करने की सुविधा

AGP 7.1, Firebase परफ़ॉर्मेंस मॉनिटरिंग Gradle प्लग इन के 1.4.0 और उससे पहले के वर्शन के साथ काम नहीं करता. AGP अपग्रेड असिस्टेंट, प्लग इन को 1.4.1 वर्शन पर अपने-आप अपडेट नहीं करेगा. इसलिए, अगर firebase-perf का इस्तेमाल किया जा रहा है और आपको AGP को 7.1 पर अपग्रेड करना है, तो आपको यह अपग्रेड मैन्युअल तरीके से करना होगा.

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

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

Hilt प्लगिन का इस्तेमाल करने वाले ऐप्लिकेशन प्रोजेक्ट की यूनिट की जांच करने से जुड़ी समस्याएं

यूनिट टेस्ट के क्लासपाथ में बिना इंस्ट्रुमेंट वाले ऐप्लिकेशन क्लास शामिल हैं. इसका मतलब है कि Hilt, यूनिट टेस्ट चलाने के दौरान डिपेंडेंसी इंजेक्शन को हैंडल करने के लिए, ऐप्लिकेशन क्लास को इंस्ट्रुमेंट नहीं करता.

यह समस्या 7.1.1 रिलीज़ के साथ ठीक हो जाएगी, समस्या #213534628 देखें.