Android
Android के लिए ग्रेड

C# Language Cordova firebase HTML iOS Java Language JavaScript Kotlin PHP react-native
खोज…


परिचय

ग्रैडल एक JVM- आधारित बिल्ड सिस्टम है जो डेवलपर्स को उच्च-स्तरीय स्क्रिप्ट लिखने में सक्षम बनाता है जिसका उपयोग संकलन और अनुप्रयोग उत्पादन की प्रक्रिया को स्वचालित करने के लिए किया जा सकता है। यह एक लचीला प्लगइन-आधारित प्रणाली है, जो आपको निर्माण प्रक्रिया के विभिन्न पहलुओं को स्वचालित करने की अनुमति देता है; संकलन और एक पर हस्ताक्षर करने सहित .jar , डाउनलोड करने और बाहरी निर्भरता के प्रबंधन, में खेतों इंजेक्शन लगाने AndroidManifest या विशिष्ट SDK संस्करण का उपयोग।

वाक्य - विन्यास

  • apply plugin : प्लगइन्स जो आमतौर पर सिर्फ 'com.android.application' या 'com.android.library' उपयोग किया जाना चाहिए।

  • android : आपके ऐप का मुख्य कॉन्फ़िगरेशन

    • compileSdkVersion : संकलन SDK संस्करण
    • buildToolsVersion : बिल्ड टूल्स संस्करण
    • defaultConfig : डिफ़ॉल्ट सेटिंग्स जो जायके और निर्माण प्रकारों द्वारा अधिलेखित की जा सकती हैं
      • applicationId : आपके द्वारा उपयोग किए जाने वाले एप्लिकेशन आईडी का उपयोग PlayStore में ज्यादातर आपके पैकेज के नाम के समान होता है
      • minSdkVersion : न्यूनतम आवश्यक SDK संस्करण
      • targetSdkVersion : आपके द्वारा संकलित SDK संस्करण (हमेशा सबसे नया होना चाहिए)
      • versionCode : आंतरिक संस्करण संख्या जो प्रत्येक अद्यतन पर बड़ी होनी चाहिए
      • versionName : वर्जन नंबर को एप डिटेल पेज में देख सकते हैं
    • buildTypes : कहीं और देखें (TODO)

  • dependencies : आपके ऐप की मावेन या स्थानीय निर्भरताएँ

    • एक एकल निर्भरता compile
    • testCompile : इकाई या एकीकरण परीक्षणों के लिए एक निर्भरता

टिप्पणियों

यह सभी देखें

Android के लिए ग्रेड - विस्तारित दस्तावेज़:

एक और टैग है जहां आप एंड्रॉइड में ग्रेडेल के उपयोग के बारे में अधिक विषय और उदाहरण पा सकते हैं।
http://www.riptutorial.com/topic/2092

एक बुनियादी build.gradle फ़ाइल

यह एक मॉड्यूल में डिफ़ॉल्ट build.gradle फ़ाइल का एक उदाहरण है। 

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion '25.0.3'

    signingConfigs {
        applicationName {
            keyAlias 'applicationName'
            keyPassword 'password'
            storeFile file('../key/applicationName.jks')
            storePassword 'keystorePassword'
        }
    }
    defaultConfig {
        applicationId 'com.company.applicationName'
        minSdkVersion 14
        targetSdkVersion 25
        versionCode 1
        versionName '1.0'
        signingConfig signingConfigs.applicationName
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support:design:25.3.1'

    testCompile 'junit:junit:4.12'
}

DSL (डोमेन-विशिष्ट भाषा)

उपरोक्त फ़ाइल के प्रत्येक ब्लॉक को DSL (डोमेन-विशिष्ट भाषा) कहा जाता है।

प्लगइन्स

पहली पंक्ति, apply plugin: 'com.android.application' , ग्रेड के लिए एंड्रॉइड प्लगइन को बिल्ड पर लागू करता है और एंड्रॉइड-विशिष्ट बिल्ड विकल्पों की घोषणा करने के लिए android {} ब्लॉक को उपलब्ध कराता है।

Android एप्लिकेशन के लिए : 

apply plugin: 'com.android.application'

Android लाइब्रेरी के लिए : 

apply plugin: 'com.android.library'

ऊपर के नमूने में DSLs को समझना

दूसरा भाग, द android {...} ब्लॉक, एंड्रॉइड DSL जिसमें आपके प्रोजेक्ट के बारे में जानकारी है।

उदाहरण के लिए, आप compileSdkVersion सेट कर सकते हैं जो Android API स्तर को निर्दिष्ट करता है, जिसका उपयोग ग्रेड द्वारा आपके ऐप को संकलित करने के लिए किया जाना चाहिए।
उप-ब्लॉक defaultConfig आपके प्रकट होने के लिए डिफ़ॉल्ट रखता है। आप उन्हें उत्पाद जायके के साथ override कर सकते override ।

आप इन उदाहरणों में अधिक जानकारी पा सकते हैं:

निर्भरता

dependencies ब्लॉक को android ब्लॉक {...} बाहर परिभाषित किया गया है: इसका मतलब है कि यह एंड्रॉइड प्लगइन द्वारा परिभाषित नहीं है, लेकिन यह मानक ग्रेड है।
dependencies ब्लॉक निर्दिष्ट करता है कि कौन सी बाहरी लाइब्रेरी (आमतौर पर एंड्रॉइड लाइब्रेरी, लेकिन जावा लाइब्रेरी भी मान्य हैं) आप अपने ऐप में शामिल करना चाहते हैं। ग्रैडल स्वचालित रूप से आपके लिए इन निर्भरताओं को डाउनलोड करेगा (यदि कोई स्थानीय प्रतिलिपि उपलब्ध नहीं है), आपको बस एक और compile लाइनों को जोड़ने की आवश्यकता है जब आप एक और पुस्तकालय जोड़ना चाहते हैं।

आइए यहां मौजूद लाइनों में से एक को देखें:

compile 'com.android.support:design:25.3.1'

यह पंक्ति मूल रूप से कहती है

मेरी परियोजना के लिए Android समर्थन डिज़ाइन लाइब्रेरी पर निर्भरता जोड़ें।

ग्रैडल यह सुनिश्चित करेगा कि लाइब्रेरी को डाउनलोड और प्रस्तुत किया जाए ताकि आप इसे अपने ऐप में उपयोग कर सकें, और इसका कोड भी आपके ऐप में शामिल हो जाएगा।

यदि आप मावेन से परिचित हैं, तो यह सिंटैक्स GroupId , एक बृहदान्त्र, ArtifactId , एक और बृहदान्त्र है, तो आप जिस निर्भरता के संस्करण को शामिल करना चाहते हैं, वह आपको वर्जनिंग पर पूर्ण नियंत्रण प्रदान करता है।

जबकि प्लस (+) चिह्न का उपयोग करके विरूपण साक्ष्य संस्करण निर्दिष्ट करना संभव है, ऐसा करने से बचने के लिए सबसे अच्छा अभ्यास है; यदि पुस्तकालय आपके ज्ञान के बिना परिवर्तनों को अद्यतन करने के साथ अद्यतन हो जाता है, तो यह उन मुद्दों को जन्म दे सकता है, जो संभवतः आपके ऐप में क्रैश हो सकते हैं।

आप विभिन्न प्रकार की निर्भरताएँ जोड़ सकते हैं:

एक विशेष ध्यान आरा फ्लैट निर्भरता के लिए समर्पित होना चाहिए।

आप इस विषय में अधिक जानकारी पा सकते हैं।

Appcompat-v7 में -v7 के बारे में ध्यान दें

compile 'com.android.support:appcompat-v7:25.3.1'

इसका appcompat मतलब है कि यह लाइब्रेरी ( appcompat ) एंड्रॉइड एपीआई स्तर 7 और आगे के साथ संगत है।

कनिष्ठ के बारे में ध्यान दें : कनिष्ठ: 4.12

यह इकाई परीक्षण के लिए परीक्षण निर्भरता है।

विभिन्न बिल्ड कॉन्फ़िगरेशन के लिए विशिष्ट निर्भरता निर्दिष्ट करना

आप निर्दिष्ट कर सकते हैं कि एक निर्भरता का उपयोग केवल एक निश्चित बिल्ड कॉन्फ़िगरेशन के लिए किया जाना चाहिए या आप सामान्य compile बजाय debugCompile , testCompile या releaseCompile का उपयोग करके बिल्ड प्रकारों या उत्पाद जायके (जैसे, डीबग, परीक्षण या रिलीज़) के लिए अलग-अलग निर्भरता परिभाषित कर सकते हैं। ।

यह आपके रिहाई का निर्माण, जो आपके रिहाई रखेंगे से बाहर परीक्षण और debug- संबंधित निर्भरता रखने के लिए उपयोगी है APK संभव और मदद के रूप में पतली के रूप में यह सुनिश्चित करें कि किसी भी डिबग जानकारी अपने ऐप के बारे आंतरिक जानकारी प्राप्त करने के लिए इस्तेमाल नहीं किया जा सकता है।

signingConfig

signingConfig आपको अपने ग्रेड को keystore जानकारी शामिल करने के लिए कॉन्फ़िगर करने की अनुमति देता है और यह सुनिश्चित करता है कि इन कॉन्फ़िगरेशन का उपयोग करके निर्मित एपीके पर हस्ताक्षर किए गए हैं और प्ले स्टोर रिलीज़ के लिए तैयार हैं।

यहां आप एक समर्पित विषय पा सकते हैं ।

नोट : यह सिफारिश नहीं है कि अपने ग्रेड फ़ाइल के अंदर हस्ताक्षर क्रेडेंशियल्स रखें। हस्ताक्षर कॉन्फ़िगरेशन को हटाने के लिए, बस साइनिंग signingConfigs भाग को छोड़ दें।
आप उन्हें विभिन्न तरीकों से निर्दिष्ट कर सकते हैं:

अधिक जानकारी के लिए इस विषय को देखें: कीस्टोर पासवर्ड को उजागर किए बिना APK पर हस्ताक्षर करें ।

आप समर्पित ग्रेडल विषय में एंड्रॉइड के लिए ग्रैडल के बारे में और जानकारी प्राप्त कर सकते हैं ।

परिभाषित उत्पाद जायके

उत्पाद जायके को android { ... } अंदर build.gradle फ़ाइल में परिभाषित किया गया है android { ... } जैसा कि नीचे देखा गया है। 

...
android {
    ...
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
}

ऐसा करने से, हमारे पास अब दो अतिरिक्त उत्पाद स्वाद हैं: free : free और paid । प्रत्येक का अपना विशिष्ट विन्यास और गुण हो सकते हैं। उदाहरण के लिए, हमारे दोनों नए स्वादों में हमारे मौजूदा main स्वाद (डिफ़ॉल्ट रूप से उपलब्ध है, इसलिए यहां नहीं दिखाया गया है) की तुलना में एक अलग applicationId और versionName है।

उत्पाद स्वाद-विशिष्ट निर्भरता जोड़ना

विशिष्ट उत्पाद स्वाद के लिए निर्भरता को जोड़ा जा सकता है, इसी तरह वे विशिष्ट बिल्ड कॉन्फ़िगरेशन के लिए कैसे जोड़े जा सकते हैं।

इस उदाहरण के लिए, मान लें कि हमने पहले से ही दो उत्पाद फ्लेवरों को परिभाषित किया है जिन्हें free और paid कहा जाता है ( फ्लेवर को यहां परिभाषित करने पर अधिक)।
फिर हम free स्वाद के लिए AdMob निर्भरता, और paid लिए पिकासो पुस्तकालय जोड़ सकते हैं जैसे: 

android {
    ...

    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
}

...
dependencies {
    ...
    // Add AdMob only for free flavor
    freeCompile 'com.android.support:appcompat-v7:23.1.1'
    freeCompile 'com.google.android.gms:play-services-ads:8.4.0'
    freeCompile 'com.android.support:support-v4:23.1.1'

    // Add picasso only for paid flavor
    paidCompile 'com.squareup.picasso:picasso:2.5.2'
} 
...

उत्पाद स्वाद-विशिष्ट संसाधनों को जोड़ना

किसी विशिष्ट उत्पाद के स्वाद के लिए संसाधन जोड़े जा सकते हैं।

इस उदाहरण के लिए, मान लें कि हमने पहले से ही दो उत्पाद फ्लेवरों को परिभाषित किया है जिन्हें free और paid कहा जाता है। उत्पाद स्वाद-विशिष्ट संसाधनों को जोड़ने के लिए, हम main/res फ़ोल्डर के साथ अतिरिक्त संसाधन फ़ोल्डर बनाते हैं, जिसे हम सामान्य रूप से संसाधनों को जोड़ सकते हैं। इस उदाहरण के लिए, हम प्रत्येक उत्पाद के स्वाद के लिए एक स्ट्रिंग, status को परिभाषित करेंगे:

/ src / main /res/values/strings.xml 

<resources>
    <string name="status">Default</string>
</resources>

/ src / free /res/values/strings.xml 

<resources>
    <string name="status">Free</string>
</resources>

/ src / paid /res/values/strings.xml 

<resources>
    <string name="status">Paid</string>
</resources>

उत्पाद स्वाद-विशिष्ट status तार main स्वाद में status लिए मूल्य को ओवरराइड करेगा।

बिल्ड कॉन्फ़िगरेशन फ़ील्ड्स को परिभाषित और उपयोग करें

BuildConfigField

buildConfigField को परिभाषित करने के लिए buildConfigField लाइनों की अनुमति देता है। ये स्थिरांक BuildConfig वर्ग के स्थिर क्षेत्रों के रूप में रनटाइम पर सुलभ होंगे। यह defaultConfig ब्लॉक के भीतर सभी क्षेत्रों को परिभाषित करके फ्लेवर बनाने के लिए इस्तेमाल किया जा सकता है, फिर आवश्यकतानुसार व्यक्तिगत बिल्ड फ्लेवर के लिए उन्हें ओवरराइड कर सकता है।

यह उदाहरण निर्माण तिथि को परिभाषित करता है और परीक्षण के बजाय निर्माण के लिए झंडे को परिभाषित करता है: 

android {
    ...
    defaultConfig {
        ...
        // defining the build date
        buildConfigField "long", "BUILD_DATE", System.currentTimeMillis() + "L"
        // define whether this build is a production build
        buildConfigField "boolean", "IS_PRODUCTION", "false"
        // note that to define a string you need to escape it
        buildConfigField "String", "API_KEY", "\"my_api_key\""
    }

    productFlavors {
        prod {
            // override the productive flag for the flavor "prod"
            buildConfigField "boolean", "IS_PRODUCTION", "true"
            resValue 'string', 'app_name', 'My App Name'
        }
        dev {
            // inherit default fields
            resValue 'string', 'app_name', 'My App Name - Dev'
        }
    }
}

स्वचालित रूप से उत्पन्न <package_name>। BuildConfig फ़ोल्डर में BuildConfig में निर्देश के आधार पर निम्नलिखित फ़ील्ड शामिल हैं: 

public class BuildConfig {
    // ... other generated fields ...
    public static final long BUILD_DATE = 1469504547000L;
    public static final boolean IS_PRODUCTION = false;
    public static final String API_KEY = "my_api_key";
}

परिभाषित फ़ील्ड अब एप्लिकेशन के भीतर रन-टाइम BuildConfig क्लास तक पहुँच कर उपयोग किया जा सकता है: 

public void example() {
    // format the build date
    SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
    String buildDate = dateFormat.format(new Date(BuildConfig.BUILD_DATE));
    Log.d("build date", buildDate);
    
    // do something depending whether this is a productive build
    if (BuildConfig.IS_PRODUCTION) {
        connectToProductionApiEndpoint();
    } else {
        connectToStagingApiEndpoint();
    }
}

ResValue

resValue में productFlavors एक संसाधन मान बनाता है। यह किसी भी प्रकार का संसाधन ( string , dimen , color , आदि) हो सकता है। यह उपयुक्त फ़ाइल में एक संसाधन को परिभाषित करने के समान है: जैसे स्ट्रिंग को स्ट्रिंग में परिभाषित strings.xml । strings.xml फ़ाइल। लाभ यह है कि ग्रेडेल में परिभाषित एक को आपके उत्पाद के आधार पर संशोधित किया जा सकता है। मान को एक्सेस करने के लिए, उसी कोड को लिखें जैसे आप रिसोर्स फ़ाइल से रेस को एक्सेस कर रहे थे: 

getResources().getString(R.string.app_name)

महत्वपूर्ण बात यह है कि इस तरह परिभाषित किए गए संसाधन फाइलों में परिभाषित मौजूदा संसाधनों को संशोधित नहीं कर सकते हैं। वे केवल नए संसाधन मान बना सकते हैं।

कुछ पुस्तकालयों (जैसे कि Google मैप्स एंड्रॉइड एपीआई) को meta-data टैग के रूप में मैनिफेस्ट में दी गई एक एपीआई कुंजी की आवश्यकता होती है। यदि डिबगिंग और प्रोडक्शन बिल्ड के लिए अलग-अलग कुंजी की आवश्यकता होती है, तो ग्रैड द्वारा भरे गए एक प्लेसहोल्डर को निर्दिष्ट करें।

अपने AndroidManifest.xml फ़ाइल में: 

<meta-data
    android:name="com.google.android.geo.API_KEY"
    android:value="${MAPS_API_KEY}"/>

और फिर अपनी build.gradle फ़ाइल के अनुसार फ़ील्ड सेट करें: 

android {
    defaultConfig {
        ...
        // Your development key
        manifestPlaceholders = [ MAPS_API_KEY: "AIza..." ]
    }

    productFlavors {
        prod {
            // Your production key
            manifestPlaceholders = [ MAPS_API_KEY: "AIza..." ]
        }
    }
}

Android बिल्ड सिस्टम स्वचालित रूप से कई फ़ील्ड बनाता है और उन्हें BuildConfig.java में BuildConfig.java । ये क्षेत्र हैं:

खेत विवरण
DEBUG यदि एप्लिकेशन डिबग या रिलीज़ मोड में है तो एक Boolean बताते हैं
APPLICATION_ID एक String जिसमें एप्लिकेशन की आईडी है (जैसे com.example.app )
BUILD_TYPE अनुप्रयोग के बिल्ड प्रकार युक्त String (आमतौर पर या तो debug या release )
FLAVOR एक String जिसमें बिल्ड का विशेष स्वाद होता है
VERSION_CODE संस्करण (बिल्ड) नंबर युक्त एक int ।
इस रूप में ही है versionCode में build.gradle या versionCode में AndroidManifest.xml
VERSION_NAME एक String जिसमें संस्करण (बिल्ड) नाम है।
इस रूप में ही है versionName में build.gradle या versionName में AndroidManifest.xml

उपरोक्त के अलावा, यदि आपने स्वाद के कई आयामों को परिभाषित किया है तो प्रत्येक आयाम का अपना मूल्य होगा। उदाहरण के लिए, यदि आपके पास color और size के स्वाद के दो आयाम हैं, तो आपके पास निम्नलिखित चर भी होंगे:

खेत विवरण
FLAVOR_color एक String जिसमें 'रंग' स्वाद का मूल्य होता है।
FLAVOR_size एक String जिसमें 'आकार' स्वाद के लिए मान होता है।

"निर्भरता.ग्रेड" फ़ाइल के माध्यम से निर्भरता को केंद्रीकृत करना

मल्टी-मॉड्यूल प्रोजेक्ट्स के साथ काम करते समय, यह एक बिल्ड स्थान पर निर्भरता को केंद्रीकृत करने में मददगार होता है, न कि उन्हें कई बिल्ड फाइलों में फैलाने के लिए, विशेष रूप से एंड्रॉइड सपोर्ट लाइब्रेरी और फायरबेस लाइब्रेरी जैसी आम लाइब्रेरी के लिए।

एक अनुशंसित तरीका है कि ग्रेड बिल्ड बिल्ड को अलग करना, एक build.gradle प्रति मॉड्यूल, साथ ही प्रोजेक्ट रूट में एक और निर्भरता के लिए एक और एक, उदाहरण के लिए: 

root
  +- gradleScript/
  |     dependencies.gradle
  +- module1/
  |     build.gradle
  +- module2/
  |     build.gradle
  +- build.gradle

फिर, आपकी सभी निर्भरता gradleScript/dependencies.gradle में स्थित हो सकती है: 

ext {
    // Version
    supportVersion = '24.1.0'

    // Support Libraries dependencies
    supportDependencies = [
            design:            "com.android.support:design:${supportVersion}",
            recyclerView:      "com.android.support:recyclerview-v7:${supportVersion}",
            cardView:          "com.android.support:cardview-v7:${supportVersion}",
            appCompat:         "com.android.support:appcompat-v7:${supportVersion}",
            supportAnnotation: "com.android.support:support-annotations:${supportVersion}",
    ]

    firebaseVersion = '9.2.0';

    firebaseDependencies = [
            core:         "com.google.firebase:firebase-core:${firebaseVersion}",
            database:     "com.google.firebase:firebase-database:${firebaseVersion}",
            storage:      "com.google.firebase:firebase-storage:${firebaseVersion}",
            crash:        "com.google.firebase:firebase-crash:${firebaseVersion}",
            auth:         "com.google.firebase:firebase-auth:${firebaseVersion}",
            messaging:    "com.google.firebase:firebase-messaging:${firebaseVersion}",
            remoteConfig: "com.google.firebase:firebase-config:${firebaseVersion}",
            invites:      "com.google.firebase:firebase-invites:${firebaseVersion}",
            adMod:        "com.google.firebase:firebase-ads:${firebaseVersion}",
            appIndexing:  "com.google.android.gms:play-services-appindexing:${firebaseVersion}",
    ];
}

जो तब उस फ़ाइल से शीर्ष स्तर फ़ाइल build.gradle में लागू किया जा सकता है: 

// Load dependencies
apply from: 'gradleScript/dependencies.gradle'

और module1/build.gradle तरह: 

// Module build file
dependencies {
    // ...
    compile supportDependencies.appCompat
    compile supportDependencies.design
    compile firebaseDependencies.crash
}

एक और दृष्टिकोण

लाइब्रेरी निर्भरता संस्करणों को केंद्रीकृत करने के लिए कम वर्बोस दृष्टिकोण को एक बार एक चर के रूप में संस्करण संख्या की घोषणा करके और हर जगह इसका उपयोग करके प्राप्त किया जा सकता है।

कार्यस्थान रूट में build.gradle जोड़ें: 

ext.v = [
    supportVersion:'24.1.1',
]

और एक ही पुस्तकालय का उपयोग करने वाले हर मॉड्यूल में आवश्यक पुस्तकालयों को जोड़ते हैं 

compile "com.android.support:support-v4:${v.supportVersion}"
compile "com.android.support:recyclerview-v7:${v.supportVersion}"
compile "com.android.support:design:${v.supportVersion}"
compile "com.android.support:support-annotations:${v.supportVersion}"

स्वाद-विशिष्ट संसाधनों के लिए निर्देशिका संरचना

विभिन्न प्रकार के एप्लिकेशन बिल्ड में अलग-अलग संसाधन हो सकते हैं। स्वाद-विशिष्ट संसाधन बनाने के लिए src निर्देशिका में अपने स्वाद के निचले-मामले के नाम के साथ एक निर्देशिका बनाएं और अपने संसाधनों को उसी तरह से जोड़ेंगे जैसे आप सामान्य रूप से करते हैं।

उदाहरण के लिए, यदि आपके पास एक स्वाद Development था और इसके लिए एक अलग लॉन्चर आइकन प्रदान करना चाहता था, तो आप एक निर्देशिका src/development/res/drawable-mdpi बनाएंगे और उस निर्देशिका के अंदर अपने विकास-विशिष्ट आइकन के साथ एक ic_launcher.png फ़ाइल बनाएँ।

निर्देशिका संरचना इस तरह दिखाई देगी: 

src/
  main/
    res/
      drawable-mdpi/
        ic_launcher.png  <-- the default launcher icon
  development/
    res/
      drawable-mdpi/
        ic_launcher.png  <-- the launcher icon used when the product flavor is 'Development'

(बेशक, इस मामले में आप भी drawable-hdpi, drawable-xhdpi आदि के लिए आइकन बनाएंगे)।

एंड्रॉइड स्टूडियो प्रोजेक्ट में दो build.gradle फाइलें क्यों हैं?

<PROJECT_ROOT>\app\build.gradle ऐप मॉड्यूल के लिए विशिष्ट है।

<PROJECT_ROOT>\build.gradle एक "टॉप-लेवल बिल्ड फ़ाइल" है जहाँ आप सभी उप-प्रोजेक्ट्स / मॉड्यूल में कॉमन विन्यास विकल्प जोड़ सकते हैं।

यदि आप अपनी परियोजना में एक अन्य मॉड्यूल का उपयोग करते हैं, तो एक स्थानीय पुस्तकालय के रूप में आपके पास एक और build.gradle फ़ाइल होगी: <PROJECT_ROOT>\module\build.gradle

शीर्ष स्तर की फ़ाइल में आप बिल्डप्स्क्रिप्ट ब्लॉक या कुछ सामान्य गुणों के रूप में सामान्य गुणों को निर्दिष्ट कर सकते हैं। 

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
       classpath 'com.android.tools.build:gradle:2.2.0'
       classpath 'com.google.gms:google-services:3.0.0'
    }
}

ext {
    compileSdkVersion = 23
    buildToolsVersion = "23.0.1"
}

app\build.gradle आप केवल मॉड्यूल के लिए गुणों को परिभाषित करते हैं: 

apply plugin: 'com.android.application'


android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
}

dependencies {
    //.....
}

शेल शेल स्क्रिप्ट को एक्सेल से बाहर निकालना

एक शेल स्क्रिप्ट आपके निर्माण को मूल रूप से विस्तारित करने के लिए एक बहुत ही बहुमुखी तरीका है जिसे आप कुछ भी सोच सकते हैं।

एक निर्वासन के रूप में, यहां प्रोटोबुफ़ फ़ाइलों को संकलित करने और परिणामी जावा फ़ाइलों को संकलन के लिए स्रोत निर्देशिका में जोड़ने के लिए एक सरल स्क्रिप्ट है: 

def compilePb() {
    exec {
        // NOTICE: gradle will fail if there's an error in the protoc file...
        executable "../pbScript.sh"
    }
}

project.afterEvaluate {
    compilePb()
}

इस उदाहरण के लिए 'pbScript.sh' शेल स्क्रिप्ट, प्रोजेक्ट के रूट फ़ोल्डर में स्थित है: 

#!/usr/bin/env bash
pp=/home/myself/my/proto

/usr/local/bin/protoc -I=$pp \
 --java_out=./src/main/java \
  --proto_path=$pp \
 $pp/my.proto \
 --proto_path=$pp \
 $pp/my_other.proto

अपने ग्रेडेल त्रुटियों को डीबग करना

निम्नलिखित ग्रेडल का एक अंश है - गैर-शून्य निकास मान क्या है और मैं इसे कैसे ठीक करूं? , इसे पूरी चर्चा के लिए देखें।

मान लीजिए कि आप एक एप्लिकेशन विकसित कर रहे हैं और आपको कुछ ग्रैडल त्रुटि मिलती है जो प्रतीत होता है कि आम तौर पर ऐसा दिखेगा। 

:module:someTask FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':module:someTask'.
> some message here...  finished with non-zero exit value X
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: Y.ZZ secs

आप अपनी समस्या के लिए StackOverflow पर यहां खोज करते हैं, और लोग कहते हैं कि अपनी परियोजना को साफ और पुनर्निर्माण करें, या मल्टीडेक्स को सक्षम करें , और जब आप कोशिश करते हैं, तो यह समस्या को ठीक नहीं कर रहा है।

अधिक जानकारी प्राप्त करने के तरीके हैं , लेकिन ग्रैडल आउटपुट को स्वयं उस संदेश के ऊपर कुछ पंक्तियों में वास्तविक त्रुटि पर इंगित करना चाहिए: module:someTask FAILED और अंतिम :module:someOtherTask जो पारित हुआ। इसलिए, यदि आप अपनी त्रुटि के बारे में कोई प्रश्न पूछते हैं, तो कृपया त्रुटि के अधिक संदर्भ को शामिल करने के लिए अपने प्रश्नों को संपादित करें।

तो, आपको "गैर-शून्य निकास मान" मिलता है। ठीक है, यह संख्या एक अच्छा संकेतक है जिसे आपको ठीक करने का प्रयास करना चाहिए। यहाँ कुछ अक्सर होते हैं।

  • 1 एक सामान्य त्रुटि कोड है और त्रुटि ग्रेडल आउटपुट में होने की संभावना है
  • 2 अतिव्यापी निर्भरता या परियोजना गलत धारणा से संबंधित प्रतीत होता है।
  • 3 बहुत अधिक निर्भरता, या स्मृति समस्या सहित से प्रतीत होता है।

उपरोक्त के लिए सामान्य समाधान (परियोजना के स्वच्छ और पुनर्निर्माण के प्रयास के बाद) हैं:

  • 1 - उस त्रुटि को संबोधित करें जिसका उल्लेख किया गया है। आम तौर पर, यह एक संकलन-समय की त्रुटि है, जिसका अर्थ है कि आपकी परियोजना में कुछ कोड मान्य नहीं है। इसमें Android प्रोजेक्ट के लिए XML और Java दोनों शामिल हैं।
  • 2 और 3 - यहाँ कई उत्तर आपको मल्टीडेक्स को सक्षम करने के लिए कहते हैं । जबकि यह समस्या को ठीक कर सकता है, यह सबसे अधिक संभावना है एक समाधान है। यदि आपको समझ में नहीं आता है कि आप इसका उपयोग क्यों कर रहे हैं (लिंक देखें), तो आपको शायद इसकी आवश्यकता नहीं है। सामान्य समाधानों में पुस्तकालय निर्भरता के आपके अति प्रयोग को काटना शामिल है (जैसे कि Google Play सेवाओं के सभी, जब आपको केवल उदाहरण के लिए मैप्स या साइन-इन जैसी एक लाइब्रेरी का उपयोग करने की आवश्यकता होती है)।

बिल्ड प्रकार और उत्पाद जायके के लिए अलग-अलग एप्लिकेशन आईडी निर्दिष्ट करना

आप अलग अलग आवेदन आईडी या प्रत्येक के लिए पैकेज के नाम निर्दिष्ट कर सकते हैं buildType या productFlavor applicationIdSuffix विन्यास विशेषता का उपयोग:

प्रत्यय लगाना का उदाहरण applicationId प्रत्येक के लिए buildType : 

defaultConfig {
    applicationId "com.package.android"
    minSdkVersion 17
    targetSdkVersion 23
    versionCode 1
    versionName "1.0"
}

buildTypes {
    release {
        debuggable false      
    }

    development {
        debuggable true
        applicationIdSuffix ".dev"
    }

    testing {
        debuggable true
        applicationIdSuffix ".qa"
    }
}

हमारे परिणामी applicationIds अब होंगे:

  • com.package.android release
  • com.package.android। development लिए देव
  • com.package.android। testing लिए qa

इस के लिए किया जा सकता है productFlavors रूप में अच्छी तरह: 

productFlavors {
    free {
        applicationIdSuffix ".free"
    }
    paid {
        applicationIdSuffix ".paid"
    }
}

परिणामी applicationIds होंगे:

  • com.package.android। मुक्त स्वाद के लिए free
  • com.package.android। भुगतान paid स्वाद के लिए paid

कीस्टोर पासवर्ड को उजागर किए बिना साइन इन करें

आप इन गुणों का उपयोग करके build.gradle फ़ाइल में build.gradle साइन करने के लिए हस्ताक्षर कॉन्फ़िगरेशन को परिभाषित कर सकते हैं:

  • storeFile : कीस्टोर फाइल
  • storePassword : कीस्टोर पासवर्ड
  • keyAlias : एक प्रमुख उपनाम नाम
  • keyPassword : एक मुख्य उपनाम पासवर्ड

कई मामलों में आपको build.gradle फ़ाइल में इस तरह की जानकारी से बचने की आवश्यकता हो सकती है।

विधि A: एक कीस्टोर.प्रोटेक्ट्स फ़ाइल का उपयोग करके रिलीज़ हस्ताक्षर कॉन्फ़िगर करें

आपके एप्लिकेशन के build.gradle को कॉन्फ़िगर करना संभव है, ताकि यह आपके हस्ताक्षर की जानकारी को keystore.properties जैसी गुण फ़ाइल से पढ़ ले।

इस तरह साइन अप करना फायदेमंद है क्योंकि:

  • आपकी हस्ताक्षरित कॉन्फ़िगरेशन जानकारी आपकी build.gradle फ़ाइल से अलग है
  • आपको अपनी कीस्टोर फ़ाइल के लिए पासवर्ड प्रदान करने के लिए हस्ताक्षर प्रक्रिया के दौरान हस्तक्षेप करने की आवश्यकता नहीं है
  • आप आसानी से संस्करण नियंत्रण से keystore.properties फ़ाइल को बाहर कर सकते हैं

सबसे पहले, इस तरह की सामग्री के साथ अपने प्रोजेक्ट के रूट में keystore.properties नामक एक फ़ाइल बनाएं (मानों को स्वयं के साथ बदलकर): 

storeFile=keystore.jks
storePassword=storePassword
keyAlias=keyAlias
keyPassword=keyPassword

अब, अपने ऐप के में build.gradle फ़ाइल, की स्थापना की signingConfigs इस प्रकार ब्लॉक: 

android {
...

    signingConfigs {
        release {
            def propsFile = rootProject.file('keystore.properties')
            if (propsFile.exists()) {
                def props = new Properties()
                props.load(new FileInputStream(propsFile))
                storeFile = file(props['storeFile'])
                storePassword = props['storePassword']
                keyAlias = props['keyAlias']
                keyPassword = props['keyPassword']
            }
        }
    }
}

यह वास्तव में यह सब है, लेकिन संस्करण नियंत्रण के लिए अपनी कीस्टोर फाइल और आपकी keystore.properties फाइल दोनों को बाहर करना न भूलें ।

ध्यान देने योग्य बातें:

  • storeFile पथ में निर्दिष्ट keystore.properties फ़ाइल को अपने ऐप्लिकेशन के अनुरूप होना चाहिए build.gradle फ़ाइल। यह उदाहरण मानता है कि कीस्टोर फ़ाइल ऐप की build.gradle फ़ाइल के समान निर्देशिका में है।
  • इस उदाहरण में प्रोजेक्ट के रूट में keystore.properties फ़ाइल है। यदि आप इसे कहीं और रखते हैं, तो अपने प्रोजेक्ट के रूट के सापेक्ष rootProject.file('keystore.properties') में मान बदलना सुनिश्चित करें।

विधि बी: एक पर्यावरण चर का उपयोग करके

एक ही गुण फ़ाइल के बिना भी प्राप्त किया जा सकता है, जिससे पासवर्ड को खोजना मुश्किल हो जाता है: 

android {

  signingConfigs {
    release {
        storeFile file('/your/keystore/location/key')
        keyAlias 'your_alias'
        String ps = System.getenv("ps")
        if (ps == null) {
             throw new GradleException('missing ps env variable')
        }
        keyPassword ps
        storePassword ps
    }
}

"ps" पर्यावरण चर वैश्विक हो सकता है, लेकिन एक सुरक्षित दृष्टिकोण केवल एंड्रॉइड स्टूडियो के खोल में जोड़कर हो सकता है।
लिनक्स में यह एंड्रॉइड स्टूडियो के Desktop Entry संपादित करके किया जा सकता है 

Exec=sh -c "export ps=myPassword123 ; /path/to/studio.sh"

आप इस विषय में अधिक जानकारी पा सकते हैं ।

अपने वर्जन को "version.properties" फ़ाइल के माध्यम से बनाना

जब भी आप इसे बनाते हैं, तो आप अपने पैकेज संस्करण को ऑटो-इंक्रीमेंट के लिए ग्रेडल का उपयोग कर सकते हैं। ऐसा करने के लिए एक version.properties फ़ाइल को उसी निर्देशिका में build.gradle जैसा कि आपके build.gradle में निम्न सामग्री के साथ है: 

VERSION_MAJOR=0
VERSION_MINOR=1
VERSION_BUILD=1

(जैसा कि आप फिट देखते हैं, प्रमुख और मामूली के लिए मूल्यों को बदलना)। फिर अपने build.gradle में android सेक्शन में निम्न कोड जोड़ें: 

// Read version information from local file and increment as appropriate
def versionPropsFile = file('version.properties')
if (versionPropsFile.canRead()) {
  def Properties versionProps = new Properties()

  versionProps.load(new FileInputStream(versionPropsFile))

  def versionMajor = versionProps['VERSION_MAJOR'].toInteger()
  def versionMinor = versionProps['VERSION_MINOR'].toInteger()
  def versionBuild = versionProps['VERSION_BUILD'].toInteger() + 1

  // Update the build number in the local file
  versionProps['VERSION_BUILD'] = versionBuild.toString()
  versionProps.store(versionPropsFile.newWriter(), null)

  defaultConfig {
    versionCode versionBuild
    versionName "${versionMajor}.${versionMinor}." + String.format("%05d", versionBuild)
  }
}

जावा में BuildConfig.VERSION_NAME को एक स्ट्रिंग BuildConfig.VERSION_NAME के रूप में पूर्ण {प्रमुख} {{मामूली}। {बिल्ड} नंबर के लिए एक्सेस किया जा सकता है और केवल बिल्ड नंबर के लिए एक पूर्णांक BuildConfig.VERSION_CODE रूप में।

आउटपुट APK नाम बदलना और संस्करण नाम जोड़ना:

यह आउटपुट एप्लिकेशन फ़ाइल नाम (.apk) बदलने के लिए कोड है। नाम के लिए एक अलग मूल्य बताए द्वारा विन्यस्त किया जा सकता newName 

android {

    applicationVariants.all { variant ->
        def newName = "ApkName";
        variant.outputs.each { output ->
            def apk = output.outputFile;

            newName += "-v" + defaultConfig.versionName;
            if (variant.buildType.name == "release") {
                newName += "-release.apk";
            } else {
                newName += ".apk";
            }
            if (!output.zipAlign) {
                newName = newName.replace(".apk", "-unaligned.apk");
            }

            output.outputFile = new File(apk.parentFile, newName);
            logger.info("INFO: Set outputFile to " 
                        + output.outputFile 
                        + " for [" + output.name + "]");
        }
    }
}

छोटे एपीके फ़ाइल आकार के लिए छवि संपीड़न अक्षम करें

यदि आप सभी छवियों को मैन्युअल रूप से अनुकूलित कर रहे हैं, तो एपीटी क्रंचर को छोटे एपीके फ़ाइल आकार के लिए अक्षम करें। 

android {
    
    aaptOptions {
        cruncherEnabled = false
    }
}

ग्रेडेल का उपयोग करके प्रोगार्ड को सक्षम करें

अपने अनुप्रयोग के लिए प्रोगार्ड कॉन्फ़िगरेशन सक्षम करने के लिए आपको इसे अपने मॉड्यूल-स्तरीय ग्रेडल फ़ाइल में सक्षम करना होगा। आपको minifyEnabled के मूल्य को true पर सेट करने की आवश्यकता true । 

buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

उपरोक्त कोड आपके प्रॉडक्ट पर लागू होने वाले डिफ़ॉल्ट एंड्रॉइड एसडीके में "प्रोगार्ड-rules.pro" फाइल के साथ आपके जारी किए गए apk के साथ संयुक्त रूप से आपके प्रोफ़िगर कॉन्फ़िगरेशन को लागू करेगा।

ग्रेडल और AndroidStudio के लिए प्रयोगात्मक NDK प्लगइन समर्थन सक्षम करें

AndroidStudio के NDK समर्थन को बेहतर बनाने के लिए प्रयोगात्मक ग्रेडल प्लगइन को सक्षम और कॉन्फ़िगर करें। जाँच करें कि आप निम्नलिखित आवश्यकताओं को पूरा करते हैं:

  • 2.10 ग्रेड (इस उदाहरण के लिए)
  • Android NDK r10 या बाद का
  • निर्माण उपकरण v19.0.0 या बाद के साथ Android SDK

MyApp / build.gradle फ़ाइल कॉन्फ़िगर करें

बिल्ड से निर्भरताएँ संपादित करें ।classpath लाइन उदा। उदा 

classpath 'com.android.tools.build:gradle:2.1.2'

सेवा 

classpath 'com.android.tools.build:gradle-experimental:0.7.2'

(v0.7.2 लेखन के समय नवीनतम संस्करण था। अपने आप नवीनतम संस्करण की जाँच करें और तदनुसार अपनी पंक्ति को अनुकूलित करें)

बिल्ड.ग्रेड फ़ाइल इस तरह दिखनी चाहिए: 

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle-experimental:0.7.2'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

MyApp / app / build.gradle फ़ाइल कॉन्फ़िगर करें

निम्न उदाहरण के समान दिखने के लिए build.gradle फ़ाइल को संपादित करें। आपके संस्करण संख्या भिन्न दिख सकते हैं। 

apply plugin: 'com.android.model.application'

model {
    android {
        compileSdkVersion 19
        buildToolsVersion "24.0.1"

        defaultConfig {
            applicationId "com.example.mydomain.myapp"
            minSdkVersion.apiLevel 19
            targetSdkVersion.apiLevel 19
            versionCode 1
            versionName "1.0"
        }
        buildTypes {
            release {
                minifyEnabled false
                proguardFiles.add(file('proguard-android.txt'))
            }
        }
        ndk {
            moduleName "myLib"
            
            /* The following lines are examples of a some optional flags that 
               you may set to configure your build environment
            */ 
            cppFlags.add("-I${file("path/to/my/includes/dir")}".toString())
            cppFlags.add("-std=c++11")
            ldLibs.addAll(['log', 'm'])
            stl = "c++_static"
            abiFilters.add("armeabi-v7a")
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

सिंक करें और जांचें कि आगे बढ़ने से पहले ग्रेडल फ़ाइलों में कोई त्रुटि नहीं है।

यदि प्लगइन सक्षम है तो टेस्ट करें

पहले सुनिश्चित करें कि आपने Android NDK मॉड्यूल डाउनलोड किया है। इसके बाद AndroidStudio में एक नया ऐप बनाएं और एक्टीविमेन फाइल में निम्नलिखित जोड़ें: 

public class MainActivity implements Activity {
    onCreate() {
        // Pregenerated code. Not important here
    }
    static {
        System.loadLibrary("myLib");
    }
    public static native String getString();
}

getString() भाग को यह कहते हुए लाल रंग से हाइलाइट किया जाना चाहिए कि संबंधित JNI फ़ंक्शन नहीं मिल सका। फ़ंक्शन कॉल पर अपने माउस को तब तक घुमाएं जब तक कि लाल लाइटबुल दिखाई न दे। बल्ब पर क्लिक करें और create function JNI_... । यह सही JNI फ़ंक्शन कॉल के साथ myApp / ऐप / src / main / jni निर्देशिका में myLib.c फ़ाइल जनरेट करना चाहिए। यह इस तरह दिखना चाहिए: 

#include <jni.h>

JNIEXPORT jstring JNICALL 
Java_com_example_mydomain_myapp_MainActivity_getString(JNIEnv *env, jobject instance)     
{
    // TODO

    return (*env)->NewStringUTF(env, returnValue);
}

यदि यह ऐसा नहीं दिखता है, तो प्लगइन सही ढंग से कॉन्फ़िगर नहीं किया गया है या NDK डाउनलोड नहीं किया गया है

परियोजना के सभी कार्य दिखाएं

gradlew tasks -- show all tasks

 

Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.

Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
classes - Assembles main classes.
clean - Deletes the build directory.
compileDebugAndroidTestSources
compileDebugSources
compileDebugUnitTestSources
compileReleaseSources
compileReleaseUnitTestSources
extractDebugAnnotations - Extracts Android annotations for the debug variant into the archive file
extractReleaseAnnotations - Extracts Android annotations for the release variant into the archive file
jar - Assembles a jar archive containing the main classes.
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.
testClasses - Assembles test classes.

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code.

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'LeitnerBoxPro'.
components - Displays the components produced by root project 'LeitnerBoxPro'. [incubating]
dependencies - Displays all dependencies declared in root project 'LeitnerBoxPro'.
dependencyInsight - Displays the insight into a specific dependency in root project 'LeitnerBoxPro'.
help - Displays a help message.
model - Displays the configuration model of root project 'LeitnerBoxPro'. [incubating]
projects - Displays the sub-projects of root project 'LeitnerBoxPro'.
properties - Displays the properties of root project 'LeitnerBoxPro'.
tasks - Displays the tasks runnable from root project 'LeitnerBoxPro' (some of the displayed tasks may belong to subprojects)
.

Install tasks
-------------
installDebug - Installs the Debug build.
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
uninstallAll - Uninstall all applications.
uninstallDebug - Uninstalls the Debug build.
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
uninstallRelease - Uninstalls the Release build.

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
test - Run unit tests for all variants.
testDebugUnitTest - Run unit tests for the debug build.
testReleaseUnitTest - Run unit tests for the release build.

Other tasks
-----------
assembleDefault
clean
jarDebugClasses
jarReleaseClasses
transformResourcesWithMergeJavaResForDebugUnitTest
transformResourcesWithMergeJavaResForReleaseUnitTest

स्वचालित रूप से "अन-डिजाइन" APK हटाएं

आप के साथ स्वचालित रूप से उत्पन्न APK फ़ाइलों की जरूरत नहीं है unaligned प्रत्यय (जो आप शायद नहीं है), तो आपको निम्न कोड को जोड़ सकते हैं build.gradle फ़ाइल: 

// delete unaligned files
android.applicationVariants.all { variant ->
  variant.assemble.doLast {
    variant.outputs.each { output ->
        println "aligned " + output.outputFile
        println "unaligned " + output.packageApplication.outputFile

        File unaligned = output.packageApplication.outputFile;
        File aligned = output.outputFile
        if (!unaligned.getName().equalsIgnoreCase(aligned.getName())) {
            println "deleting " + unaligned.getName()
            unaligned.delete()
        }
    }
  }
}

यहाँ से

बिल्ड वैरिएंट की अनदेखी

कुछ कारणों से आप अपने बिल्ड वेरिएंट को अनदेखा करना चाह सकते हैं। उदाहरण के लिए: आपके पास 'नकली' उत्पाद स्वाद है और आप इसका उपयोग केवल डिबग उद्देश्यों के लिए करते हैं, जैसे इकाई / इंस्ट्रूमेंटेशन परीक्षण।

आइए हमारी परियोजना से मॉकड्रिल वेरिएंट को अनदेखा करें। Build.gradle फ़ाइल खोलें और लिखें: 

    // Remove mockRelease as it's not needed.
    android.variantFilter { variant ->
        if (variant.buildType.name.equals('release') && variant.getFlavors().get(0).name.equals('mock')) {
            variant.setIgnore(true);
        }
    }

निर्भरता का पेड़ देखना

कार्य निर्भरता का उपयोग करें। आपके मॉड्यूल कैसे सेट किए जाते हैं, इस पर निर्भर करते हुए, यह या तो हो सकता है ./gradlew dependencies या मॉड्यूल ऐप उपयोग की निर्भरताएँ देखने के लिए ./gradlew :app:dependencies

निम्न निर्माण build.gradle फ़ाइल का उदाहरण है 

dependencies {
    compile 'com.android.support:design:23.2.1'
    compile 'com.android.support:cardview-v7:23.1.1'

    compile 'com.google.android.gms:play-services:6.5.87'
}

निम्नलिखित ग्राफ का उत्पादन करेगा: 

Parallel execution is an incubating feature.
:app:dependencies

------------------------------------------------------------
Project :app
------------------------------------------------------------
. . .
_releaseApk - ## Internal use, do not manually configure ##
+--- com.android.support:design:23.2.1
|    +--- com.android.support:support-v4:23.2.1
|    |    \--- com.android.support:support-annotations:23.2.1
|    +--- com.android.support:appcompat-v7:23.2.1
|    |    +--- com.android.support:support-v4:23.2.1 (*)
|    |    +--- com.android.support:animated-vector-drawable:23.2.1
|    |    |    \--- com.android.support:support-vector-drawable:23.2.1
|    |    |         \--- com.android.support:support-v4:23.2.1 (*)
|    |    \--- com.android.support:support-vector-drawable:23.2.1 (*)
|    \--- com.android.support:recyclerview-v7:23.2.1
|         +--- com.android.support:support-v4:23.2.1 (*)
|         \--- com.android.support:support-annotations:23.2.1
+--- com.android.support:cardview-v7:23.1.1
\--- com.google.android.gms:play-services:6.5.87
     \--- com.android.support:support-v4:21.0.0 -> 23.2.1 (*)

. . .

यहां आप देख सकते हैं कि परियोजना सीधे com.android.support:design संस्करण 23.2.1 सहित है, जो स्वयं com.android.support:support-v4 संस्करण 23.2.1 के साथ ला रही है। हालाँकि, com.google.android.gms:play-services में एक ही support-v4 पर निर्भरता होती है, लेकिन पुराने वर्जन 21.0.0 के साथ, जो कि एक कंफर्टल द्वारा डिटेक्ट किया गया संघर्ष है।

(*) का उपयोग तब किया जाता है जब प्रवण सूक्ष्मता को छोड़ देता है क्योंकि वे निर्भरताएं पहले से ही पहले से सूचीबद्ध थीं।

केंद्रीय संस्करण / बिल्डकॉनफिगुरेशन के लिए gradle.properties का उपयोग करें

आप केंद्रीय कॉन्फ़िगरेशन जानकारी को परिभाषित कर सकते हैं

या यह रूट gradle.properties फ़ाइल के साथ करते हैं

परियोजना संरचना 

root
  +- module1/
  |     build.gradle
  +- module2/
  |     build.gradle
  +- build.gradle
  +- gradle.properties

gradle.properties में सभी सबमॉड्यूल के लिए वैश्विक सेटिंग 

# used for manifest
# todo increment for every release
appVersionCode=19
appVersionName=0.5.2.160726

# android tools settings
appCompileSdkVersion=23
appBuildToolsVersion=23.0.2

एक सबमॉड्यूल में उपयोग 

apply plugin: 'com.android.application'
android {
    // appXXX are defined in gradle.properties
    compileSdkVersion = Integer.valueOf(appCompileSdkVersion)
    buildToolsVersion = appBuildToolsVersion

    defaultConfig {
        // appXXX are defined in gradle.properties
        versionCode = Long.valueOf(appVersionCode)
        versionName = appVersionName
    }
}

dependencies {
    ...
}

नोट: यदि आप अपने ऐप को F-Droid ऐप स्टोर में प्रकाशित करना चाहते हैं, तो आपको gradle फ़ाइल में मैजिक नंबरों का उपयोग करना होगा क्योंकि f-droid रोबोट वर्जन परिवर्तनों का पता लगाने / सत्यापित करने के लिए वर्जन वर्मनमीटर नहीं पढ़ सकता है।

हस्ताक्षर करने की जानकारी प्रदर्शित करें

कुछ परिस्थितियों में (उदाहरण के लिए Google API कुंजी प्राप्त करने के लिए) आपको अपना कीस्टोर फिंगरप्रिंट खोजने की आवश्यकता है। ग्रैडल के पास एक सुविधाजनक कार्य है, जो किस्टोर फिंगरप्रिंट सहित सभी हस्ताक्षरित जानकारी प्रदर्शित करता है: 

./gradlew signingReport

यह एक नमूना आउटपुट है: 

:app:signingReport
Variant: release
Config: none
----------
Variant: debug
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: debugAndroidTest
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: debugUnitTest
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: releaseUnitTest
Config: none
----------

बिल्ड प्रकार परिभाषित करना

आप android {} ब्लॉक के अंदर मॉड्यूल-स्तर build.gradle फ़ाइल में बिल्ड प्रकार बना और कॉन्फ़िगर कर सकते हैं। 

    android {
        ...
        defaultConfig {...}
    
        buildTypes {
            release {
                minifyEnabled true
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }
    
            debug {
                applicationIdSuffix ".debug"
            }
        }
    }


Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow