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

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

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

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

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

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

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

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

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

• इस्तेमाल करने वाला मॉड्यूल CMake होना चाहिए, न कि ndk-build. 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++ शेयर किए गए एसटीएल का इस्तेमाल कर सकते हैं.

   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

AGP के साथ C/C++ एएआर के उपभोक्ताओं और प्रोड्यूसर को कॉन्फ़िगर करने के तरीके के बारे में ज़्यादा जानने के लिए, 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 Gradle प्लगिन 7.1.0-alpha09 में, Android रिसॉर्स श्रिंकर के डिफ़ॉल्ट तौर पर लागू होने की सुविधा को अपडेट किया गया है. नए तरीके से, डाइनैमिक फ़ीचर वाले ऐप्लिकेशन को छोटा किया जा सकता है.

ऐप्लिकेशन के साइज़ को और कम करने के लिए एक्सपेरिमेंट करना

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

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

Android Gradle प्लगिन 8.0.0 में, पुराने तरीके को हटाने के लिए शेड्यूल किया गया है.

बिल्ड वैरिएंट पब्लिश करना

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

Javadoc JAR पब्लिश करना

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

सोर्स JAR पब्लिश करें

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

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

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

नेविगेशन सेफ़ आर्ग्युमेंट के साथ काम करने की सुविधा

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

इसके अलावा, Navigation 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 Publish प्लग इन का इस्तेमाल करना लेख पढ़ें.

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 देखें.