我只是技术搬运工，如果搬运有误，请不吝指出，谢谢

Android的Gradle插件

Android的编译系统包含了Gradle插件。Gradle是一个先进的构建工具包，它可以管理依赖，并允许你定义自己的构建逻辑。Android Studio 使用一个Gradle的包装来完全整合Gradle插件。Android的Gradle插件也可以独立于Android Studio运行。这样就意味着，你可以从装有Android Studio的机器的命令行或者是从没有安装Android Studio的机器上(比如持续集成服务器)构建你的Android apps。

构建配置

你项目的构建配置文件是build.gradle文件，它是一个纯文本文件，使用了Gradle的语法和选项，Android插件为你的构建配置如下几个方面：

构建变种(Build Variants)。这个构建系统可以生成不同产品的APK，并且可以为相同的模块配置不同的配置。当你想为你的应用构建不同的版本，但是又不想为不同的版本创建不同的项目或模块，这是非常有用的。

依赖(Dependencies)。这个构建系统可以管理项目的以来，并且支持依赖本地系统文件和运程仓库。这样可以免去了手工的为你的项目收索，下载，拷贝相应的包文件。

清单条目(Manifest entries)。这个构建系统可以让你使用构建变量的配置来指定manifest文件元素的值。这些构建变量的值覆盖了manifest文件的值。这是有用的，如果你想为你的多个某块生成多个APK，这样每个APK可以有不同的名字，minimum SDK版本，或者是target SDK版本。如果多个manifest文件存在，将被合并到优先的buildType和productFlavor, /main文件，和library的manifest中。

签名。 构建系统可以让你指定特定的签名设置。它可以在构建的过程中自动对你的APK进行签名。

ProGuard.构建系统可以让你为各自的变体(bariant)指定特定不同的ProGuard。在构建的过程中构建系统将执行ProGuard从而混淆你的class.

测试.对于大多数模板，构建系统创建一个测试目录(androidTest),并且生成一个测试的APK。所以你不需要单独创建一个测试项目。构建系统在构建过程中将会运行测试代码。

Gradle构建文件通过Groovy语法的领域特定语音来描述和操纵构建逻辑。Groovy是一种动态语音，可以自定义构建逻辑，并且和Gradle插件提供的特定元素进行交互。

通过公约构建

Android 构建系统为项目结构和其他构建项预制了智能的默认值。如果你的项目是按照这些公约来的，你的Gradle构建文件将非常简单。当一些公约不适合你的项目的时候，构建系统的灵活性将允许你配置构建过程每个方面。例如，你需要替换模块目录默认的源码目录文件，你可以在模块构建文件中指定一个新的目录结构。

项目和模块设置

在Android Stuidio的表现中，一个项目(Project)是开发结构的顶层结构。Android Studio的项目包含了项目文件和一个或多个应用模块。一个模块是你应用的一个组件，你可以独立地构建，测试，bebug。模块包含了你应用的源码和资源文件。Android Studio项目可以包含多种模块。

Android 库模块包含了可复用的代码和资源。构建系统将为库模块生成AAR包。

App Engine 模块包含了App Engine 继承的代码和资源。

java 库模块包含了可复用的代码。构建系统生成了Jar包。

Android Studio项目包含了一个顶层项目的Gradle配置文件，它允许你为所有在项目中的应用模块配置常用的配置。每个应用模块还有自己用用的build.gradle文件为了配置特定的配置项。

项目构建文件

默认的，项目级的Gradle文件使用buildscript来定义Gradle的仓库和依赖。这样允许不同的项目使用不同的Gradle版本。支持的仓库包括：JCenter,Maven,Central,lvy。这个例子声明了使用JCenter仓库和使用了1.0.1版本的Gradle插件的类路径依赖结构的构建脚本。

注： Android Studio项目的SDK位置被定义在local.properties文件的sdk.dir设置中，或者是通过环境变量ANDROID_HOME.

模块构建文件

应用模块的Gradle构建文件允许你配置模块的构建设置，包括覆盖 src/main中的manifest设置和设置自定义的包选项。

android 设置

         compileSdkVersion

         buildToolsVersion

defaultConfig 和 productFlavors

         manifest的属性，如 applicationId,minSdkVersion,targetSdkVersion和测试信息。

buildTypes

         构建属性，如debuggable,ProGuard,debug签名，版本名后缀，和测试信息。

dependencies

这个例子应用了Android插件，使用了默认的配置用来覆盖几个manifest的属性，创建了两个构建类型：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构建系统管理了项目的依赖，并且支持模块依赖，二进制依赖，和运程二进制依赖。

模块依赖

         一个应用模块可以包含其他模块的依赖在它的构建文件中。当你构建这个模块的时候，构建系统将装配它需要的模块。

本地依赖

         如果在你的本地系统中，有你模块依赖的存档文，如JAR文件，你可以在你的模块构建文件中声明依赖。

运程依赖

         当一些运程仓库的依赖是有效的，你不需要必须下载和拷贝它们到你的项目中。Android Studio构建系统支持运程仓库依赖，比如 Maven, 依赖管理，如: lvy。

         许多流行的软件库和工具在公共Maven仓库是有效的。对于这些依赖，你只需要指定Maven的坐标，这是唯一标示远程仓库每个元素。在构建系统中，Maven坐标的格式是：group:name:version。比如，16.0.1版本的Google Guava库的Maven坐标是： com.google.guava:guava:16.0.1.

         Maven中央仓库广泛的用来分发许多库和工具。

构建任务

Android Studio的构建系统定义了一个分层的构建任务集合：顶层或 anckor 任务调用依赖任务产生他们的集合构造输出。顶层构建任务是：

assemble

         构造项目输出

check

         运行检查和测试

build

         运行 assemble 和 check

clean

         执行clean。

Android插件提供了connectedCheck和deviceCheck任务用来检查 连接的模拟的远程的设备。Gradle任务可以通过点击右边距的Gradle选项卡来查看。

你可以看到有效任务的类表，并且可以从Android Studio和命令行执行任何任务，就像 Building and Running from Android Studio 和Build the project from the command line中描述的。

Gradle包装

Android Studio的项目包含了Gradle包装，包含了：

一个JAR文件

一个属性文件

一个Windows平台的Shell脚本

一个Linux平台的Shell脚本

注：你应该将这些文件都提交到你的源码控制系统中。

使用Gradle包装(而不是使用本地安装的Gradle)可以确保你一直运行在local.properties文件中定义的Gradle版本。如果你咬为你的项目配置一个新版本的Gradle，编辑这个属性文件。

Android Studio从你项目的Gradle包装目录中读取属性文件，并且从这个目录中运行这个包装，因此你可以可以对多个要求不同版本Gradle的项目进行无缝工作。

注： Android Studio不用Shell脚本，因此当从IDE中构建是，你对其的改变不会起任何作用。你可以在Gradle的构建文件中定义自己的逻辑。

你可以在没有安装Android Studio的机器上，从命令行中执行这些脚本，从而构建你的项目。

注意：当你创建一个项目是，只能使用从可行任来源的Gradle包装脚本和JAR包，像由Android Studio生成的。

构建变种

你应用的没个版本在构建系统中表现为一个构建变量。构建变量是由项目flavors和构建类型组成。项目flavors代表了一个应用的构建版本，如免费和付费。 构建类型代表了每个应用构建包的版本，如debug和release。构建系统为每个项目flavor和构建类型的组合生成APK。

默认情况下，Android Studio配置了默认的设置，在build.gradle文件中的defaultconfig,和两个构建类型(debug和releas)。这样会生成两个构建变种，debug和release，构建系统将为每个构建变种生成APK。

添加两个项目flavors：demo和full，随同默认的构建类型debug和release，将产生4个构建变种，各自有各自的配置：

demoDebug

demoRelease

fullDebug

fullRelease

资源合并于多个Android应用：

构建变种基于buildType和productFlavor的构建设置

主要的资源集合，一般位于 src/main/res

库项目的依赖，它通过在arr捆绑的资源对象来提供资源。

从低到高的合并次序是：libraries/dependencies-> main src -> productFlavor -> buildType。

有些应用不只一个维度的复杂特性组合，但是它们依然表现为同一个应用。比如，除了有一个demo和full版本的应用，一些游戏有可能包含了特定 CPU/ABI的二进制文件。构建系统的灵活性使产生如下变种称为可能：

x86-demoDebug

x86-demoRelease

x86-fullDebug

x86-fullRelease

arm-demoDebug

arm-demoRelease

arm-fullDebug

arm-fullRelease

mips-demoDebug

mips-demoRelease

mips-fullDebug

mips-fullRelease

这个项目将包含两个构建类型(debug 和 release)和两个维度的项目 flavors,一个是app的类型(demo和full),还有一个是 CPU/ABI(X86,ARM,或者 MIPS).

源码目录

为了为你的应用构建不同的版本，构建系统从以下的地方集合源码和资源文件：

src/main/ -主源码目录(对于所有变种的默认配置)

src/<buildType>- 源码目录

src/<productFlavor>/ -源码目录

注： 构建类型(buildtype) 和 product flavor 的源码 目录是可选的， 因为Android Studio不会为你创建这些目录。当你添加 build types和product flavors到构建配置文件中的时候，你应该创建这些目录。如果这些目录不存在，构建系统不会使用这些目录。

对于那些没有定义任何flavors的项目来说 ，构建系统使用了defaultConfig设置，主要的app目录和默认的构建类型目录。比如，生成默认的debug和releas构建变种，没有product flavors，构建系统使用：

src/main/  (默认的配置)

src/releas/ (构建类型)

src/debug/(构建类型)

对于使用了flavor维度的项目来说，构建系在每个维度的flavor源码目录合并。比如，为了生成arm-demo-release构建变种，构建系统合并：

src/main/ (默认配置)

src/release/ (构建类型)

src/demo/ (flavor – 应用类型维度)

src/arm/ (flavor – ABI维度)

这些目录的源码被集合起来生成这个构建变种的输出。

你可以在不同的目录中使用相同的类目，只要这些目录在一通过变种中不被一起使用。

构建系统统一回集合所有的manifest到一个manifest中，因此每个构建变种可以定义不同的组件或者是权限在最终的manifest。 manifest合并的从低到高的优先级是: libraries/dependencies-> main src -> productFlavor -> buildType 。

构建系统会合并来自所有源码目录的资源。如果在一个构建变种中，存在不同目录包含相同名字的资源，优先次序按照以下： build type的资源覆盖—>product flavorà覆盖main目录的资源à覆盖任何库。

注：构建变种可以使你服用一般的activities, 应用逻辑，不同版本的资源文件。