Android Gradle प्लग इन 3.0.0 (अक्टूबर 2017)

'Android Gradle प्लग इन 3.0.0' में कई तरह के बदलाव शामिल हैं जिनका मकसद बड़े प्रोजेक्ट की परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करने के लिए किया जाता है.

उदाहरण के लिए, स्केलेटन का सैंपल प्रोजेक्ट, जिसमें ~130 मॉड्यूल और कई बाहरी डिपेंडेंसी शामिल हैं (इसमें कोई कोड या रिसॉर्स नहीं है), लेकिन परफ़ॉर्मेंस बेहतर हो सकती है इनसे मिलता-जुलता:

इनमें से कुछ बदलाव मौजूदा बिल्ड में गड़बड़ी करते हैं. इसलिए, आपको
तो माइग्रेशन की प्रोसेस पूरी हो जाएगी.

अगर आपको परफ़ॉर्मेंस में ऊपर बताए गए सुधार नहीं दिख रहे हैं, तो कृपया गड़बड़ी की शिकायत करें और उसका इस्तेमाल करके अपने बिल्ड का ट्रेस शामिल करें Gredle प्रोफ़ाइलर.

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

• Gredle 4.1 या उससे ज़्यादा. इस बारे में ज़्यादा जानने के लिए, Gredle को अपडेट किया जा रहा है.
• टूल 26.0.2 या उससे ज़्यादा. इस अपडेट के बाद, अब आपको बिल्ड टूल—प्लग इन डिफ़ॉल्ट रूप से ज़रूरी वर्शन के कम से कम वर्शन का इस्तेमाल करता है. इसलिए, अब android.buildToolsVersion प्रॉपर्टी को हटाया जा सकता है.

ऑप्टिमाइज़ेशन

• बेहतरीन तरीके से, मल्टी-मॉड्यूल प्रोजेक्ट के लिए बेहतर समानता टास्क ग्राफ़.
• डिपेंडेंसी में बदलाव करते समय, Gradle, तेज़ी से बिल्ड करता है ऐसे मॉड्यूल को फिर से कंपाइल करना जिन्हें उस डिपेंडेंसी के एपीआई का ऐक्सेस नहीं है. आपको यह तय करना चाहिए कि कौनसी डिपेंडेंसी अपने एपीआई को अन्य मॉड्यूल में लीक करती हैं इस्तेमाल किया जा रहा है Gradle के नए डिपेंडेंसी कॉन्फ़िगरेशन: implementation, api, compileOnly, और runtimeOnly.
• हर क्लास के हिसाब से डेक्सिंग की वजह से, बिल्ड की स्पीड तेज़ी से बढ़ती है. हर क्लास अब अलग-अलग DEX फ़ाइलों में कंपाइल किया जाता है और सिर्फ़ उन क्लास को किए गए बदलाव फिर से दिखाए जाते हैं. आपको इसके लिए बिल्ड की स्पीड में सुधार करना होगा ऐसे ऐप्लिकेशन जो minSdkVersion को 20 या उससे कम पर सेट करते हैं और लेगसी मल्टी-डेक्स.
• बिल्ड की स्पीड को बेहतर बनाया गया है. इसके लिए, कुछ टास्क को ऑप्टिमाइज़ करके चाच वाले आउटपुट का इस्तेमाल किया जाता है. इस ऑप्टिमाइज़ेशन का फ़ायदा पाने के लिए, Gredle बिल्ड कैश चालू करें.
• AAPT2 का इस्तेमाल करके, इंक्रीमेंटल रिसॉर्स प्रोसेसिंग को बेहतर बनाया गया है. डिफ़ॉल्ट रूप से चालू रहता है. अगर आपको AAPT2 इस्तेमाल करते समय कोई समस्या आ रही है, कृपया गड़बड़ी की शिकायत करें. आप यह भी कर सकते हैं अपनेandroid.enableAapt2=false gradle.properties फ़ाइल और इसके हिसाब से Gradle डीमन को रीस्टार्ट करना ./gradlew --stop को कमांड लाइन से चला रही है.

नई सुविधाएं

• वैरिएंट अवेयर डिपेंडेंसी मैनेजमेंट. मॉड्यूल का कोई खास वैरिएंट बनाते समय, अब प्लगिन लोकल लाइब्रेरी मॉड्यूल डिपेंडेंसी के वैरिएंट से अपने-आप .
• इसमें काम करने के लिए एक नया फ़ीचर मॉड्यूल प्लगिन शामिल किया गया है Android Instant Apps और Android Instant Apps का SDK टूल (जिसे डाउनलोड किया जा सकता है) एसडीके मैनेजर का इस्तेमाल करके). नए प्लग इन की मदद से फ़ीचर मॉड्यूल बनाने के बारे में ज़्यादा जानने के लिए, पढ़ें किसी स्ट्रक्चर का स्ट्रक्चर कई सुविधाओं वाला इंस्टैंट ऐप्लिकेशन.
• कुछ Java 8 भाषा सुविधाओं और Java 8 के उपयोग के लिए अंतर्निहित समर्थन लाइब्रेरी. Jack को अब बंद कर दिया गया है और अब इसकी ज़रूरत नहीं है, और आप को पहले जैक को अक्षम करना चाहिए, ताकि डिफ़ॉल्ट टूलचेन. ज़्यादा जानकारी के लिए, पढ़ें Java 8 भाषा की सुविधाओं का इस्तेमाल करें.

• इसके साथ टेस्ट चलाने के लिए सहायता जोड़ी गई Android टेस्ट ऑर्केस्ट्रेटर की मदद से, ऐप्लिकेशन के हर टेस्ट को इंस्ट्रुमेंटेशन को खुद शुरू करने की कोशिश कर रहा है. ऐसा इसलिए, क्योंकि हर जांच अपने-आप होती है इंस्ट्रुमेंटेशन इंस्टेंस, टेस्ट के बीच शेयर की गई कोई भी स्थिति इकट्ठा नहीं होती आपके डिवाइस के सीपीयू या मेमोरी पर काम करता है. साथ ही, अगर कोई टेस्ट क्रैश हो जाता है, तब भी उसे इंस्ट्रुमेंटेशन का सिर्फ़ अपना इंस्टेंस होता है, ताकि आपके दूसरे टेस्ट अब भी चलते रहें.

  • इस्तेमाल करने या न करने के बारे में तय करने के लिए, testOptions.execution को जोड़ा गया डिवाइस पर टेस्ट ऑर्केस्ट्रेशन. अगर आपको इस्तेमाल करें Android Test ऑर्केस्ट्रार के साथ काम करता है, तो आपको ANDROID_TEST_ORCHESTRATOR, जैसा कि नीचे दिखाया गया है. डिफ़ॉल्ट रूप से, यह प्रॉपर्टी को HOST पर सेट किया गया है. इससे डिवाइस पर ऐक्सेस बंद हो जाएगा और यह टेस्ट चलाने का स्टैंडर्ड तरीका है.

  ग्रूवी

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

• androidTestUtil के नए डिपेंडेंसी कॉन्फ़िगरेशन की मदद से, ये काम किए जा सकते हैं अपने इंस्ट्रुमेंटेशन टेस्ट चलाने से पहले, दूसरा टेस्ट हेल्पर APK इंस्टॉल करें, जैसे, Android Test Orchestrator:

  ग्रूवी

          dependencies {
            androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
            ...
          }
          

  Kotlin

          dependencies {
            androidTestUtil("com.android.support.test:orchestrator:1.0.0")
            ...
          }
          

• testOptions.unitTests.includeAndroidResources को इसमें जोड़ा गया में ऐसी सहायता यूनिट की जांच की सुविधा मिलती है जिसके लिए Android के संसाधनों की ज़रूरत होती है, जैसे कि रोबोइलेक्ट्रिक. इसे कब सेट किया जाता है प्रॉपर्टी को true प्रॉपर्टी के साथ जोड़ा जाता है, तो प्लग इन संसाधन, एसेट, और मेनिफ़ेस्ट मर्ज करना हो. इसके बाद, आपकी जांच से com/android/tools/test_config.properties की जांच करें नीचे दी गई कुंजियों के लिए क्लासपाथ इस्तेमाल करें:

  • android_merged_assets: इसका ऐब्सलूट पाथ मर्ज की गई ऐसेट डायरेक्ट्री.

    ध्यान दें: लाइब्रेरी मॉड्यूल के लिए, मर्ज की गई ऐसेट इसमें डिपेंडेंसी की एसेट शामिल नहीं हैं (देखें समस्या #65550419) है.

  • android_merged_manifest: इसका ऐब्सलूट पाथ मर्ज की गई मेनिफ़ेस्ट फ़ाइल.

  • android_merged_resources: इसका ऐब्सलूट पाथ मर्ज की गई रिसॉर्स डायरेक्ट्री, जिसमें से सभी संसाधन होते हैं और इसकी सभी डिपेंडेंसी.

  • android_custom_package: फ़ाइनल आर क्लास का नाम. यदि आप डायनामिक रूप से ऐप्लिकेशन आईडी संशोधित करते हैं तो यह पैकेज का नाम, शायद यहां दी गई package एट्रिब्यूट से मेल न खाए के तौर पर डिलीवर हो जाएगा.

• फ़ॉन्ट के लिए सहायता संसाधनों के तौर पर (यह एक नई सुविधा है, जिसे Android 8.0 (एपीआई लेवल 26)).
• अलग-अलग भाषा के हिसाब से बनाए गए APKs के लिए, Android Instant Apps SDK 1.1 और इसके बाद के वर्शन.

• अब अपने एक्सटर्नल नेटिव बिल्ड के लिए आउटपुट डायरेक्ट्री बदली जा सकती है प्रोजेक्ट, जैसा कि नीचे दिखाया गया है:

  ग्रूवी

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory "./outputs/cmake"
                  }
              }
          }
          

  Kotlin

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory = "./outputs/cmake"
                  }
              }
          }
          

• अब ये काम किए जा सकते हैं CMake 3.7 या Android Studio से नेटिव प्रोजेक्ट बनाते समय.

• lintChecks के नए डिपेंडेंसी कॉन्फ़िगरेशन की मदद से, ये काम किए जा सकते हैं एक JAR बनाएं, जो कस्टम लिंट के नियमों को तय करता हो और उसे अपने AAR में पैकेज करें और APK प्रोजेक्ट शामिल करते हैं.

  आपके कस्टम लिंट के नियम, आउटपुट वाले किसी अलग प्रोजेक्ट से जुड़े होने चाहिए एक JAR शामिल है, जिसमें सिर्फ़ एक JAR शामिल है compileOnly निर्भरता. इसके बाद, ऐप्लिकेशन और लाइब्रेरी के अन्य मॉड्यूल आपके लिंट पर निर्भर कर सकते हैं प्रोजेक्ट करने के लिए lintChecks कॉन्फ़िगरेशन का इस्तेमाल करें:

  ग्रूवी

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks project(':lint-checks')
          }
          

  Kotlin

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks(project(":lint-checks"))
          }
          

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

• Android प्लग इन 3.0.0 कुछ एपीआई हटा देता है और आपका बिल्ड काम करना बंद कर देता है नहीं किया जा सकता. उदाहरण के लिए, अब वैरिएंट एपीआई का इस्तेमाल इन कामों के लिए नहीं किया जा सकता outputFile() ऑब्जेक्ट ऐक्सेस करें या इसका इस्तेमाल करें मेनिफ़ेस्ट फ़ाइल पाने के लिए processManifest.manifestOutputFile() . इस बारे में ज़्यादा जानने के लिए, पढ़ें एपीआई में बदलाव.
• अब आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है (इसलिए, अब android.buildToolsVersion प्रॉपर्टी को हटाया जा सकता है). इन्होंने बदलाव किया है डिफ़ॉल्ट, प्लगिन अपने-आप ही उन ज़रूरी बिल्ड टूल का इस्तेमाल करता है इस्तेमाल कर रहे हैं.
• अब आपके पास buildTypes में PNG क्रंचिंग की सुविधा को चालू या बंद करने का विकल्प है ब्लॉक करें, जैसा कि नीचे दिखाया गया है. सभी बिल्ड के लिए PNG क्रंचिंग डिफ़ॉल्ट रूप से चालू होती है को छोड़कर डीबग बिल्ड को छोड़कर क्योंकि यह उन प्रोजेक्ट के लिए बिल्ड समय को बढ़ा देता है कई PNG फ़ाइलें शामिल होनी चाहिए. इसलिए, अन्य बिल्ड टाइप के बिल्ड में लगने वाले समय को कम करने के लिए, आपको या तो PNG क्रंचिंग को बंद करना चाहिए या रूपांतरित अपनी इमेज को WebP पर अपलोड करें.

  ग्रूवी

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              crunchPngs false
            }
          }
        }
        

  Kotlin

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              isCrunchPngs = false
            }
          }
        }
        

• Android प्लगिन अब ऐसे एक्ज़ीक्यूटेबल टारगेट अपने-आप बनाता है जो जिसे आप अपने बाहरी CMake प्रोजेक्ट में कॉन्फ़िगर कर सकते हैं.
• अब आपको ऐसा करना चाहिए व्याख्या जोड़ें प्रोसेसर को annotationProcessor डिपेंडेंसी कॉन्फ़िगरेशन.
• अब काम नहीं करने वाले ndkCompile के इस्तेमाल पर ज़्यादा पाबंदी लगा दी गई है. इसके बजाय, कंपाइल करने के लिए CMake या ndk-build का इस्तेमाल करके माइग्रेट करें नेटिव कोड जिसे आप अपने APK में पैकेज करना चाहते हैं. इस बारे में ज़्यादा जानने के लिए, पढ़ें इस तारीख से माइग्रेट करें ndkcompile पर सेट किया गया है.