Android Gradle प्लगिन 3.0.0 (अक्टूबर 2017)
Android Gradle प्लगिन 3.0.0 में कई बदलाव किए गए हैं. इनका मकसद, बड़े प्रोजेक्ट की परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करना है.
| Android प्लगिन का वर्शन + Gradle का वर्शन | Android प्लगिन 2.2.0 + Gradle 2.14.1 | Android प्लगिन 2.3.0 + Gradle 3.3 | Android प्लगिन 3.0.0 + Gradle 4.1 |
|---|---|---|---|
कॉन्फ़िगरेशन (उदाहरण के लिए, ./gradlew --help चलाना) |
करीब 2 मिनट | करीब 9 सेकंड | करीब 2.5 सेकंड |
| Java में एक लाइन का बदलाव (इंपलीमेंटेशन में बदलाव) | करीब 2 मिनट 15 सेकंड | करीब 29 सेकंड | करीब 6.4 सेकंड |
इनमें से कुछ बदलावों की वजह से, मौजूदा बिल्ड टूट जाते हैं. इसलिए, नए प्लगिन का इस्तेमाल करने से पहले, आपको अपने प्रोजेक्ट को माइग्रेट करने के लिए ज़रूरी कोशिश के बारे में सोचना चाहिए.
अगर आपको ऊपर बताए गए परफ़ॉर्मेंस में सुधार नहीं दिखते हैं, कृपया गड़बड़ी की शिकायत करें साथ ही, Gradle Profiler का इस्तेमाल करके, अपने बिल्ड का ट्रेस शामिल करें.
Android प्लगिन के इस वर्शन के लिए, ये ज़रूरी शर्तें हैं:
| सबसे पुराना वर्शन | डिफ़ॉल्ट वर्शन | नोट | |
|---|---|---|---|
| ग्रेडल | 4.1 | 4.1 | ज़्यादा जानकारी के लिए, Gradle को अपडेट करने का तरीका देखें. |
| एसडीके बिल्ड टूल | 26.0.2 | 26.0.2 | इंस्टॉल करें या कॉन्फ़िगर करें एसडीके बिल्ड टूल. इस अपडेट के बाद, आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. प्लगिन, डिफ़ॉल्ट रूप से ज़रूरी सबसे पुराने वर्शन का इस्तेमाल करता है. इसलिए, अब android.buildToolsVersion प्रॉपर्टी को हटाया जा सकता है. |
3.0.1 (नवंबर 2017)
यह Android Studio 3.0.1 के लिए एक छोटा अपडेट है. इसमें सामान्य गड़बड़ियां ठीक की गई हैं और परफ़ॉर्मेंस में सुधार किया गया है.
ऑप्टिमाइज़ेशन
- मल्टी-मॉड्यूल प्रोजेक्ट के लिए, बेहतर पैरललिज़्म. इसके लिए, टास्क ग्राफ़ का इस्तेमाल किया जाता है.
- डिपेंडेंसी में बदलाव करने पर, Gradle तेज़ी से बिल्ड करता है. ऐसा इसलिए, क्योंकि यह उन मॉड्यूल को फिर से कंपाइल नहीं करता जिनके पास उस डिपेंडेंसी के एपीआई का ऐक्सेस नहीं होता.
आपको Gradle के नए डिपेंडेंसी कॉन्फ़िगरेशन:
implementation,api,compileOnly, औरruntimeOnlyका इस्तेमाल करके, यह तय करना चाहिए कि किन डिपेंडेंसी के एपीआई, दूसरे मॉड्यूल के साथ शेयर किए जा सकते हैं. - क्लास के हिसाब से डेक्सिंग की वजह से, इंक्रीमेंटल बिल्ड की स्पीड बेहतर हुई है. अब हर क्लास को
अलग-अलग DEX फ़ाइलों में कंपाइल किया जाता है. साथ ही, सिर्फ़ उन क्लास को
फिर से डेक्स किया जाता है जिनमें बदलाव किया गया है. आपको उन ऐप्लिकेशन के लिए भी बिल्ड की स्पीड बेहतर होने की उम्मीद करनी चाहिए जिनमें
minSdkVersionको 20 या उससे कम पर सेट किया गया है. साथ ही, लेगसी मल्टी-डेक्स का इस्तेमाल किया गया है. - कैश्ड आउटपुट का इस्तेमाल करने के लिए, कुछ टास्क को ऑप्टिमाइज़ करके बिल्ड की स्पीड बेहतर की गई है. इस ऑप्टिमाइज़ेशन का फ़ायदा पाने के लिए, आपको सबसे पहले Gradle बिल्ड कैश चालू करना होगा.
- AAPT2 का इस्तेमाल करके, इंक्रीमेंटल रिसॉर्स प्रोसेसिंग को बेहतर बनाया गया है. यह अब
डिफ़ॉल्ट रूप से चालू है. अगर आपको AAPT2 का इस्तेमाल करते समय समस्याएं आ रही हैं,
कृपया गड़बड़ी की शिकायत करें. आपके पास
android.enableAapt2=falseको अपनीgradle.propertiesफ़ाइल में सेट करके, AAPT2 को बंद करने का विकल्प भी है. इसके बाद, कमांड लाइन से./gradlew --stopचलाकर, Gradle डेमॉन को रीस्टार्ट करें.
नई सुविधाएं
- वैरिएंट के हिसाब से डिपेंडेंसी मैनेज करना. किसी मॉड्यूल के किसी वैरिएंट को बिल्ड करते समय, प्लगिन अब स्थानीय लाइब्रेरी मॉड्यूल डिपेंडेंसी के वैरिएंट को, उस मॉड्यूल के वैरिएंट से अपने-आप मैच करता है जिसे आप बिल्ड कर रहे हैं.
- इसमें Android Instant Apps और Android Instant Apps SDK (जिसे एसडीके मैनेजर का इस्तेमाल करके डाउनलोड किया जा सकता है) के लिए, नया फ़ीचर मॉड्यूल प्लगिन शामिल है. नए प्लगिन की मदद से, फ़ीचर मॉड्यूल बनाने के बारे में ज़्यादा जानने के लिए, एक से ज़्यादा सुविधाओं वाले झटपट ऐप्लिकेशन का स्ट्रक्चर पढ़ें.
- Java 8 की कुछ भाषा सुविधाओं और Java 8 लाइब्रेरी का इस्तेमाल करने के लिए, पहले से मौजूद सहायता. Jack अब बंद हो गया है और इसकी ज़रूरत नहीं है. साथ ही, डिफ़ॉल्ट टूलचेन में मौजूद, बेहतर Java 8 सहायता का इस्तेमाल करने के लिए, आपको सबसे पहले Jack को बंद करना होगा. ज़्यादा जानकारी के लिए, Java 8 की भाषा सुविधाओं का इस्तेमाल करना लेख पढ़ें.
-
Android Test Orchestrator की मदद से टेस्ट चलाने की सुविधा जोड़ी गई है. इससे आपके ऐप्लिकेशन के हर टेस्ट को, इंस्ट्रुमेंटेशन के अपने इनवोकेशन में चलाया जा सकता है. हर टेस्ट, इंस्ट्रुमेंटेशन के अपने इंस्टेंस में चलता है. इसलिए, टेस्ट के बीच शेयर किया गया कोई भी स्टेट, आपके डिवाइस के सीपीयू या मेमोरी पर इकट्ठा नहीं होता. साथ ही, अगर कोई टेस्ट क्रैश हो जाता है, तो वह सिर्फ़ इंस्ट्रुमेंटेशन के अपने इंस्टेंस को बंद करता है. इसलिए, आपके अन्य टेस्ट अब भी चलते रहते हैं.
- डिवाइस पर टेस्ट ऑर्केस्ट्रेशन का इस्तेमाल करना है या नहीं, यह तय करने के लिए
testOptions.executionजोड़ा गया है. अगर आपको Android Test Orchestrator का इस्तेमाल करना है, तो आपको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 के संसाधनों की ज़रूरत होती है. जैसे, Roboelectric. जब इस प्रॉपर्टी कोtrueपर सेट किया जाता है, तो प्लगिन आपके यूनिट टेस्ट चलाने से पहले, संसाधन, एसेट, और मेनिफ़ेस्ट को मर्ज करता है. इसके बाद, आपके टेस्ट, क्लासपाथ पर मौजूदcom/android/tools/test_config.propertiesमें इन कुंजियों की जांच कर सकते हैं:-
android_merged_assets: मर्ज किए गए एसेट डायरेक्ट्री का पूरा पाथ.ध्यान दें: लाइब्रेरी मॉड्यूल के लिए, मर्ज किए गए एसेट में डिपेंडेंसी के एसेट शामिल नहीं होते (समस्या #65550419 देखें).
-
android_merged_manifest: मर्ज की गई मेनिफ़ेस्ट फ़ाइल का पूरा पाथ. -
android_merged_resources: मर्ज किए गए संसाधन डायरेक्ट्री का पूरा पाथ. इसमें मॉड्यूल और उसकी सभी डिपेंडेंसी के सभी संसाधन शामिल होते हैं. -
android_custom_package: फ़ाइनल R क्लास का पैकेज नाम. अगर ऐप्लिकेशन आईडी में डाइनैमिक तरीके से बदलाव किया जाता है, तो हो सकता है कि यह पैकेज नाम, ऐप्लिकेशन के मेनिफ़ेस्ट में मौजूदpackageएट्रिब्यूट से मैच न करे.
-
- फ़ॉन्ट को संसाधनों के तौर पर इस्तेमाल करने की सुविधा. यह Android 8.0 (एपीआई लेवल 26) में जोड़ी गई नई सुविधा है.
- Android Instant Apps SDK 1.1 और इसके बाद के वर्शन के साथ, भाषा के हिसाब से APK की सुविधा.
-
अब अपने बाहरी नेटिव बिल्ड प्रोजेक्ट के लिए, आउटपुट डायरेक्ट्री बदली जा सकती है. जैसा कि यहां दिखाया गया है:
शानदार
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" } } }
- अब Android Studio से नेटिव प्रोजेक्ट बनाते समय, CMake 3.7 या इसके बाद के वर्शन का इस्तेमाल किया जा सकता है.
-
नई
lintChecksडिपेंडेंसी कॉन्फ़िगरेशन की सुविधा से, ऐसा JAR बनाया जा सकता है जिसमें कस्टम लिंट नियम तय किए गए हों. साथ ही, इसे अपने AAR और APK प्रोजेक्ट में पैकेज किया जा सकता है.आपके कस्टम लिंट नियम, किसी अलग प्रोजेक्ट के होने चाहिए. इससे एक 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, कुछ एपीआई हटाता है. अगर उनका इस्तेमाल किया जाता है, तो आपका बिल्ड टूट जाएगा.
उदाहरण के लिए, अब
ऑब्जेक्ट को ऐक्सेस करने के लिए, वैरिएंट एपीआई का इस्तेमाल नहीं किया जा सकता. साथ ही, हर वैरिएंट के लिए मेनिफ़ेस्ट फ़ाइल पाने के लिए,
processManifest.manifestOutputFile()का इस्तेमाल नहीं किया जा सकता.outputFile()ज़्यादा जानकारी के लिए, एपीआई में हुए बदलाव लेख पढ़ें. - अब आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. इसलिए, अब
प्रॉपर्टी को हटाया जा सकता है.
android.buildToolsVersionBy डिफ़ॉल्ट रूप से, प्लगिन, Android प्लगिन के उस वर्शन के लिए, ज़रूरी सबसे पुराने बिल्ड टूल वर्शन का इस्तेमाल करता है जिसका इस्तेमाल किया जा रहा है. - अब
buildTypesब्लॉक में, पीएनजी क्रंचिंग को चालू/बंद किया जा सकता है. जैसा कि यहां दिखाया गया है. डीबग बिल्ड को छोड़कर, सभी बिल्ड के लिए पीएनजी क्रंचिंग डिफ़ॉल्ट रूप से चालू होती है ऐसा इसलिए, क्योंकि इससे उन प्रोजेक्ट के लिए बिल्ड का समय बढ़ जाता है जिनमें कई पीएनजी फ़ाइलें शामिल होती हैं. इसलिए, अन्य बिल्ड टाइप के लिए बिल्ड का समय बेहतर बनाने के लिए, आपको पीएनजी क्रंचिंग को बंद करना चाहिए या अपनी इमेज को 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 से माइग्रेट करना लेख पढ़ें.