Several build.gradle files of android studio

Android Studio uses Gradle to build projects. An Android project contains two build.gradle files, as shown in the figure below:

(1) The build.gradle file in
　　the in the outermost directory is as follows:

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

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

　　Ignoring the syntax we don't understand, literally we can see that the key has two parts of code, the repositories closure and the dependencies closure.
1. Repositories closure
　　The configuration of jcenter() is declared in the closure, where jcenter is a code hosting repository that hosts many Android open source projects. After configuring jcenter here, we can easily refer to the open source projects on jcenter in the project.
2. Dependencies closure
　　The closure uses classpath to declare a Gradle plugin. Since Gradle is not only used to build Android projects, relevant plugins are introduced here to build Android projects, where '2.2.2' is the version number of the plugin , which can be adjusted according to the latest version number.
(2) The build.gradle file in the module directory The contents of the build.gradle file under the app module in the
project are as follows:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion "25.0.2"
    defaultConfig {
        applicationId "com .wkui.douban.easysearch"
        minSdkVersion 15
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"



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

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android .support:appcompat-v7:25.2.0'
    testCompile 'junit:junit:4.12'
}

　　As can be seen from the content of the file, it is mainly divided into three parts:
1.
　　The first line in the apply plugin file uses apply plugin to indicate that a Plug-in, the plug-in generally has two optional values:
one is 'com.android.application', indicating that the module is an application module and can be run directly; the other is 'com.android.library', indicating that the module It is a library module and can only be run as a code library attached to other application modules.
2, android closure
　　This closure is mainly used to configure various properties of the project construction, compileSdkVersion is used to specify the compiled version of the project, 25 means to use the SDK of the Android 7.1 system to compile. buildToolsVersion is used to specify the version of the project build tools. The defaultConfig closure and buildTypes closure are nested in the android closure:
1) defaultConfig
　　closure Configure more details of the project, where applicationId specifies the package name of the project, we can modify the package name of the project by modifying this value .
　　minSdkVersion specifies the minimum compatible version of the project, which is specified as 15 here, indicating that the minimum compatible version is Android 4.0.
　　The value specified by targetSdkVersion indicates that the target version has been fully tested, and the system will activate some of the latest features corresponding to the target system for the application. The behavior of the Android system platform is changed. Only the attribute value of targetSdkVersion is set to be greater than or equal to The API version of the system platform will only take effect. For example, if the specified targetSdkVersion value is 22, it means that the program has only been fully tested on the Android 5.1 version at most, and the new features such as system runtime permissions on the Android 6.0 system (corresponding to targetSdkVersion of 23) are not will not be enabled.
2) buildTypes closure
　　This closure mainly specifies the main configuration for generating the installation file, and generally contains two sub-closures, one is the debug closure, which is used to specify the configuration for generating the beta version installation file, which can be ignored and not written; the other is release Closure, used to specify the configuration to generate the official version of the installation file.
　　In the above code, the content of the debug closure is omitted, and only the release closure is written. Among them, minifyEnabled indicates whether to obfuscate the code, and true indicates to obfuscate the code. proguardFiles specifies the obfuscated rule file. Here, two files, the proguard-android.txt file and the proguard-rules.pro file, are specified. The proguard-android.txt file is the default obfuscation file, which defines some general obfuscation rules. The proguard-rules.pro file is located in the root directory of the current project, and some project-specific obfuscation rules can be defined in this file.
3. Dependencies Closure
　　This closure defines the dependencies of the project. Generally, projects have three dependencies: local dependencies, library dependencies and remote dependencies. Local dependencies can add dependencies to local jar packages or directories, library dependencies can add dependencies to library modules in the project, and remote dependencies can add dependencies to open source projects on the jcener library.
　　The statements defined in the closure are explained below.
　　The compile fileTree in the first line is a local dependency declaration, which means that all files with the .jar suffix in the libs directory are added to the build path of the project.
　　The compile statement in the second line is a remote dependency declaration, 'com.android.support:appcompat-v7:25.2.0' is a standard remote dependency library format, and com.android.support is the domain name part, which is used to distinguish different companies library; appcompat-v7 is the component name, used to distinguish different libraries of the same company; 25.2.0 is the version number, used to distinguish different versions of the same library. After adding this statement, Gradle will first check whether the library has been cached locally when building the project. If there is no cache, it will be automatically downloaded online, and it will be automatically added to the project's build path after downloading.
　　The testCompile statement is used to declare the test case library and is not used for the time being. The library dependency declaration is not used here. If there is a library module named helper, then adding the library dependency needs to add the statement compile project(':helper').

Author: sunnygarden
Link: http://www.jianshu.com/p/9c27dd7938b7
Source: Jianshu The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.