/**
* {@moduleName}\
* 默认的 module 目录下的 文件内容如上。
apply plugin: ''：
表示使用 插件。也就是表示，这是一个 android application module 。 表示，这是一个 android library module 。
android：
配置所有android构建过程需要的参数。
compileSdkVersion：
用于编译的 SDK 版本。
buildToolsVersion：
用于 Gradle 编译项目的工具版本。
defaultConfig：
Android 项目默认设置。
applicationId：应用程序包名。
minSdkVersion：最低支持 Android 版本。
targetSdkVersion：目标版本。实际上应为测试环境下测试机的 Android 版本。
versionCode：版本号。
5. **versionName**：版本名称。
buildTypes:
编译类型。默认有两个： release 和 debug 。我们可以在此处添加自己的 buildTypes ，可在 Build Variants 面板看到（见 讲解1 ）。
minifyEnabled：
是否使用混淆。在老版本中为 runProguard ，新版本之所换名称，是因为新版本支持去掉没使用到的资源文件，而 runProguard 这个名称已不合适了。
2. **proguardFiles**：
使用的混淆文件，可以使用多个混淆文件。此例中，使用了 **SDK** 中的 **** 文件以及当前 **module** 目录下的 **** 文件。
dependencies：
用于配制引用的依赖。
compile fileTree(dir: 'libs', include: ['*.jar'])：
引用当前 module 目录下的 libs 文件夹中的所有 .jar 文件。
2. **compile ':appcompat-v7:21.0.3'**：
引用 **21.0.3**版本的 **appcompat-v7** （也就是常用的 **v7** library 项目）。
ps:在 **Eclipse** 中，使用 **android support** ，需要在 SDK 中下载 **Android Support Library** 。在 Android Studio中，使用 **android support** ，需要在 SDK 中下载 **Android Support Repository** ，且项目中使用的版本不能大于 SDK 中的版本。
*/
apply plugin: ''
android {
compileSdkVersion 21
// buildToolsVersion "21.1.2"
buildToolsVersion "22.0.1"
/*加入.so：*/
// （1）老版本，好像是指0.5以前的，具体不太记得了，方法如下：
// （注意：代码中的':MyProject'一定要换成你的项目名字哦）
// task copyNativeLibs(type: Copy) {
// from(new File(project(':Direct-Load-apk').buildDir, 'native-libs')) { include '**/*.so' }
// into new File(buildDir, 'native-libs')
// }
//
// (Compile) { compileTask -> copyNativeLibs }
//
// 'cleanCopyNativeLibs'
//
// () { pkgTask ->
// new File(buildDir, 'native-libs')
// }
// （2）新版本，具体版本号忘记了，反正如果你下载的是最新的那么自带就是最新的编译器。
// 移除lint检查的error
// lintOptions {
// abortOnError false
// }
/**
* 使用 Java7
*/
// compileOptions {
// sourceCompatibility JavaVersion.VERSION_1_7
// targetCompatibility JavaVersion.VERSION_1_7
// }
/**
* 这个配置应用用在从Eclipse导入的项目
*/
// sourceSets {
// main {
// = ['libs']
// ''
// = ['src']
// = ['src']
// = ['src']
// = ['src']
// = ['res']
// = ['assets']
// }
//
// // Move the tests to tests/java, tests/res, etc...
// ('tests')
//
// // Move the build types to build-types/<type>
// // For instance, build-types/debug/java, build-types/debug/, ...
// // This moves them out of them default location under src/<type>/... which would
// // conflict with src/ being used by the main source set.
// // Adding new build types or product flavors should be accompanied
// // by a similar customization.
// ('build-types/debug')
// ('build-types/release')
// }
/**
* 现在碰到的问题是如何触发这个事件打包
* signingConfigs 元素用于设置签名文件信息。在本例中，我们使用了 app/keystore 文件为 release 分支进行签名。
* 默认使用 SDK 中的 为 debug 分支进行签名。
*/
signingConfigs {
release {
storeFile file('keystore')
storePassword 'helloworld'
keyAlias 'Android Release Key'
keyPassword 'helloworld'
}
}
defaultConfig {
applicationId ""
minSdkVersion 14
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
/**
* Gradle Build Variants
本例用于讲解如何使用 Gradle 利用一份代码生成多种 APK 。
本例中， app 文件夹中，除了默认会生成的 main 目录以及 androidTest 目录之外，我额外添加了6个目录，
分别是： release 、 debug 、 buildtypesnochange 、 playstore 、 amazonstore 、 productflavorsnochange 。
同时，我们在 app/ 中将这 6 个文件夹分不到 buildTypes 和 productFlavors 中。
设置所有的 buildTypes 的 zipAlignEnabled 为 false 目的是为了只生成 unaligned 的 APK ，用于只产生 9 个 APK 。
因为 unaligned 的 APK 是编译 aligned 的 APK的中间产物，会影响我们最终编译出的 APK 的个数。
为 release 和 buildtypesnochange 设置签名是为了方便安装到设备中。
观察 Android Studio 中 Build Variants 面板，发现 app 的选项列表已经不是默认的 release 和 debug 了
这些列表是一个 productFlavors 和一个 buildTypes 组装的结果。
在 Android Studio 的 Gradle Plugin 中，每一个 APK 均是由一个 buildTypes 和一个 productFlavors 组装而成。
在默认的情况下， buildTypes 有 release 和 debug 两个分支； productFlavors 没有。
每一个 module/src 都有一个名称为 main 的文件夹。这个文件夹属于 buildTypes 和 productFlavors 基础，
buildTypes 和 productFlavors 都可以访问和修改 main 文件夹中的内容。
现在发现还是gradle编译不过；（不知道如何原因）
我们通过 gradle build 命令，可以生成 9 种不同的 APK ，
*/
buildTypes {
// 我们可以在 buildTypes 中对 APK 的一些信息可以设置，例如本例中将 debug 分支下 APK 包名在默认的包名后追加 .debug ，从而最终包名为 .gradle_build_configs.debug：
/**
* debug 类型的 APK 的名称为 Debug；release 类型的 APK 的名称为 Release；
* buildtypesnochange 类型的 APK 的名称为 playstore 、 amazonstore 、 productflavorsnochange 中设置的 apname 名称（分别对应 Play 、 Amazon 、 Gradle-Build-Variants 。
* buildtypesnochange 和 productflavorsnochange 中没有设置 appname ，则使用了 main 中的 appname）。
debug 类型的 APK 的图标为 D；release 类型的 APK 的图标为 R；
buildtypesnochange 类型的 APK 的图标为 playstore 、 amazonstore 、 productflavorsnochange 中设置的 apname 图标（分别对应图标 P 、 A 、Android 默认图标。
buildtypesnochange 和 productflavorsnochange 中均没有设置 ic_launcher.png ，则使用了 main 中的 ic_launcher.png）。
在类 MainActivity 中，有这么一段代码：
TextView textView = (TextView) findViewById();
("\nappName = " + getString(.app_name));
("\nBuildTypesName = " + ());
("\nProductFlavorsName = " + ());
("\npackageName = " + getPackageName());
实际上，在 main 文件夹中，并没有定义 BuildTypesUtils 类和 ProductFlavorsUtils 类（ BuildTypesUtils 类定义在 release 、 debug 、 buildtypesnochange 中；
ProductFlavorsUtils 类定义在 playstore 、 amazonstore 、 productflavorsnochange 中），但是我们可以使用这些类。
当你在 Android Studio 的 Build Variants 面板中切换当前选择的 Build Variants ，你会发现在 Project 面板中，
对应的两个文件夹的 java 和 res 文件夹的图标会发生变化（显示为资源文件夹图标的样式），而 main 文件夹中的这两个文件夹一直表现为资源文件夹图标的样式。
你在 Build Variants 面板切换 Build Variants ，实际上是在更改当前编译的分支。当你选择了一个 Build Variants 后，
Android Studio 会编译改 Build Variants 对应的 buildTypes 和 productFlavors 中的类以及资源文件，重新组装，形成新的 App 。
所谓的重新组装，简单理解起来就是，将当前的 Build Variants 对应的 buildTypes 文件夹中的内容、当前的 Build Variants 对应的 productFlavors 对应的文件夹中的内容、 main 文件夹中的内容合并到一起，形成一个并集。
合并规则：
图片、音频、 XML 类型的 Drawable 等资源文件，将会进行文件级的覆盖（本例中的 ic_launcher.png）。
字符串、颜色值、整型等资源以及 ，将会进行元素级的覆盖（本例中的 appname 、 hello_world）。
代码资源，同一个类， buildTypes 、 productFlavors 、 main 中只能存在一次，否则会有类重复的错误（这就是为什么本例中没有在 main 中定义 BuildTypesUtils 类和 ProductFlavorsUtils 类）。
覆盖等级为：buildTypes > productFlavors > main （这就是为什么 release 类型的 APK 的名称都是 Release ；
debug 类型的 APK 的名称都是 Debug ； buildtypesnochange 类型的 APK 的名称需要根据 productFlavors 来确定）。
*/
debug {
applicationIdSuffix ".debug"
zipAlignEnabled false
}
release {
// 是否进行混淆
// minifyEnabled也是最新的语法，很早之前是runProguard,这个也需要更新下。
minifyEnabled false
// 混淆文件的位置
proguardFiles getDefaultProguardFile(''), ''
applicationIdSuffix '.release'
signingConfig signingConfigs.release
zipAlignEnabled true
}
/**
* Gradle进行方便的多渠道打包;assemble还可以和productFlavors结合使用，具体在下一篇多渠道打包进一步解释
*/
// buildtypesnochange {
// signingConfig
// zipAlignEnabled false
// }
// 移除lint检查的error
lintOptions {
abortOnError false
}
}
productFlavors {
playstore {
applicationId ''
// applicationName "playstore"
}
amazonstore {
applicationId ''
// applicationName "amazonstore"
}
productflavorsnochange {
}
}
}
/**
* Gradle Library Projects
Gradle 项目可以依赖于其它组件。这些组件可以是外部二进制包，或者是其它的 Gradle 项目。
*/
dependencies {
// Remote artifacts（远程文件）compile ':appcompat-v7:21.0.2'
/**
* 引用 21.0.2 版本的 appcompat-v7 。
在 Android Studio中，使用 android support ，需要在 SDK 中下载 Android Support Repository ，且项目中使用的版本不能大于 SDK 中的版本。
当你的 SDK 中已经下载指定版本的 Android Support Repository ，即使没有联网，你也是可以在 Android Studio 中依赖对应的文件。
如果你的 SDK 没有下载指定版本的 Android Support Repository ，即使你现在连着网，也会出错。
*/
compile ':appcompat-v7:22.1.1'
// compile ':support-v4:21.0.2'
// compile ':support-v4:21.+'
// Local packages（本地包）
// 引用 libs 目录下的所有的 .jar 文件。如果你指向引用 libs 目录下中一个指定的 jar ，你可以这么设置：
// 引用libs文件夹下除以外所有的jar。
// compile fileTree(dir: 'libs', include: ['*.jar'], exclude: [''])
// compile files('libs/')
compile fileTree(include: ['*.jar'], dir: 'libs')
// compile ':appcompat-v7:21.0.3'
// compile ':butterknife:6.0.0'
// compile ':lib-core:3.1.0@aar'
// compile ':lib-manipulation:3.1.0@aar'
// compile ':lib-core-slh:3.1.0@aar'
// compile ':analytics:'
// compile ':library:1.5.2'
// compile ':library:1.0.0'
// compile ':library-circular:1.0.0'
// 引用 lib 工程。
// compile project(':app')
// 编译extras目录下的ShimmerAndroid模块
// compile project(':extras:ShimmerAndroid')
// Java 在做 Unit Test 的时候，最常用的便是 JUnit 了，所以我们需要加入 JUnit 的依赖。在 {@projectName}/{@moduleName}/ 中添加 JUnit 的 Maven 依赖。
// testCompile 意思为，test模式下依赖某一个库，该库不会在我们正式发布时打包到我们的程序中，作用和 debugCompile 类似。
// testCompile 'junit:junit:4.12'
}
/**
* if this project form eclipse export ;
* Gradle Eclipse Compatible
当你的项目从 Eclipse 中使用 Generate Gradle build files 导出的时候。为了兼容 Eclipse 的文件结构， Gradle 对资源文件目录、代码文件目录等目录进行了设置。
默认的，导出项目中没有 {@projectName}/ 文件，而且 {@projectName}/ 和 {@moduleName}/ 文件进行了合并。合并后的文件内容如下：
buildscript {repositories {mavenCentral()}dependencies {classpath ':gradle:1.0.0'}}apply plugin: 'android'
dependencies {compile fileTree(dir: 'libs', include: '*.jar')}android {compileSdkVersion 21
buildToolsVersion "21.1.2"
sourceSets {main { ''
= ['src']
= ['src']
= ['src']
= ['src']
= ['res']
= ['assets']}// Move the tests to tests/java, tests/res, etc...
('tests')
// Move the build types to build-types/<type>
// For instance, build-types/debug/java, build-types/debug/, ...
// This moves them out of them default location under src/<type>/... which would
// conflict with src/ being used by the main source set.
// Adding new build types or product flavors should be accompanied
// by a similar customization.
('build-types/debug')
('build-types/release')}}和默认的 Android Studio {@moduleName}/ 文件相比， sourceSets 算是最大的区别了。 sourceSets 用于设置文件目录。
main 元素表示默认的主干，出了 main 之外，默认的会有 release 和 debug 分支。如果 release 和 debug 分支中有些文件所在的目录不在默认目录同时也不再 main 所设置的目录，你可以在对应的分支中进行设置。
*/
/**
* ps:补充内容
关于依赖更多的补充内容如下：
* dependencies {// 引入 jar 包。
// 引用某一个特定的jar。
compile files('libs/')
// 引用libs文件夹下除以外所有的jar。
compile fileTree(dir: 'libs', include: ['*.jar'], exclude: [''])
// so包在0.8版本的Android Studio中的目录更改为@{ModuleName}/src/main/jniLibs。且可以不用在此处配置so了。
// 从 maven 库中引入。
//compile ':extra-abc:0.9.2'
// 引用 lib 工程。
compile project(':moduleName')
// 引用users-library。users-library作用是，在编译时使用，但是jar不会打包到apk中，由Android或Android上安装的服务提供需要的内容。
// 使用场景：
// 1. 使用Android的中的一些隐藏的API。
// 2. Google的服务框架或者其他服务框架。需要在中配合uses-library使用。
provided files('libs/')
provided 'aaa:bbb:'
// 在测试环境下引用依赖。
// 引用jar文件。
androidTestCompile files('libs/')
// 引用Maven。
androidTestCompile 'junit:junit:4.11'
// 在baidu productFlavors分支下引用依赖。
// 引用jar文件。
baiduCompile files('libs/')
// 引用Maven。
baiduCompile 'aaa:bbb:'
// 在release buildTypes分支下引用依赖。
// 引用jar文件。
releaseCompile files('libs/')
// 引用Maven。
releaseCompile 'aaa:bbb:'}*/