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

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

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

• SDK Build Tools 29.0.2 या इसके बाद का वर्शन.

नई सुविधाएं

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

Android Studio के 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, डीसुगरिंग नाम की प्रोसेस के ज़रिए, 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 के लिए, छूटे हुए APIs उपलब्ध कराए जा सकें.

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

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

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 पैकेज फ़ॉर्मैट का इस्तेमाल करके एक्सपोर्ट किया जाता है.

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

आम तौर पर, पैकेज का नाम 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 पैकेज{: .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 के साथ अपने-आप लिंक कर देता है. साथ ही, इसे APK या ऐप्लिकेशन बंडल में libcurl.so कर देता है. ज़्यादा जानकारी के लिए, 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-ओनली प्रोजेक्ट में नॉन-इंक्रीमेंटल एनोटेशन प्रोसेसर का इस्तेमाल करने पर, इंक्रीमेंटल 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 प्लगइन के पिछले वर्शन में, आपको 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 में ठीक कर दिया जाएगा.