Android Gradle प्लगिन 3.0.0 (अक्टूबर 2017)
Android Gradle प्लगिन 3.0.0 में कई बदलाव किए गए हैं. इनका मकसद, बड़े प्रोजेक्ट की परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करना है.
उदाहरण के लिए, ~130 मॉड्यूल और बड़ी संख्या में बाहरी डिपेंडेंसी (लेकिन कोई कोड या संसाधन नहीं) वाले सैंपल स्केलेटन प्रोजेक्ट पर, आपको परफ़ॉर्मेंस में इस तरह के सुधार देखने को मिल सकते हैं:
| 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 प्रोफ़ाइलर का इस्तेमाल करके, अपने बिल्ड का ट्रेस शामिल करें.
Android प्लगिन के इस वर्शन के लिए, ये ज़रूरी हैं:
| सबसे पुराना वर्शन | डिफ़ॉल्ट वर्शन | नोट | |
|---|---|---|---|
| ग्रेडल | 4.1 | 4.1 | ज़्यादा जानकारी के लिए, Gradle को अपडेट करने का तरीका देखें. |
| SDK Build Tools | 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 का इस्तेमाल करते समय समस्याएं आ रही हैं, तो कृपया गड़बड़ी की शिकायत करें.
gradle.propertiesफ़ाइल मेंandroid.enableAapt2=falseसेट करके भी AAPT2 को बंद किया जा सकता है. इसके बाद, कमांड लाइन से./gradlew --stopचलाकर Gradle डीमन को रीस्टार्ट करें.
नई सुविधाएं
- वैरिएंट के हिसाब से डिपेंडेंसी मैनेजमेंट. किसी मॉड्यूल का कोई वैरिएंट बनाते समय, प्लगिन अब लोकल लाइब्रेरी मॉड्यूल की डिपेंडेंसी के वैरिएंट को, बनाए जा रहे मॉड्यूल के वैरिएंट से अपने-आप मैच करता है.
- इसमें Android Instant Apps और Android Instant Apps SDK टूल के साथ काम करने वाला एक नया फ़ीचर मॉड्यूल प्लग इन शामिल है. इस SDK टूल को एसडीके मैनेजर का इस्तेमाल करके डाउनलोड किया जा सकता है. नए प्लगिन की मदद से फ़ीचर मॉड्यूल बनाने के बारे में ज़्यादा जानने के लिए, कई सुविधाओं वाले इंस्टैंट ऐप्लिकेशन का स्ट्रक्चर लेख पढ़ें.
- Java 8 की कुछ सुविधाओं और Java 8 की लाइब्रेरी का इस्तेमाल करने के लिए, पहले से मौजूद सहायता. Jack अब काम नहीं करता और इसकी ज़रूरत नहीं है. डिफ़ॉल्ट टूलचेन में मौजूद Java 8 के बेहतर वर्शन का इस्तेमाल करने के लिए, आपको पहले Jack को बंद करना होगा. ज़्यादा जानकारी के लिए, Java 8 की भाषा की सुविधाएं इस्तेमाल करना लेख पढ़ें.
-
Android Test Orchestrator की मदद से टेस्ट चलाने की सुविधा जोड़ी गई है. इससे आपको अपने ऐप्लिकेशन के हर टेस्ट को इंस्ट्रुमेंटेशन के अपने इन्वोकेशन में चलाने की सुविधा मिलती है. हर टेस्ट अपने इंस्ट्रुमेंटेशन इंस्टेंस में चलता है. इसलिए, टेस्ट के बीच शेयर की गई कोई भी स्थिति, आपके डिवाइस के सीपीयू या मेमोरी में इकट्ठा नहीं होती. इसके अलावा, अगर कोई टेस्ट क्रैश हो जाता है, तो वह सिर्फ़ इंस्ट्रुमेंटेशन के अपने इंस्टेंस को बंद करता है. इससे आपके अन्य टेस्ट चलते रहते हैं.
testOptions.executionको जोड़ा गया, ताकि यह तय किया जा सके कि डिवाइस पर टेस्ट ऑर्केस्ट्रेशन का इस्तेमाल करना है या नहीं. अगर आपको Android के जांच करने वाले टूल का इस्तेमाल करना है, तो आपकोANDROID_TEST_ORCHESTRATORकी जानकारी देनी होगी, जैसा कि यहां दिखाया गया है. डिफ़ॉल्ट रूप से, यह प्रॉपर्टीHOSTपर सेट होती है. इससे डिवाइस पर ऑर्केस्ट्रेशन की सुविधा बंद हो जाती है. साथ ही, यह टेस्ट चलाने का स्टैंडर्ड तरीका है.
Groovy
android { testOptions { execution 'ANDROID_TEST_ORCHESTRATOR' } }
Kotlin
android { testOptions { execution = "ANDROID_TEST_ORCHESTRATOR" } }
-
androidTestUtilडिपेंडेंसी के नए कॉन्फ़िगरेशन की मदद से, इंस्ट्रुमेंटेशन टेस्ट चलाने से पहले, टेस्ट में मदद करने वाला कोई दूसरा APK इंस्टॉल किया जा सकता है. जैसे, Android का जांच करने वाला टूल:Groovy
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 और इसके बाद के वर्शन के साथ, भाषा के हिसाब से एपीके के लिए सहायता.
-
अब आपके पास बाहरी नेटिव बिल्ड प्रोजेक्ट के लिए, आउटपुट डायरेक्ट्री बदलने का विकल्प है. इसके लिए, यहां दिया गया तरीका अपनाएं:
Groovy
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external C/C++ // 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 C/C++ // 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 बनाया जा सकता है जो कस्टम लिंट नियमों को तय करता है. साथ ही, उसे आपके एएआर और APK प्रोजेक्ट में पैकेज करता है.कस्टम लिंट नियम, किसी ऐसे अलग प्रोजेक्ट से जुड़े होने चाहिए जो एक JAR आउटपुट करता हो और जिसमें सिर्फ़
compileOnlyडिपेंडेंसी शामिल हों. इसके बाद, अन्य ऐप्लिकेशन और लाइब्रेरी मॉड्यूल,lintChecksकॉन्फ़िगरेशन का इस्तेमाल करके आपके लिंट प्रोजेक्ट पर निर्भर हो सकते हैं:Groovy
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()ऑब्जेक्ट को ऐक्सेस करने के लिए, Variants API का इस्तेमाल नहीं किया जा सकता. इसके अलावा, हर वैरिएंट के लिए मेनिफ़ेस्ट फ़ाइल पाने के लिए,processManifest.manifestOutputFile()का इस्तेमाल नहीं किया जा सकता. ज़्यादा जानने के लिए, एपीआई में हुए बदलाव लेख पढ़ें. - अब आपको बिल्ड टूल के लिए कोई वर्शन तय करने की ज़रूरत नहीं है. इसलिए, अब
android.buildToolsVersionप्रॉपर्टी को हटाया जा सकता है. डिफ़ॉल्ट रूप से, प्लगिन आपके Android प्लगिन के वर्शन के लिए, ज़रूरी बिल्ड टूल के कम से कम वर्शन का इस्तेमाल अपने-आप करता है. - अब
buildTypesब्लॉक में पीएनजी क्रंचिंग को चालू/बंद किया जा सकता है, जैसा कि यहां दिखाया गया है. PNG क्रंचिंग की सुविधा, डीबग बिल्ड को छोड़कर सभी बिल्ड के लिए डिफ़ॉल्ट रूप से चालू होती है. ऐसा इसलिए, क्योंकि इससे उन प्रोजेक्ट के लिए बिल्ड बनाने में ज़्यादा समय लगता है जिनमें कई PNG फ़ाइलें शामिल होती हैं. इसलिए, अन्य बिल्ड टाइप के लिए बिल्ड टाइम को बेहतर बनाने के लिए, आपको पीएनजी क्रंचिंग को बंद करना चाहिए या अपनी इमेज को WebP में बदलना चाहिए.Groovy
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 से माइग्रेट करना लेख पढ़ें.