我只是技术搬运工，如果搬运有误，请不吝指出，谢谢
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插件的类路径依赖结构的构建脚本。
|
buildscript { |
注： 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中描述的。
?
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, 应用逻辑，不同版本的资源文件。
?
?
?
?
原文：http://netfreeperson.iteye.com/blog/2287123