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 को अपडेट करना लेख पढ़ें.
SDK टूल के लिए बिल्ड टूल 29.0.2 29.0.2 SDK Build Tools को इंस्टॉल या कॉन्फ़िगर करें.

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

नई सुविधाएं

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

Android Studio के बिल्ड विश्लेषक के लिए सहायता

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

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

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

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

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

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

Android Studio के 3.0 और इसके बाद के वर्शन में, DEX कंपाइलर D8 ने डिसगैरिंग नाम की प्रोसेस के ज़रिए, 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 सुविधा पर निर्भर हो सकती है. यह सुविधा, बुनियादी मॉड्यूल पर निर्भर करती है, जैसा कि नीचे दिए गए चित्र में दिखाया गया है.

सुविधाओं की डिपेंडेंसी

सुविधाओं का मॉड्यूल :video, सुविधाओं के मॉड्यूल :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 में, एक सुविधा पर दूसरी सुविधा की निर्भरता की सुविधा चालू करनी चाहिए. उदाहरण के लिए, रन कॉन्फ़िगरेशन में बदलाव करते समय इस सुविधा का इस्तेमाल किया जा सकता है. इसके लिए, मेन्यू बार में जाकर सहायता > कस्टम VM के विकल्पों में बदलाव करें पर क्लिक करें. साथ ही, इन चीज़ों को शामिल करें:

-Drundebug.feature.on.feature=true

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

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

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

डेटा को 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
  }
}

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

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

लाइब्रेरी, 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 package{: .external} दिखाती है. इसे find_package{: .external} कमांड की मदद से इंपोर्ट किया जाता है. यह कमांड, दिए गए पैकेज के नाम और वर्शन से मैच करने वाले कॉन्फ़िगरेशन फ़ाइल वाले पैकेज खोजता है. साथ ही, उन टारगेट को दिखाता है जिन्हें आपके बिल्ड में इस्तेमाल करने के लिए तय किया गया है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन libapp.so को परिभाषित करता है और वह curl का इस्तेमाल करता है, तो आपको अपनी 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 से अपने-आप लिंक कर देता है. साथ ही, APK या ऐप्लिकेशन बंडल में libcurl.so को पैकेज कर देता है. ज़्यादा जानकारी के लिए, curl prefab sample{:.external} देखें.

उपयोगकर्ता के व्यवहार में बदलाव

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

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

signingConfig ब्लॉक में, ऐप्लिकेशन साइनिंग कॉन्फ़िगरेशन के व्यवहार में ये बदलाव हुए हैं:

v1 साइनिंग

  • अगर v1SigningEnabled साफ़ तौर पर चालू है, तो AGP, ऐप्लिकेशन साइनिंग के वर्शन 1 का इस्तेमाल करता है.
  • अगर उपयोगकर्ता ने 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 प्रोजेक्ट में एनोटेशन प्रोसेसर के इस्तेमाल के दौरान, इंक्रीमेंटल Java कंपाइलेशन को बनाए रखने के लिए किया जाता था. इसे चालू करने के लिए, gradle.properties फ़ाइल में android.enableSeparateAnnotationProcessing को true पर सेट किया जाता था. हालांकि, यह विकल्प अब काम नहीं करता.

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

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

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

Error: Annotation processors must be explicitly declared now.

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

CMake का इस्तेमाल करने वाली, पहले से बनी डिपेंडेंसी को अपने-आप पैकेज करना

Android Gradle प्लग इन के पुराने वर्शन के लिए ज़रूरी था कि आप jniLibs का इस्तेमाल करके, CMake के बाहरी नेटिव बिल्ड में इस्तेमाल की जाने वाली पहले से बनी लाइब्रेरी को साफ़ तौर पर पैकेज करें. आपके मॉड्यूल की 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'

बाहरी नेटिव बिल्ड अब उन लाइब्रेरी को अपने-आप पैकेज करता है. इसलिए, 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 में ठीक कर दी जाएगी.