Android Gradle प्लग इन 4.0.0 (अप्रैल 2020)

Android प्लगिन के इस वर्शन के लिए, ये ज़रूरी शर्तें पूरी होनी चाहिए:

4.0.1 (जुलाई 2020)

इस छोटे से अपडेट में, Android 11 में पैकेज विज़िबिलिटी के लिए, नई डिफ़ॉल्ट सेटिंग और सुविधाओं के साथ काम करने की सुविधा जोड़ी गई है.

Android के पिछले वर्शन में, किसी डिवाइस पर इंस्टॉल किए गए सभी ऐप्लिकेशन की सूची देखी जा सकती थी. Android 11 (एपीआई लेवल 30) से, ऐप्लिकेशन के पास डिफ़ॉल्ट रूप से सिर्फ़ इंस्टॉल किए गए पैकेज की फ़िल्टर की गई सूची का ऐक्सेस होता है. सिस्टम पर ऐप्लिकेशन की पूरी सूची देखने के लिए, अब आपको अपने ऐप्लिकेशन या लाइब्रेरी के Android मेनिफ़ेस्ट में <queries> एलिमेंट जोड़ना होगा.

Android Gradle प्लग इन 4.1 और इसके बाद के वर्शन, नए <queries> के साथ पहले से ही काम करते हैं. हालांकि, पुराने वर्शन इसके साथ काम नहीं करते. अगर आपने <queries> एलिमेंट जोड़ा है या आपने Android 11 को टारगेट करने वाली किसी लाइब्रेरी या SDK टूल का इस्तेमाल शुरू किया है, तो ऐप्लिकेशन बनाते समय आपको मेनिफ़ेस्ट मर्ज करने से जुड़ी गड़बड़ियां दिख सकती हैं.

इस समस्या को हल करने के लिए, हम AGP 3.3 और इसके बाद के वर्शन के लिए पैच का एक सेट रिलीज़ कर रहे हैं. अगर AGP का पुराना वर्शन इस्तेमाल किया जा रहा है, तो इनमें से किसी एक वर्शन पर अपग्रेड करें:

कम से कम वर्शन डिफ़ॉल्ट वर्शन नोट
Gradle 6.1.1 6.1.1 ज़्यादा जानने के लिए, Gradle को अपडेट करना लेख पढ़ें.
एसडीके बिल्ड टूल 29.0.2 29.0.2 एसडीके बिल्ड टूल इंस्टॉल करें या कॉन्फ़िगर करें.

इस नई सुविधा के बारे में ज़्यादा जानने के लिए, Android 11 में पैकेज की जानकारी देखने की सुविधा देखें.

नई सुविधाएं

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

Android Studio के Build Analyzer के लिए सहायता

Build Analyzer विंडो से, आपको बिल्ड प्रोसेस से जुड़ी समस्याओं को समझने और उनका पता लगाने में मदद मिलती है. जैसे, ऑप्टिमाइज़ेशन बंद होना और टास्क को गलत तरीके से कॉन्फ़िगर करना. यह सुविधा तब उपलब्ध होती है, जब Android Studio 4.0 और उसके बाद के वर्शन के साथ Android Gradle प्लगिन 4.0.0 और उसके बाद के वर्शन का इस्तेमाल किया जाता है. Android Studio में Build Analyzer विंडो खोलने के लिए, यह तरीका अपनाएं:

  1. अगर आपने अब तक ऐसा नहीं किया है, तो मेन्यू बार में जाकर बनाएं > प्रोजेक्ट बनाएं को चुनें और अपना ऐप्लिकेशन बनाएं.
  2. मेन्यू बार में जाकर, व्यू > टूल विंडो > बिल्ड चुनें.
  3. बिल्ड विंडो में, बिल्ड ऐनलाइज़र विंडो को इनमें से किसी एक तरीके से खोलें:
    • Android Studio में प्रोजेक्ट बनाने की प्रोसेस पूरी होने के बाद, Build Analyzer टैब पर क्लिक करें.
    • Android Studio के प्रोजेक्ट बनाने के बाद, Build Output विंडो की दाईं ओर मौजूद लिंक पर क्लिक करें.

Build Analyzer विंडो, संभावित बिल्ड समस्याओं को बाईं ओर मौजूद ट्री में व्यवस्थित करती है. दाईं ओर मौजूद पैनल में, हर समस्या की जांच की जा सकती है. साथ ही, उसकी जानकारी देखने के लिए उस पर क्लिक किया जा सकता है. Android Studio, आपकी बिल्ड का विश्लेषण करता है. इस दौरान, वह उन टास्क के सेट का हिसाब लगाता है जिनसे बिल्ड की अवधि तय होती है. साथ ही, वह एक विज़ुअलाइज़ेशन उपलब्ध कराता है, ताकि आपको इन टास्क के असर को समझने में मदद मिल सके. चेतावनी नोड को बड़ा करके, चेतावनियों के बारे में जानकारी भी देखी जा सकती है.

ज़्यादा जानने के लिए, बिल्ड की स्पीड में होने वाली गिरावट की पहचान करना लेख पढ़ें.

D8 और R8 में Java 8 लाइब्रेरी का डिसुगरिंग

Android Gradle प्लगिन में अब Java 8 की कई भाषाओं के एपीआई इस्तेमाल करने की सुविधा शामिल है. इसके लिए, आपके ऐप्लिकेशन के लिए कम से कम एपीआई लेवल की ज़रूरत नहीं होती.

Android Studio 3.0 और इसके बाद के वर्शन में, DEX कंपाइलर D8, desugaring नाम की प्रोसेस के ज़रिए, Java 8 की भाषा से जुड़ी सुविधाओं के लिए पहले से ही काफ़ी सपोर्ट उपलब्ध कराता है. जैसे, लैम्ब्डा एक्सप्रेशन, डिफ़ॉल्ट इंटरफ़ेस के तरीके, संसाधनों के साथ कोशिश करना वगैरह. Android Studio 4.0 में, डिसुगरिंग इंजन को इस तरह से बढ़ाया गया है कि वह Java लैंग्वेज एपीआई को डिसुगर कर सके. इसका मतलब है कि अब Android के पुराने वर्शन पर काम करने वाले ऐप्लिकेशन में, स्टैंडर्ड लैंग्वेज एपीआई शामिल किए जा सकते हैं. ये एपीआई, Android के हाल ही के वर्शन में ही उपलब्ध थे. जैसे, java.util.streams.

इस रिलीज़ में, एपीआई के इस सेट का इस्तेमाल किया जा सकता है:

  • सीक्वेंशियल स्ट्रीम (java.util.stream)
  • java.time का सबसेट
  • java.util.function
  • java.util.{Map,Collection,Comparator} में हाल ही में जोड़े गए वीडियो
  • ज़रूरी नहीं (java.util.Optional, java.util.OptionalInt, और java.util.OptionalDouble) और ऊपर दिए गए एपीआई के साथ काम आने वाली कुछ अन्य नई क्लास
  • java.util.concurrent.atomic में कुछ नई सुविधाएं जोड़ी गई हैं. जैसे, AtomicInteger, AtomicLong, और AtomicReference पर नए तरीके
  • ConcurrentHashMap (Android 5.0 के लिए गड़बड़ियां ठीक की गई हैं)

इन भाषा एपीआई के साथ काम करने के लिए, D8 एक अलग लाइब्रेरी DEX फ़ाइल कंपाइल करता है. इसमें, मौजूद न होने वाले एपीआई को लागू करने का तरीका शामिल होता है. साथ ही, इसे आपके ऐप्लिकेशन में शामिल किया जाता है. डिसुगरिंग की प्रोसेस, आपके ऐप्लिकेशन के कोड को फिर से लिखती है, ताकि रनटाइम में इस लाइब्रेरी का इस्तेमाल किया जा सके.

इन लैंग्वेज एपीआई के साथ काम करने की सुविधा चालू करने के लिए, अपने ऐप्लिकेशन मॉड्यूल की build.gradle फ़ाइल में यह कोड शामिल करें:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }



compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}



dependencies {
  coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}
 
android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }



compileOptions {
    // Flag to enable support for the new language APIs
    isCoreLibraryDesugaringEnabled = true
    // Sets Java compatibility to Java 8
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}



dependencies {
  coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4")
}

ध्यान दें कि आपको ऊपर दिए गए कोड स्निपेट को लाइब्रेरी मॉड्यूल की build.gradle फ़ाइल में भी शामिल करना पड़ सकता है. ऐसा तब होता है, जब

  • लाइब्रेरी मॉड्यूल के इंस्ट्रुमेंटेड टेस्ट, इन भाषा एपीआई का इस्तेमाल करते हैं. ये एपीआई, सीधे तौर पर या लाइब्रेरी मॉड्यूल या उसकी डिपेंडेंसी के ज़रिए इस्तेमाल किए जाते हैं. ऐसा इसलिए किया जाता है, ताकि आपके इंस्ट्रुमेंटेड टेस्ट APK के लिए, छूटे हुए एपीआई उपलब्ध कराए जा सकें.

  • आपको लाइब्रेरी मॉड्यूल पर अलग से लिंट चलाना हो. इससे लिंट को भाषा के एपीआई के मान्य इस्तेमाल की पहचान करने में मदद मिलती है. साथ ही, इससे गलत चेतावनियां देने से बचा जा सकता है.

बिल्ड की सुविधाओं को चालू या बंद करने के नए विकल्प

Android Gradle प्लग इन 4.0.0 में, यह कंट्रोल करने का नया तरीका पेश किया गया है कि आपको कौनसी बिल्ड सुविधाएं चालू और बंद करनी हैं. जैसे, व्यू बाइंडिंग और डेटा बाइंडिंग. नई सुविधाएं जोड़े जाने पर, वे डिफ़ॉल्ट रूप से बंद रहेंगी. इसके बाद, buildFeatures ब्लॉक का इस्तेमाल करके, सिर्फ़ उन सुविधाओं को चालू किया जा सकता है जिनकी आपको ज़रूरत है. इससे आपको अपने प्रोजेक्ट के लिए, बिल्ड की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने में मदद मिलती है. मॉड्यूल-लेवल की build.gradle फ़ाइल में, हर मॉड्यूल के लिए ये विकल्प सेट किए जा सकते हैं:

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}
 
android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

प्रोजेक्ट के सभी मॉड्यूल में इन सुविधाओं के लिए डिफ़ॉल्ट सेटिंग भी तय की जा सकती है. इसके लिए, आपको अपने प्रोजेक्ट की gradle.properties फ़ाइल में इनमें से एक या इससे ज़्यादा सेटिंग शामिल करनी होंगी. यहां इसका उदाहरण दिया गया है. ध्यान रखें कि इन प्रोजेक्ट-वाइड डिफ़ॉल्ट सेटिंग को बदलने के लिए, मॉड्यूल-लेवल की build.gradle फ़ाइल में buildFeatures ब्लॉक का इस्तेमाल किया जा सकता है.

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true

एक सुविधा के लिए दूसरी सुविधा पर निर्भरता

Android Gradle प्लगइन के पिछले वर्शन में, सभी फ़ीचर मॉड्यूल सिर्फ़ ऐप्लिकेशन के बेस मॉड्यूल पर निर्भर हो सकते थे. Android Gradle प्लग इन 4.0.0 का इस्तेमाल करते समय, अब एक ऐसा फ़ीचर मॉड्यूल शामिल किया जा सकता है जो किसी दूसरे फ़ीचर मॉड्यूल पर निर्भर करता है. इसका मतलब है कि :video सुविधा, :camera सुविधा पर निर्भर हो सकती है. वहीं, :camera सुविधा, बुनियादी सुविधाओं के मॉड्यूल पर निर्भर होती है. इसे नीचे दिए गए डायग्राम में दिखाया गया है.

सुविधाओं के बीच निर्भरता

सुविधा मॉड्यूल :video, सुविधा :camera पर निर्भर करता है. वहीं, सुविधा :camera, बुनियादी :app मॉड्यूल पर निर्भर करती है.

इसका मतलब है कि जब आपका ऐप्लिकेशन किसी फ़ीचर मॉड्यूल को डाउनलोड करने का अनुरोध करता है, तो वह उन अन्य फ़ीचर मॉड्यूल को भी डाउनलोड करता है जिन पर वह निर्भर करता है. अपने ऐप्लिकेशन के लिए सुविधा वाले मॉड्यूल बनाने के बाद, मॉड्यूल की build.gradle फ़ाइल में, सुविधा-ऑन-सुविधा वाली डिपेंडेंसी का एलान किया जा सकता है. उदाहरण के लिए, :video मॉड्यूल, :camera पर इस तरह से निर्भरता का एलान करता है:

// In the build.gradle file of the ':video' module.
dependencies {
  // All feature modules must declare a dependency
  // on the base module.
  implementation project(':app')
  // Declares that this module also depends on the 'camera'
  // feature module.
  implementation project(':camera')
  ...
}
 
// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

इसके अलावा, आपको Android Studio में सुविधा-पर-सुविधा निर्भरता वाली सुविधा चालू करनी चाहिए. इससे, रन कॉन्फ़िगरेशन में बदलाव करते समय सुविधा का इस्तेमाल किया जा सकेगा. उदाहरण के लिए, मेन्यू बार में सहायता > कस्टम वीएम विकल्प में बदलाव करें पर क्लिक करके, सुविधा-पर-सुविधा निर्भरता वाली सुविधा चालू करें. साथ ही, इसमें ये शामिल करें:

-Drundebug.feature.on.feature=true

डिपेंडेंसी का मेटाडेटा

Android Gradle plugin 4.0.0 और इसके बाद के वर्शन का इस्तेमाल करके ऐप्लिकेशन बनाते समय, प्लगिन में ऐसा मेटाडेटा शामिल होता है जो आपके ऐप्लिकेशन में कंपाइल की गई डिपेंडेंसी के बारे में बताता है. ऐप्लिकेशन अपलोड करते समय, Play Console इस मेटाडेटा की जांच करता है, ताकि आपको ये फ़ायदे मिल सकें:

  • आपके ऐप्लिकेशन में इस्तेमाल किए गए एसडीके और डिपेंडेंसी से जुड़ी जानी-पहचानी समस्याओं के बारे में सूचनाएं पाना
  • उन समस्याओं को हल करने के लिए, कार्रवाई करने लायक सुझाव/राय पाएं

डेटा को कंप्रेस किया जाता है. साथ ही, Google Play की साइनिंग कुंजी से एन्क्रिप्ट (सुरक्षित) किया जाता है. इसके बाद, इसे रिलीज़ किए जाने वाले ऐप्लिकेशन के साइनिंग ब्लॉक में सेव किया जाता है. हालांकि, इस मेटाडेटा की जांच खुद की जा सकती है. इसके लिए, आपको इंटरमीडिएट बिल्ड फ़ाइलों को इस डायरेक्ट्री में देखना होगा: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

अगर आपको यह जानकारी शेयर नहीं करनी है, तो ऑप्ट-आउट किया जा सकता है. इसके लिए, आपको अपने मॉड्यूल की build.gradle फ़ाइल में यह जानकारी शामिल करनी होगी:

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}
 
android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

एएआर डिपेंडेंसी से नेटिव लाइब्रेरी इंपोर्ट करना

अब अपने ऐप्लिकेशन की एएआर डिपेंडेंसी से, C/C++ लाइब्रेरी इंपोर्ट की जा सकती हैं. नीचे दिए गए कॉन्फ़िगरेशन के चरणों को पूरा करने पर, Gradle इन नेटिव लाइब्रेरी को आपके बाहरी नेटिव बिल्ड सिस्टम, जैसे कि CMake के साथ इस्तेमाल करने के लिए अपने-आप उपलब्ध कराता है. ध्यान दें कि Gradle सिर्फ़ इन लाइब्रेरी को आपकी बिल्ड के लिए उपलब्ध कराता है. इनका इस्तेमाल करने के लिए, आपको अपनी बिल्ड स्क्रिप्ट कॉन्फ़िगर करनी होंगी.

लाइब्रेरी को Prefab पैकेज फ़ॉर्मैट का इस्तेमाल करके एक्सपोर्ट किया जाता है.

हर डिपेंडेंसी ज़्यादा से ज़्यादा एक प्रीफ़ैब पैकेज दिखा सकती है. इसमें एक या उससे ज़्यादा मॉड्यूल शामिल होते हैं. Prefab मॉड्यूल एक लाइब्रेरी होती है. यह शेयर की गई, स्टैटिक या सिर्फ़ हेडर वाली लाइब्रेरी हो सकती है.

आम तौर पर, पैकेज का नाम Maven आर्टफ़ैक्ट के नाम और मॉड्यूल के नाम से मेल खाता है. साथ ही, मॉड्यूल का नाम लाइब्रेरी के नाम से मेल खाता है. हालांकि, ऐसा हमेशा नहीं होता. लाइब्रेरी के पैकेज और मॉड्यूल का नाम जानने के लिए, आपको डिपेंडेंसी के दस्तावेज़ देखने पड़ सकते हैं.

बाहरी नेटिव बिल्ड सिस्टम को कॉन्फ़िगर करना

आपको जो तरीका अपनाना है उसे देखने के लिए, यहां दिए गए चरणों का पालन करें. ये चरण, इस्तेमाल किए जाने वाले बाहरी नेटिव बिल्ड सिस्टम के लिए हैं.

आपके ऐप्लिकेशन की हर AAR डिपेंडेंसी में नेटिव कोड शामिल होता है. यह एक Android.mk फ़ाइल दिखाता है, जिसे आपको अपने ndk-build प्रोजेक्ट में इंपोर्ट करना होता है. import&endash;module कमांड का इस्तेमाल करके, इस फ़ाइल को इंपोर्ट किया जाता है. यह कमांड, उन पाथ को खोजती है जिन्हें आपने ndk-build प्रोजेक्ट में import&endash;add&endash;path प्रॉपर्टी का इस्तेमाल करके तय किया है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन libapp.so को परिभाषित करता है और यह curl का इस्तेमाल करता है, तो आपको अपनी Android.mk फ़ाइल में यह शामिल करना चाहिए:

  1. CMake के लिए:

    add_library(app SHARED app.cpp)
    


    # Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)

  2. ndk-build के लिए:

    include $(CLEAR_VARS)
LOCAL_MODULE := libapp
LOCAL_SRC_FILES := app.cpp
# Link libcurl from the curl AAR.
LOCAL_SHARED_LIBRARIES := curl
include $(BUILD_SHARED_LIBRARY)
    


    # If you don't expect that your project will be built using versions of the NDK
# older than r21, you can omit this block.
ifneq ($(call ndk-major-at-least,21),true)
    $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH))
endif
    


    # Import all modules that are included in the curl AAR.
$(call import-module,prefab/curl)

AAR में शामिल नेटिव डिपेंडेंसी, CMAKE_FIND_ROOT_PATH{: .external} वैरिएबल के ज़रिए आपके CMake प्रोजेक्ट के लिए उपलब्ध कराई जाती हैं. CMake को शुरू करने पर, Gradle इस वैल्यू को अपने-आप सेट कर देगा. इसलिए, अगर आपका बिल्ड सिस्टम इस वैरिएबल में बदलाव करता है, तो इसे असाइन करने के बजाय इसमें जोड़ें.

हर डिपेंडेंसी, आपके CMake बिल्ड के लिए config-file पैकेज{: .external} उपलब्ध कराती है. इसे find_package{: .external} कमांड की मदद से इंपोर्ट किया जाता है. यह कमांड, दिए गए पैकेज के नाम और वर्शन से मेल खाने वाले config-file पैकेज खोजती है. साथ ही, उन टारगेट को दिखाती है जिन्हें यह आपकी बिल्ड में इस्तेमाल करने के लिए तय करता है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन libapp.so को तय करता है और curl का इस्तेमाल करता है, तो आपको अपनी libapp.so फ़ाइल में यह शामिल करना चाहिए:CMakeLists.txt


add_library(app SHARED app.cpp)



# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)

अब app.cpp में #include "curl/curl.h" की जानकारी दी जा सकती है. प्रोजेक्ट बनाने के दौरान, आपका बाहरी नेटिव बिल्ड सिस्टम, libapp.so को libcurl.so के साथ अपने-आप लिंक कर देता है. साथ ही, libcurl.so को APK या ऐप्लिकेशन बंडल में पैकेज कर देता है. ज़्यादा जानकारी के लिए, curl प्रीफ़ैब का सैंपल{:.external} देखें.

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

इस प्लगिन के इस वर्शन का इस्तेमाल करने पर, आपको व्यवहार में ये बदलाव दिख सकते हैं.

v1/v2 के साइनिंग कॉन्फ़िगरेशन से जुड़े अपडेट

signingConfig ब्लॉक में, ऐप्लिकेशन पर हस्ताक्षर करने के कॉन्फ़िगरेशन का तरीका बदल गया है. अब यह इस तरह काम करेगा:

v1 साइनिंग

  • अगर v1SigningEnabled को साफ़ तौर पर चालू किया गया है, तो AGP, v1 ऐप्लिकेशन साइनिंग करता है.
  • अगर उपयोगकर्ता ने v1SigningEnabled को साफ़ तौर पर बंद किया है, तो v1 ऐप्लिकेशन पर हस्ताक्षर करने की सुविधा काम नहीं करेगी.
  • अगर उपयोगकर्ता ने v1 पर हस्ताक्षर करने की सुविधा को साफ़ तौर पर चालू नहीं किया है, तो minSdk और targetSdk के आधार पर इसे अपने-आप बंद किया जा सकता है.

v2 साइनिंग

  • अगर v2SigningEnabled को साफ़ तौर पर चालू किया जाता है, तो AGP, v2 ऐप्लिकेशन साइनिंग करता है.
  • अगर उपयोगकर्ता ने v2SigningEnabled को साफ़ तौर पर बंद किया है, तो v2 ऐप्लिकेशन साइनिंग नहीं की जाती है.
  • अगर उपयोगकर्ता ने v2 पर हस्ताक्षर करने की सुविधा को साफ़ तौर पर चालू नहीं किया है, तो targetSdk के आधार पर इसे अपने-आप बंद किया जा सकता है.

इन बदलावों की मदद से, AGP बिल्ड को ऑप्टिमाइज़ कर सकता है. इसके लिए, वह साइनिंग मैकेनिज़्म को बंद कर सकता है. ऐसा इस आधार पर किया जाता है कि उपयोगकर्ता ने इन फ़्लैग को साफ़ तौर पर चालू किया है या नहीं. इस रिलीज़ से पहले, v1Signing को साफ़ तौर पर चालू किए जाने के बावजूद बंद किया जा सकता था. इससे भ्रम की स्थिति पैदा हो सकती थी.

feature और instantapp Android Gradle प्लग इन हटा दिए गए हैं

Android Gradle प्लग इन 3.6.0 ने, फ़ीचर प्लग इन (com.android.feature) और झटपट ऐप्लिकेशन प्लग इन (com.android.instantapp) को बंद कर दिया है. अब Android ऐप्लिकेशन बंडल का इस्तेमाल करके, झटपट ऐप्लिकेशन बनाने और उन्हें पैकेज करने के लिए, डाइनैमिक फ़ीचर प्लग इन (com.android.dynamic-feature) का इस्तेमाल किया जा सकता है.

Android Gradle प्लग इन 4.0.0 और इसके बाद के वर्शन में, इन बंद किए गए प्लग इन को पूरी तरह से हटा दिया गया है. इसलिए, Android Gradle प्लगिन के नए वर्शन का इस्तेमाल करने के लिए, आपको अपने झटपट ऐप्लिकेशन को Android ऐप्लिकेशन बंडल के साथ काम करने वाले वर्शन पर माइग्रेट करना होगा. झटपट इस्तेमाल किए जा सकने वाले ऐप्लिकेशन को माइग्रेट करके, ऐप्लिकेशन बंडल के फ़ायदे पाए जा सकते हैं. साथ ही, अपने ऐप्लिकेशन के मॉड्यूलर डिज़ाइन को आसान बनाया जा सकता है.

ध्यान दें: Android Studio 4.0 और इसके बाद के वर्शन में, हटाए गए प्लग इन का इस्तेमाल करने वाले प्रोजेक्ट खोलने के लिए, प्रोजेक्ट में Android Gradle प्लग इन 3.6.0 या इससे पहले का वर्शन इस्तेमाल किया जाना चाहिए.

एनोटेशन को अलग से प्रोसेस करने की सुविधा हटा दी गई है

एनोटेशन प्रोसेस करने के लिए, अलग से टास्क बनाने की सुविधा हटा दी गई है. इस विकल्प का इस्तेमाल, Java-only प्रोजेक्ट में नॉन-इंक्रीमेंटल एनोटेशन प्रोसेसर का इस्तेमाल करते समय, इंक्रीमेंटल Java कंपाइलेशन को बनाए रखने के लिए किया जाता था. इसे gradle.properties फ़ाइल में android.enableSeparateAnnotationProcessing को true पर सेट करके चालू किया जाता था. हालांकि, अब यह काम नहीं करता.

इसके बजाय, आपको इंक्रीमेंटल एनोटेशन प्रोसेसर का इस्तेमाल करना चाहिए, ताकि बिल्ड की परफ़ॉर्मेंस को बेहतर बनाया जा सके.

includeCompileClasspath का अब इस्तेमाल नहीं किया जा सकता

Android Gradle प्लगइन अब कंपाइल क्लासपाथ पर घोषित किए गए एनोटेशन प्रोसेसर की जांच नहीं करता है और न ही उन्हें शामिल करता है. साथ ही, annotationProcessorOptions.includeCompileClasspath डीएसएल प्रॉपर्टी का अब कोई असर नहीं पड़ता. अगर आपने कंपाइल क्लासपाथ में एनोटेशन प्रोसेसर शामिल किए हैं, तो आपको यह गड़बड़ी दिख सकती है:

Error: Annotation processors must be explicitly declared now.

इस समस्या को हल करने के लिए, आपको annotationProcessor डिपेंडेंसी कॉन्फ़िगरेशन का इस्तेमाल करके, अपने build.gradle फ़ाइलों में एनोटेशन प्रोसेसर शामिल करने होंगे. ज़्यादा जानने के लिए, एनोटेशन प्रोसेसर जोड़ना लेख पढ़ें.

CMake की ओर से इस्तेमाल की जाने वाली, पहले से बनी डिपेंडेंसी की ऑटोमैटिक पैकेजिंग

Android Gradle प्लगइन के पिछले वर्शन में, आपको CMake के बाहरी नेटिव बिल्ड में इस्तेमाल की गई किसी भी पहले से बनी लाइब्रेरी को साफ़ तौर पर पैकेज करना होता था. इसके लिए, आपको jniLibs का इस्तेमाल करना होता था. ऐसा हो सकता है कि आपकी लाइब्रेरी, आपके मॉड्यूल की src/main/jniLibs डायरेक्ट्री में मौजूद हो. इसके अलावा, यह भी हो सकता है कि वह build.gradle फ़ाइल में कॉन्फ़िगर की गई किसी अन्य डायरेक्ट्री में मौजूद हो:

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.srcDirs = ['libs']
  }
}
 
sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.setSrcDirs(listOf("libs"))
  }
}

Android Gradle प्लग इन 4.0 के साथ, ऊपर दिया गया कॉन्फ़िगरेशन अब ज़रूरी नहीं है. इससे बिल्ड नहीं हो पाएगा:

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
  > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
    > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

External native build अब उन लाइब्रेरी को अपने-आप पैकेज करता है. इसलिए, लाइब्रेरी को jniLibs के साथ पैकेज करने पर डुप्लीकेट बन जाता है. बिल्ड से जुड़ी गड़बड़ी से बचने के लिए, पहले से बनी लाइब्रेरी को jniLibs से बाहर किसी दूसरी जगह पर ले जाएं या अपनी build.gradle फ़ाइल से jniLibs कॉन्फ़िगरेशन हटाएं.

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

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

Gradle वर्कर मैकेनिज़्म में रेस कंडीशन

Android Gradle प्लग इन 4.0 में हुए बदलावों की वजह से, Gradle में रेस कंडीशन ट्रिगर हो सकती है. ऐसा तब होता है, जब &endash;&endash;no&endash;daemon और Gradle 6.3 या इससे पहले के वर्शन का इस्तेमाल किया जा रहा हो. इसकी वजह से, बिल्ड पूरा होने के बाद बिल्ड हैंग हो जाते हैं.

इस समस्या को Gradle 6.4 में ठीक कर दिया जाएगा.