Gradle的Android插件

Android构建系统由一个Gradle的Android插件组成。 Gradle是一个高级的构建工具集，它能够管理依赖，并使你可以定义定制化的构建逻辑。Android Studio使用了一个Gradle包装器来完整地集成Gradle的Android插件。Gradle的Android插件也能够独立于Android Studio而运行。这意味着你能够用Android Studio构建你的Android apps，也能够从你机器的命令行或没有安装Android Studio的机器上构建你的Android apps(好比持续集成服务器)。

不管你是使用命令行，远程主机仍是Android Studio来构建一个项目，构建的输出都相同。

构建配置(Build Configuration)

你的项目的构建配置(build configuration)在build.gradle文件里定义，它们都是使用Gradle语法和选项及Android插件的纯文本文件，它们配置了你的构建的以下几个方面：

Build variants。构建系统能够为相同的模块，根据不一样的产品及构建配置产生多个APKs。当你想要构建你的应用程序的不一样版本时这颇有用，它使你不须要为每一个版本建立一个不一样的项目或模块。

依赖。构建系统管理项目依赖，并支持对本地文件系统及远程仓库的依赖。这使你能够再也不不得不搜索，下载，复制你依赖的二进制包到你的项目。

Manifest entries。构建系统使你可以在build variant配置中指定manifest文件的某些元素的值。这些构建值会覆盖manifest文件里的已有值。若是你想要为你的模块产生多个APKs这颇有用，其中每一个apk文件具备一个不一样的应用程序名称，最小SDK版本，或目标SDK版本。当有多个manifests出现时，manifest设定以buildType和productFlavor，/main manifest，和library manifests的优先级进行合并。

签名。构建系统使你可以在构建配置中指定签名设定，它还能够在构建过程当中签名你的APKs。

ProGuard。构建系统使你可以为每一个build variant指定一个不一样的ProGuard规则文件。构建系统能够在构建过程当中运行ProGuard来混淆你的类。

测试。对于大多数的模板，构建系统建立一个测试目录，androidTest并由你的项目的测试代码产生一个测试APK，于是你不须要建立一个单独测试项目。构建系统还能在构建过程当中运行你的测试。

Gradle构建文件使用了领域特定语言(Domain Specific Language，DSL)经过Groovy语法来描述和控制构建逻辑。Groovy是一个动态语言，你能够用它定义定制的构建逻辑，及与Gradle的Android插件所提供的Android特有元素进行交互。

按照惯例构建(Build by Convention)

Android Studio构建系统对于项目的结构及其它构建选项的预设行为有一些假定。若是你的项目符合这些惯例，你的Gradle构建文件将很是简单。当这些惯例中的一些不适用于你的项目时，构建系统的灵活性使你可以配置构建过程的几乎每一个方面。好比，若是你须要替换你的模块目录里的默认源码文件夹，你能够在模块的构建文件(build file)中配置一个新的目录结构。

项目和模块设定

Android Studio里的一个project，表明最顶层的Android开发结构。Android Studio工程包含工程文件和一个或多个应用程序模块。一个模块是你app的一个组件，你能够独立地对它进行构建，测试或调试。模块包含你的apps的源代码和资源。Android Studio工程能够包含多种模块：

Android应用程序模块包含应用程序(mobile，TV，Weat，Glass)代码，它可能依赖于库模块(library modules)，尽管许多Android apps只由一个应用程序模块组成。构建系统会为应用程序模块产生APK包。

Android库模块包含可复用的Android特有代码和资源。构建系统会为库模块产生一个AAR(Android ARchive)包。

App引擎模块包含App引擎集成的代码和资源。

Java库模块包含可复用的代码。构建系统会为Java库模块产生一个JAR包。

Android Studio工程包含一个顶层的Gradle构建文件，它使你能够为工程里的全部应用程序模块添加共用的配置选项。每一个应用程序模块又有它本身build.gradle文件，来进行那个模块特有的构建设定。

工程构建文件

默认状况下，工程级的Gradle文件使用buildscript元素来定义Gradle仓库(repositories)和依赖(dependencies)。这使得不一样的工程可使用不一样的Gradle版本。支持的仓库包括JCenter，Maven Central，或Ivy。这个例子声明构建脚本使用JCenter仓库，及一个包含1.0.1版Gradle的Android插件的classpath dependency artifact。

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

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

allprojects {
   repositories {
       jcenter()
   }
}

注意：Android Studio工程的SDK位置由local.properties文件里的sdk.dir设定设置，或经过ANDROID_HOME环境变量设置。

模块构建文件

应用程序模块Gradle构建文件使你可以配置模块构建设定，这包括覆盖src/main manifest设定，及设置定制的打包选项。

android settings

• compileSdkVersion
• buildToolsVersion

defaultConfig和productFlavors

• manifest属性，好比applicationId，minSdkVersion，targetSdkVersion，和测试信息。

buildTypes

• 构建属性，好比debuggable, ProGuard开关，debug签名，version name 后缀和testinformation。

dependencies

这个例子应用Android插件，使用默认的配置来覆盖多个manifest属性，建立两个build types：release和debug，并声明了一些依赖：

apply plugin: 'com.android.application'

android {
    compileSdkVersion 20
    buildToolsVersion "20.0.0"

    defaultConfig {
        applicationId "com.mycompany.myapplication"
        minSdkVersion 13
        targetSdkVersion 20
        versionCode 1
        versionName "1.0"
    }

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

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:20.0.0'
    compile project(path: ':app2, configuration: 'android-endpoints')
}

注意：你能够为属性值注入定制的构建逻辑，属性值由一个函数定义，而函数又会被属性调用，好比：

def computeVersionName() {
  ...
}

android {
    defaultConfig {
        versionName computeVersionName()
        ...
    }
}

依赖

Android Studio构建系统可以管理工程依赖，它支持模块依赖，本地二进制依赖，和远程二进制依赖。

模块依赖

一个应用程序模块能够在它的构建文件中包含一个它所依赖的其它模块的列表。当构建这个模块的时候，构建系统会聚集并包含这些须要的模块。

本地依赖

若是一个模块依赖于你本地文件系统中已有的二进制包，好比JAR文件，你能够为那个模块在构建文件中声明这种依赖。

远程依赖

当你的某些依赖能够在一个远程仓库中得到时，你就不须要下载它们并把它们复制到你的工程里了。Android Studio构建系统支持仓库的远程依赖，好比Maven，和依赖管理器，好比Ivy。

许多流行的软件库和工具均可以在公共的Maven仓库中得到。对于这些依赖，你只须要指定它们的Maven坐标便可，Maven坐标能够惟一地标识一个远程仓库中的每个元素。构建系统中使用的Maven坐标的格式为group:name:version。好比16.0.1版的Google Guava库的Maven坐标为com.google.guava:guava:16.0.1。

Maven Central Repository被普遍地用于分发多种库和工具。

Build Tasks

Android Studio构建系统定义了一个build tasks的分层集合：顶层的或祖先的tasks调用它依赖的tasks来处理它的集合构建输出。顶层的build tasks有：

assemble

• 构建工程输出。

check

• 执行检查和测试。

build

• assemble和check都执行。

clean

• 执行清理动做。

Android插件提供了connectedCheck和deviceCheck tasks来在connected，emulated，和remote devices时执行检查。能够经过点击右侧的Gradle标签查看Gradle tasks。

你能够在Android Studio或在命令行中查看全部可用tasks的列表并调用其中的任何一个，正如Building and Running from Android Studio和Build the project from the command line中所描述的那样。

Gradle包装器

Android Studio工程包含有Gradle包装器，它由以下几部分组成：

• 一个JAR文件
• 一个属性文件
• 一个Windows平台的shell脚本
• 一个Mac和Linux平台的shell脚本

注意：你应该把全部这些文件都提交到你的源码版本控制系统里。

使用Gradle包装器(而不是本地安装的Gradle)能够确保你可以老是运行local.properties文件中定义Gradle版本。要配置你的工程使用一个更新的Gradle版本，只须要修改属性文件并指定一个新的版本便可。

Android Studio从你工程里的Gradle包装器目录下读取属性文件，并在这个目录运行包装器，这样你就能够无障碍地同时工做于多个须要不一样Gradle版本的工程上了。

注意：Android Studio不使用shell脚本，于是当你用IDE进行构建时，你对shell脚本作的任何修改都不会起做用。你应该转经过Gradle构建文件来定制你的构建逻辑。

你能够在开发机或其它没有安装Android Studio的机器的命令行中运行shell脚原本构建你的工程。

注意：当你建立一个工程时，请只使用来自于一个可靠来源的Gradle包装器脚本和JAR文件，好比Android Studio产生的那些。

Build Variants

在构建系统中，你的app的每一个版本由一个build variant表示。Build variants是product flavors和build types的组合。Product flavors表示一个app的产品构建版本，好比免费版和付费版。Build types表明为每一个app包产生的构建打包版本，好比debug和release。构建系统会为每一个product flavors和build types的组合产生APKs。

默认状况下，Android Studio定义了默认的配置设定，在build.gradle文件中的defaultConfig，及两个build types (debug和release)。这将建立两个build variants，debug和release，构建系统将会为每一个variant产生一个APK。

在默认的build types debug和release存在的同时，添加两个product flavors，demo和full将产生四个build variants，每一个都有它本身的定制配置：

• demoDebug
• demoRelease
• fullDebug
• fullRelease
• 基于buildType, 和productFlavor构建设定的Build variants
• 主sourceSet，一般位于src/main/res
• Library Project依赖，经过它们的aar bundle中的res entry提供资源。

按优先级从低到高的合并顺序为libraries/dependencies -> main src -> productFlavor -> buildType。

某些工程具备复杂的多维度的功能组合，但它们仍然表示相同的app。好比，除了有app的demo和full版本以外，某些游戏可能包含特定于一个特别的CPU/ABI的二进制文件。构建系统的灵活性使得为一个工程产生以下的这些build variants成为可能：

• x86-demoDebug
• x86-demoRelease
• x86-fullDebug
• x86-fullRelease
• arm-demoDebug
• arm-demoRelease
• arm-fullDebug
• arm-fullRelease
• mips-demoDebug
• mips-demoRelease
• mips-fullDebug
• mips-fullRelease

这个工程将由两个build types (debug和release)和二维的product flavors组成，二维中的一个维度是app type (demo或full)，另外一个是CPU/ABI(x86, ARM, or MIPS)。

源码目录

要构建你的app的每一个版本，构建系统将结合以下这些目录里的源码和资源：

src/main/ - 主源码目录(全部variants共用的默认配置)

src/<buildType>/ - 源码目录

src/<productFlavor>/ - 源码目录

注意：build type和product flavor源码目录是可选的，于是Android Studio不会为你建立这些目录。你应该在给构建配置文件添加build type和product flavor时建立这些目录。若是这些目录不存在，则构建系统将不使用它们。

对于那些没有定义任何flavors的工程，构建系统使用defaultConfig设定，主app目录和默认的build type目录。好比，要在工程中没有product flavors的状况下产生默认的debug和release build variants，构建系统使用：

• src/main/ (默认配置)
  
• src/release/ (build type)
  
• src/debug/ (build type)

对于那些定义了一系列product flavors的工程，构建系统则合并build type，product flavor和主源码目录。好比，要产生full-debug build variant，构建系统合并build type，product flavor和主源码目录：

• src/main/ (默认配置)
• src/debug/ (build type)
• src/full/ (flavor)

对于那些使用了多个flavor维度的工程，针对每一个维度构建系统合并一个flavor源码目录。好比，要产生arm-demo-release build variant，构建系统合并：

• src/main/ (默认配置)
• src/release/ (build type)
• src/demo/ (flavor - app type dimension)
• src/arm/ (flavor - ABI dimension)

这些目录下的源代码会被一块儿用来为一个build variant产生输出。你能够在那些不会被用在相同variant的不一样目录下包含具备相同名字的类。

构建系统也会把全部的manifests合并为一个单独的manifest，从而每一个build variant能够在最终的manifest中定义不一样的组件或权限。manifests合并的优先级从低到高排列为libraries/dependencies -> main src -> productFlavor -> buildType。

构建系统合并全部源码目录下的全部资源。若是同一个build variant的不一样文件夹中包含了具备相同名字的资源，则优先级顺序以下：build type资源覆盖product flavor的那些资源，product flavor资源覆盖主源码目录下的资源，主源码目录下的资源覆盖库的资源。

注意：Build variants使你可以在你的app的不一样版本间复用共用的activities，应用程序逻辑，和资源。

Done。

原文。