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

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

• Gradle 6.1.1. ज़्यादा जानकारी के लिए, Gradle को अपडेट करने के बारे में पढ़ें.

• एसडीके बिल्ड टूल 29.0.2 या इसके बाद का वर्शन.

नई सुविधाएं

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

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

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

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

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

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

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

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

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

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

• सीक्वेंशियल स्ट्रीम (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 पर निर्भर करता है. वहीं, :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 में फ़ीचर-ऑन-फ़ीचर डिपेंडेंसी की सुविधा चालू करें. ऐसा करने के लिए, मेन्यू बार में जाकर Help > Edit Custom VM Options पर क्लिक करें और यह शामिल करें. इससे, रन कॉन्फ़िगरेशन में बदलाव करते समय, इस सुविधा का इस्तेमाल किया जा सकेगा.

-Drundebug.feature.on.feature=true

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

Android Gradle प्लगिन 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
  }
}

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

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

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

हर डिपेंडेंसी, ज़्यादा से ज़्यादा एक 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 प्रोजेक्ट को CMAKE_FIND_ROOT_PATH{: .external} वैरिएबल के ज़रिए दिखती हैं. CMake को शुरू करने पर, Gradle इस वैल्यू को अपने-आप सेट कर देगा. इसलिए, अगर आपका बिल्ड सिस्टम इस वैरिएबल में बदलाव करता है, तो पक्का करें कि वह इसे असाइन करने के बजाय, इसमें जोड़ रहा हो.

हर डिपेंडेंसी, आपके CMake बिल्ड को एक config-file package{: .external} दिखाती है. इसे आप find_package{: .external} कमांड से इंपोर्ट करते हैं. यह कमांड, दिए गए पैकेज के नाम और वर्शन से मेल खाने वाले config-file पैकेज खोजता है. साथ ही, आपके बिल्ड में इस्तेमाल किए जाने वाले टारगेट को दिखाता है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन 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 का सैंपल{:.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 वाले प्रोजेक्ट में, नॉन-इंक्रीमेंटल एनोटेशन प्रोसेसर का इस्तेमाल करने पर, 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 प्लगिन के पिछले वर्शन में, 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'

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