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

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

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

Lint analysis task को अब कैश मेमोरी में सेव किया जा सकता है

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

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

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

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

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

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

• उपयोग करने वाले मॉड्यूल को build.gradle फ़ाइल में prefab चालू करना होगा.

android {
  buildFeatures {
    prefab true
  }
}

• publishing मॉड्यूल में, 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 के साथ नेटिव 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 Gradle प्लग इन 7.1.0-alpha09 में, Android रिसॉर्स श्रिंकर के डिफ़ॉल्ट तरीके को अपडेट किया गया है. नए तरीके से लागू करने पर, डाइनैमिक फ़ीचर वाले ऐप्लिकेशन का साइज़ कम किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

सिमैंटिक में बदलाव की वजह से लिंट ब्लॉक किया गया

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

नेविगेशन के लिए Safe Args की सुविधा के साथ काम करने वाली लाइब्रेरी

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 Performance Monitoring Gradle प्लगिन के 1.4.0 और इससे पहले के वर्शन के साथ काम नहीं करता. AGP अपग्रेड असिस्टेंट, प्लगिन को 1.4.1 वर्शन पर अपने-आप अपडेट नहीं करेगा. इसलिए, अगर firebase-perf का इस्तेमाल किया जा रहा है और आपको AGP को 7.1 पर अपग्रेड करना है, तो आपको यह अपग्रेड मैन्युअल तरीके से करना होगा.

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

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

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

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

इस समस्या को 7.1.1 वर्शन में ठीक कर दिया जाएगा. समस्या #213534628 देखें.