3、Basic Project（基本项目）

一个Gradle项目的构建过程定义在build.gradle文件中，位于项目的根目录下。

3.1 Simple build files（简单的构建文件）

一个最简单的Gradle纯Java项目的build.gradle文件包含以下内容：

    apply plugin: 'java'

    buildscript {
        repositories {
            mavenCentral()
        }

        dependencies {
            classpath 'com.android.tools.build:gradle:0.11.1'
        }
    }

    apply plugin: 'android'

    android {
        compileSdkVersion 19

        buildToolsVersion "19.0.0"

    }

3.2 Project Structure（项目结构）

上面提到的基本的构建文件需要一个默认的文件夹结构。Gradle遵循约定优先于配置的概念，在可能的情况尽可能提供合理的默认配置参数。

基本的项目开始于两个名为“source sets”的组件，即main source code和test code。它们分别位于：
    * src/main/
    * src/androidTest/
里面每一个存在的文件夹对应相应的源组件。
对于Java plugin和Android plugin来说，它们的Java源代码和资源文件路径如下：
    * java/
    * resources/
但对于Android plugin来说，它还拥有以下特有的文件和文件夹结构：
    * AndroidManifest.xml
    * res/
    * assets/
    * aidl/
    * rs/
    * jni/
注意：src/androidTest/AndroidManifest.xml是不需要的，它会自动被创建。

3.2.1 Configuring the Structure（配置项目结构）

当默认的项目结构不适用的时候，你可能需要去配置它。根据Gradle文档，重新为Java项目配置sourceSets可以使用以下方法：

    sourceSets {
        main {
            java {
                srcDir 'src/java'

            }

            resources {

                srcDir 'src/resources'

            }

        }
    }

    sourceSets {
        main.java.srcDirs = ['src/java']
        main.resources.srcDirs = ['src/resources']
    }

    android {
        sourceSets {
            main {
                manifest.srcFile 'AndroidManifest.xml'
                java.srcDirs = ['src']

                resources.srcDirs = ['src']
                aidl.srcDirs = ['src']

                renderscript.srcDirs = ['src']

                res.srcDirs = ['res']
                assets.srcDirs = ['assets']

            }


            androidTest.setRoot('tests')
        }
    }

以上也是将旧构建系统项目迁移到新构建系统需要做的迁移工作。

3.3 Build Tasks（构建任务）

3.3.1 General Tasks（通用任务）

添加一个插件到构建文件中将会自动创建一系列构建任务(build tasks)去执行（注：gradle属于任务驱动型构建工具，它的构建过程是基于Task的）。Java plugin和Android plugin都会创建以下task：
    * assemble：这个task将会组合项目的所有输出。
    * check：这个task将会执行所有检查。
    * build：这个task将会执行assemble和check两个task的所有工作
    * clean：这个task将会清空项目的输出。
实际上assemble，check，build这三个task不做任何事情。它们只是一个Task标志，用来告诉android plugin添加实际需要执行的task去完成这些工作。

这就允许你去调用相同的task，而不需要考虑当前是什么类型的项目，或者当前项目添加了什么plugin。
例如，添加了findbugs plugin将会创建一个新的task并且让check task依赖于这个新的task。当check task被调用的时候，这个新的task将会先被调用。

在命令行环境中，你可以执行以下命令来获取更多高级别的task：

    gradle tasks

    gradle tasks --all

3.3.2 Java project tasks（Java项目的Task）

Java plugin主要创建了两个task，依赖于main task（一个标识性的task）：
    * assemble
        * jar：这个task创建所有输出
    * check
        * test：这个task执行所有的测试。
jar task自身直接或者间接依赖于其他task：classes task将会被调用于编译java源码。
testClasses task用于编译测试，但是它很少被调用，因为test task依赖于它（类似于classes task）。

通常情况下，你只需要调用到assemble和check，不需要其他task。

你可以在Gradle文档中查看java plugin的全部task。

3.3.3 Android tasks

Android plugin使用相同的约定以兼容其他插件，并且附加了自己的标识性task，包括：
    * assemble：这个task用于组合项目中的所有输出。
    * check：这个task用于执行所有检查。
    * connectedCheck：这个task将会在一个指定的设备或者模拟器上执行检查，它们可以同时在所有连接的设备上执行。
    * deviceCheck：通过APIs连接远程设备来执行检查，这是在CL服务器上使用的。
    * build：这个task执行assemble和check的所有工作。
    * clean：这个task清空项目的所有输出。
这些新的标识性task是必须的，以保证能够在没有设备连接的情况下执行定期检查。
注意build task不依赖于deviceCheck或者connectedCheck。

一个Android项目至少拥有两个输出：debug APK（调试版APK)和release APK（发布版APK）。每一个输出都拥有自己的标识性task以便能够单独构建它们。
    * assemble：
        * assembleDebug
        * assembleRelease
它们都依赖于其它一些tasks以完成构建一个APK需要多个步骤。其中assemble task依赖于这两个task，所以执行assemble将会同时构建出两个APK。

小提示：gradle在命令行终端上支持骆驼命名法的task简称，例如，执行gradle aR命令等同于执行gradle assembleRelease。

check task也拥有自己的依赖：
    * check：
        * lint
    * connectedCheck：
        * connectedAndroidTest
        * connectedUiAutomatorTest(目前还没有应用到）
    * deviceCheck: 这个test依赖于test创建时，其它实现测试扩展点的插件。

最后，只要task能够被安装（那些要求签名的task），android plugin就会为所有构建类型（debug，release，test）安装或者卸载。

3.4 Basic Build Customization（基本的构建定制）

Android plugin提供了大量DSL用于直接从构建系统定制大部分事情。

3.4.1 Manifest entries （Manifest属性）

通过SDL可以配置一下manifest选项：
    * minSdkVersion
    * targetSdkVersion
    * versionName
    * packageName
    * package Name for the test application
    * Instrumentation test runner
例如：

    android {
        compileSdkVersion 19

        buildToolsVersion "19.0.0"


        defaultConfig {
            versionCode 12

            versionName "2.0"

            minSdkVersion 16
            targetSdkVersion 16
        }
    }

    def computeVersionName() {
        ...
    }

    android {
        compileSdkVersion 19
        buildToolsVersion "19.0.0"

        defaultConfig {
            versionCode 12
            versionName computeVersionName()
            minSdkVersion 16
            targetSdkVersion 16
        }
    }

如果一个属性没有使用DSL进行设置，一些默认的属性值将会被使用。以下表格是可能使用到的值：

    if (android.defaultConfig.testInstrumentationRunner == null) {
        // assign a better default...
    }

3.4.2 Build Types（构建类型）

    android {
        buildTypes {
            debug {
                applicationIdSuffix ".debug"

            }

            jnidebug.initWith(buildTypes.debug)
            jnidebug {
                packageNameSuffix ".jnidebug"
                jnidebugBuild true
            }
        }
    }

以下是一些可能使用到的属性和默认值：

    src/<buildtypename>/

    android {
        sourceSets.jnidebug.setRoot('foo/jnidebug')
    }

3.4.3 signing configurations（签名配置）

    android {
        signingConfigs {
            debug {
                storeFile file("debug.keystore")
            }

            myConfig {
                storeFile file("other.keystore")
                storePassword "android"
                keyAlias "androiddebugkey"
                keyPassword "android"
            }
        }

        buildTypes {
            foo {
                debuggable true
                jniDebugBuild true
                signingConfig signingConfigs.myConfig
            }
        }
    }

3.4.4 Running Proguard（运行 Proguard）

android {
    buildTypes {
        release {
            runProguard true
            proguardFile getDefaultProguardFile('proguard-android.txt')
        }
    }

    productFlavors {
        flavor1 {
        }
        flavor2 {
            proguardFile 'some-other-rules.txt'
        }

    }
}