/**
 * {@moduleName}\build.gradle
 * 默认的 module 目录下的 build.gradle 文件内容如上。
 apply plugin: ‘com.android.application‘：
 表示使用 com.android.application 插件。也就是表示，这是一个 android application module 。 com.android.library 表示，这是一个 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** 中的 **proguard-android.txt** 文件以及当前 **module** 目录下的 **proguard-rules.pro** 文件。
 dependencies：
 用于配制引用的依赖。
 compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])：
 引用当前 module 目录下的 libs 文件夹中的所有 .jar 文件。
 2. **compile ‘com.android.support: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: ‘com.android.application‘
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‘)
//    }
//
//    tasks.withType(Compile) { compileTask -> compileTask.dependsOn copyNativeLibs }
//
//    clean.dependsOn ‘cleanCopyNativeLibs‘
//
//    tasks.withType(com.android.build.gradle.PackageApplicationTask) { pkgTask ->
//        pkgTask.jniDir 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 {
//    jniLibs.srcDirs = [‘libs‘]
//            manifest.srcFile ‘AndroidManifest.xml‘
//            java.srcDirs = [‘src‘]
//            resources.srcDirs = [‘src‘]
//            aidl.srcDirs = [‘src‘]
//            renderscript.srcDirs = [‘src‘]
//            res.srcDirs = [‘res‘]
//            assets.srcDirs = [‘assets‘]
//        }
//
//        // Move the tests to tests/java, tests/res, etc...
//        instrumentTest.setRoot(‘tests‘)
//
//        // Move the build types to build-types/<type>
//        // For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ...
//        // 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.
//        debug.setRoot(‘build-types/debug‘)
//        release.setRoot(‘build-types/release‘)
//    }
/**
 * 现在碰到的问题是如何触发这个事件打包
 * signingConfigs 元素用于设置签名文件信息。在本例中，我们使用了 app/keystore 文件为 release 分支进行签名。
 * 默认使用 SDK 中的 debug.keystore 为 debug 分支进行签名。
 */
    signingConfigs {
        release {
            storeFile file(‘keystore‘)
            storePassword ‘helloworld‘
            keyAlias ‘Android Release Key‘
            keyPassword ‘helloworld‘
        }
    }
    defaultConfig {
        applicationId "com.zsy.testasbuild"
        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/build.gradle 中将这 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 ，从而最终包名为 cc.bb.aa.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(R.id.textview);
         textView.append("\nappName = " + getString(R.string.app_name));
         textView.append("\nBuildTypesName = " + BuildTypesUtils.getBuildTypesName());
         textView.append("\nProductFlavorsName = " + ProductFlavorsUtils.getProductFlavorsName());
         textView.append("\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）。
         字符串、颜色值、整型等资源以及 AndroidManifest.xml ，将会进行元素级的覆盖（本例中的 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(‘proguard-android.txt‘), ‘proguard-rules.pro‘
            applicationIdSuffix ‘.release‘
            signingConfig signingConfigs.release
            zipAlignEnabled true
        }
/**
 * Gradle进行方便的多渠道打包;assemble还可以和productFlavors结合使用，具体在下一篇多渠道打包进一步解释
 */
//        buildtypesnochange {
//            signingConfig signingConfigs.release
//            zipAlignEnabled false
//        }
        // 移除lint检查的error
        lintOptions {
            abortOnError false
        }
    }
    productFlavors {
        playstore {
            applicationId ‘com.zsy.testasbuild.playstore‘
//            applicationName "playstore"
        }
        amazonstore {
            applicationId ‘com.zsy.testasbuild.amazonstore‘
//            applicationName "amazonstore"
        }
        productflavorsnochange {
        }
    }
}
/**
 * Gradle Library Projects
 Gradle 项目可以依赖于其它组件。这些组件可以是外部二进制包，或者是其它的 Gradle 项目。
 */
dependencies {
//    Remote artifacts（远程文件）compile ‘com.android.support: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 ‘com.android.support:appcompat-v7:22.1.1‘
//    compile ‘com.android.support:support-v4:21.0.2‘
//    compile ‘com.android.support:support-v4:21.+‘
//    Local packages（本地包）
//    引用 libs 目录下的所有的 .jar 文件。如果你指向引用 libs 目录下中一个指定的 jar ，你可以这么设置：
    // 引用libs文件夹下除xx.jar以外所有的jar。
//    compile fileTree(dir: ‘libs‘, include: [‘*.jar‘], exclude: [‘xx.jar‘])
//    compile files(‘libs/xx.jar‘)
    compile fileTree(include: [‘*.jar‘], dir: ‘libs‘)
//    compile ‘com.android.support:appcompat-v7:21.0.3‘
//    compile ‘com.jakewharton:butterknife:6.0.0‘
//    compile ‘com.nhaarman.listviewanimations:lib-core:3.1.0@aar‘
//    compile ‘com.nhaarman.listviewanimations:lib-manipulation:3.1.0@aar‘
//    compile ‘com.nhaarman.listviewanimations:lib-core-slh:3.1.0@aar‘
//    compile ‘com.umeng.analytics:analytics:latest.integration‘
//    compile ‘com.github.gabrielemariotti.changeloglib:library:1.5.2‘
//    compile ‘com.hannesdorfmann.smoothprogressbar:library:1.0.0‘
//    compile ‘com.github.castorflex.smoothprogressbar:library-circular:1.0.0‘
// 引用 lib 工程。
//    compile project(‘:app‘)
    // 编译extras目录下的ShimmerAndroid模块
//    compile project(‘:extras:ShimmerAndroid‘)
//    Java 在做 Unit Test 的时候，最常用的便是 JUnit 了，所以我们需要加入 JUnit 的依赖。在 {@projectName}/{@moduleName}/build.gradle 中添加 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}/settings.gradle 文件，而且 {@projectName}/build.gradle 和 {@moduleName}/build.gradle 文件进行了合并。合并后的文件内容如下：
 buildscript {repositories {mavenCentral()}dependencies {classpath ‘com.android.tools.build:gradle:1.0.0‘}}apply plugin: ‘android‘
 dependencies {compile fileTree(dir: ‘libs‘, include: ‘*.jar‘)}android {compileSdkVersion 21
 buildToolsVersion "21.1.2"
 sourceSets {main {manifest.srcFile ‘AndroidManifest.xml‘
 java.srcDirs = [‘src‘]
 resources.srcDirs = [‘src‘]
 aidl.srcDirs = [‘src‘]
 renderscript.srcDirs = [‘src‘]
 res.srcDirs = [‘res‘]
 assets.srcDirs = [‘assets‘]}// Move the tests to tests/java, tests/res, etc...
 instrumentTest.setRoot(‘tests‘)
 // Move the build types to build-types/<type>
 // For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ...
 // 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.
 debug.setRoot(‘build-types/debug‘)
 release.setRoot(‘build-types/release‘)}}和默认的 Android Studio {@moduleName}/build.gradle 文件相比， sourceSets 算是最大的区别了。 sourceSets 用于设置文件目录。
 main 元素表示默认的主干，出了 main 之外，默认的会有 release 和 debug 分支。如果 release 和 debug 分支中有些文件所在的目录不在默认目录同时也不再 main 所设置的目录，你可以在对应的分支中进行设置。
 */
/**
 * ps:补充内容
 关于依赖更多的补充内容如下：
 * dependencies {// 引入 jar 包。
 // 引用某一个特定的jar。
 compile files(‘libs/xx.jar‘)
 // 引用libs文件夹下除xx.jar以外所有的jar。
 compile fileTree(dir: ‘libs‘, include: [‘*.jar‘], exclude: [‘xx.jar‘])
 // so包在0.8版本的Android Studio中的目录更改为@{ModuleName}/src/main/jniLibs。且可以不用在此处配置so了。
 // 从 maven 库中引入。
 //compile ‘com.github.chrisbanes.actionbarpulltorefresh:extra-abc:0.9.2‘
 // 引用 lib 工程。
 compile project(‘:moduleName‘)
 // 引用users-library。users-library作用是，在编译时使用，但是jar不会打包到apk中，由Android或Android上安装的服务提供需要的内容。
 // 使用场景：
 // 1. 使用Android的framework-classes.jar中的一些隐藏的API。
 // 2. Google的服务框架或者其他服务框架。需要在AndroidMainFest.xml中配合uses-library使用。
 provided files(‘libs/xx.jar‘)
 provided ‘aaa:bbb:x.x.x‘
 // 在测试环境下引用依赖。
 // 引用jar文件。
 androidTestCompile files(‘libs/xx.jar‘)
 // 引用Maven。
 androidTestCompile ‘junit:junit:4.11‘
 // 在baidu productFlavors分支下引用依赖。
 // 引用jar文件。
 baiduCompile files(‘libs/xx.jar‘)
 // 引用Maven。
 baiduCompile ‘aaa:bbb:x.x.x‘
 // 在release buildTypes分支下引用依赖。
 // 引用jar文件。
 releaseCompile files(‘libs/xx.jar‘)
 // 引用Maven。
 releaseCompile ‘aaa:bbb:x.x.x‘}*/