├── 031_simple_build_files.md ├── 11_goals_of_the_new_build_system.md ├── README.md ├── SUMMARY.md ├── _book ├── 031_simple_build_files.html ├── 11_goals_of_the_new_build_system.html ├── GLOSSARY.html ├── aapt_options.html ├── advanced_build_customization.html ├── android_tasks.html ├── basic_build_customization.html ├── basics_and_configuration.html ├── build_options.html ├── build_tasks.html ├── build_types.html ├── build_variants.html ├── building_and_tasks.html ├── buildtype_and_product_flavor_property_reference.html ├── configuring_the_structure.html ├── cover.jpg ├── cover_small.jpg ├── creating_a_library_project.html ├── dependencies,_android_libraries_and_multi-project_setup.html ├── dependencies_on_binary_packages.html ├── dex_options.html ├── differences_between_a_project_and_a_library_project.html ├── general_tasks.html ├── gitbook │ ├── app.js │ ├── fonts │ │ ├── fontawesome │ │ │ ├── FontAwesome.otf │ │ │ ├── fontawesome-webfont.eot │ │ │ ├── fontawesome-webfont.svg │ │ │ ├── fontawesome-webfont.ttf │ │ │ └── fontawesome-webfont.woff │ │ ├── merriweather │ │ │ ├── 250.woff │ │ │ ├── 250i.woff │ │ │ ├── 400.woff │ │ │ ├── 400i.woff │ │ │ ├── 700.woff │ │ │ ├── 700i.woff │ │ │ ├── 900.woff │ │ │ └── 900i.woff │ │ └── opensans │ │ │ ├── 300.woff │ │ │ ├── 300i.woff │ │ │ ├── 400.woff │ │ │ ├── 400i.woff │ │ │ ├── 600.woff │ │ │ ├── 600i.woff │ │ │ ├── 700.woff │ │ │ └── 700i.woff │ ├── images │ │ ├── apple-touch-icon-precomposed-152.png │ │ └── favicon.ico │ ├── plugins │ │ └── gitbook-plugin-mathjax │ │ │ └── plugin.js │ ├── print.css │ └── style.css ├── glossary_index.json ├── goals_of_the_new_build_system.html ├── index.html ├── java_compilation_options.html ├── java_project_tasks.html ├── library_projects.html ├── library_publication.html ├── lint_support.html ├── local_packages.html ├── manifest_entries.html ├── manipulating_tasks.html ├── multi-flavor_variants.html ├── multi-projects_reports.html ├── multi_project_setup.html ├── product_flavor_configuration.html ├── product_flavors.html ├── project_structure.html ├── publish.sh ├── referencing_a_library.html ├── remote_artifacts.html ├── req.html ├── requirements.html ├── running_proguard.html ├── running_tests.html ├── search_index.json ├── signing_configurations.html ├── single_projects.html ├── sourcesets_and_dependencies.html ├── test_reports.html ├── testing.html ├── testing_android_libraries.html ├── using_sourcecompatibility_17.html └── why_gradle.html ├── aapt_options.md ├── advanced_build_customization.md ├── android_tasks.md ├── basic_build_customization.md ├── basics_and_configuration.md ├── build_options.md ├── build_tasks.md ├── build_type_+_product_flavor_=_build_variant.md ├── build_types.md ├── build_variants.md ├── building_and_tasks.md ├── buildtype_and_product_flavor_property_reference.md ├── configuring_the_structure.md ├── cover.jpg ├── cover_small.jpg ├── creating_a_library_project.md ├── dependencies,_android_libraries_and_multi-project_setup.md ├── dependencies_on_binary_packages.md ├── dex_options.md ├── differences_between_a_project_and_a_library_project.md ├── general_tasks.md ├── goals_of_the_new_build_system.md ├── java_compilation_options.md ├── java_project_tasks.md ├── library_projects.md ├── library_publication.md ├── lint_support.md ├── local_packages.md ├── manifest_entries.md ├── manipulating_tasks.md ├── multi-flavor_variants.md ├── multi-projects_reports.md ├── multi_project_setup.md ├── product_flavor_configuration.md ├── product_flavors.md ├── project_structure.md ├── publish.sh ├── referencing_a_library.md ├── remote_artifacts.md ├── req.md ├── requirements.md ├── running_proguard.md ├── running_tests.md ├── signing_configurations.md ├── single_projects.md ├── sourcesets_and_dependencies.md ├── test_reports.md ├── testing.md ├── testing_android_libraries.md ├── using_sourcecompatibility_17.md └── why_gradle.md /031_simple_build_files.md: -------------------------------------------------------------------------------- 1 | # 简单构建文件 2 | 一个最简单Gradle纯Java工程的build.gradle文件包含了以下内容: 3 | ``` groovy 4 | apply plugin: 'java' 5 | ``` 6 | 这是Gradle包装的Java插件。该插件提供了所有构建和测试Java应用程序的东西。 7 | 最简单的Android工程的build.gradle描述： 8 | ``` groovy 9 | buildscript { 10 | repositories { 11 | mavenCentral() 12 | } 13 | 14 | dependencies { 15 | classpath 'com.android.tools.build:gradle:0.11.1' 16 | } 17 | } 18 | 19 | apply plugin: 'android' 20 | 21 | android { 22 | compileSdkVersion 19 23 | buildToolsVersion "19.0.0" 24 | } 25 | ``` 26 | 译者注：目前gradle tools版本为0.13.+(2014.10.08) 27 | 28 | 上述内容包含了Android构建文件的3个主要部分： 29 | 30 | **buildscript { ... }**配置了驱动构建的代码. 31 | 32 | 在这个例子中，他申明了使用Maven中央库，并且申明了一个Maven构件的依赖classpath。这个构件声明了Gradle的Android插件版本为0.11.1. 33 | 34 | **注意**：这里的配置只影响了构建过程的代码，而不是整个工程的代码.工程本身需要声明它自己的仓库和依赖.这个后面会提到. 35 | 36 | 然后，跟前面提到的Java插件一样，添加了**android**插件. 37 | 38 | 最后，**android { ... }**配置了所有android构建的参数.也是Android DSL的入口点. 39 | 默认情况下，只有编译的target和build-tools版本是必须的.就是**compileSdkVersion**和**buildtoolsVersion **两个属性. 40 | 编译的target属性相当于在老的构建系统中`project.properties`中的target属性.这个新属性和老的target属性一样可以指定一个int(api等级)或者string类型的值. 41 | 42 | **重要：** 你只能使用**android**插件.如果同时使用**java**插件，会导致构建错误. 43 | 44 | **注意：** 你还需要添加*local.properties*文件，使用**sdk.dir**属性，来设置已经存在的SDK路径. 45 | 另外，你也可以设置环境变量**ANDROID_HOME**.这两种方式没有什么区别,可以根据你自己的喜好来选择一种. 46 | 47 | 48 | 49 | 50 | 51 | 52 | -------------------------------------------------------------------------------- /11_goals_of_the_new_build_system.md: -------------------------------------------------------------------------------- 1 | # 简介 2 | 本文档适用于0.9版本的Gradle plugin。在我们引入1.0版本之前，内容可能会与之前的版本不兼容。 3 | 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 说明 2 | Gradle Plugin User Guide中文版 3 | ======================== 4 | [![Build Status](https://www.gitbook.io/button/status/book/yeungeek/gradle-plugin-user-guide)](https://www.gitbook.io/book/yeungeek/gradle-plugin-user-guide/activity) 5 | 6 | Gradle Plugin的使用，并结合例子说明 7 | 8 | * Gradle Plugin User Guide中文版 正在翻译当中 欢迎大家一起加入 9 | * github: https://github.com/yeungeek/GradlePlugin_UserGuide 10 | * 使用了gitbook进行编辑：http://yeungeek.gitbooks.io/gradle-plugin-user-guide/ 11 | * 原文地址：http://tools.android.com/tech-docs/new-build-system/user-guide 12 | * 我会开放权限给需要加入的同学，联系我: yeungeek#gmail.com 13 | 14 | **翻译进度** 15 | 16 | 章节| 时间 | 译者|实例 17 | ----|------|----|---- 18 | 1 | 14.09.29 | [yeungeek](https://github.com/yeungeek)|[HelloWorld](https://github.com/yeungeek/Android-Gradle-Samples/tree/master/HelloWorld) 19 | 2 | 14.09.29 | [yeungeek](https://github.com/yeungeek)|- 20 | 3.1 | 14.10.08 | [yeungeek](https://github.com/yeungeek)| 21 | 3.2 | 14.10.09 | [yeungeek](https://github.com/yeungeek)| 22 | 3.3 | 14.10.10 | [yeungeek](https://github.com/yeungeek)| 23 | 3.4 | 14.10.20 | [yeungeek](https://github.com/yeungeek)| 24 | 4.1 | 14.11.03 | [yeungeek](https://github.com/yeungeek)| 25 | 4.2 | 14.11.05 | [yeungeek](https://github.com/yeungeek)| 26 | 4.3 | 14.12.01 | [flyouting](https://github.com/flyouting)| 27 | 5.1 | 15.05.01 | [yeungeek](https://github.com/yeungeek)| 28 | 5.2 | 15.05.02 | [yeungeek](https://github.com/yeungeek)| 29 | 5.3 | 15.05.02 | [yeungeek](https://github.com/yeungeek)| 30 | 5.4 | 15.05.04 | [yeungeek](https://github.com/yeungeek)| 31 | 5.5 | 15.05.05 | [yeungeek](https://github.com/yeungeek)| 32 | 6 | 15.06.21 | [yeungeek](https://github.com/yeungeek)| 33 | 7 | 15.06.22 | [yeungeek](https://github.com/yeungeek)| 34 | 35 | **特色** 36 | 37 | 我们是有实例的人 38 | 39 | gradle对应的示例代码，可以fork [Samples](https://github.com/yeungeek/Android-Gradle-Samples). 40 | 41 | # Summary 42 | 43 | * [序言](README.md) 44 | * [简介](11_goals_of_the_new_build_system.md) 45 | * [新构建系统的目标](goals_of_the_new_build_system.md) 46 | * [为什么使用Gradle?](why_gradle.md) 47 | * [配置](req.md) 48 | * [基础工程](requirements.md) 49 | * [简单构建文件](031_simple_build_files.md) 50 | * [工程结构](project_structure.md) 51 | * [配置工程结构](configuring_the_structure.md) 52 | * [构建任务](build_tasks.md) 53 | * [通用任务](general_tasks.md) 54 | * [Java工程任务](java_project_tasks.md) 55 | * [Android任务](android_tasks.md) 56 | * [基本的构建自定义](basic_build_customization.md) 57 | * [Manifest属性](manifest_entries.md) 58 | * [构建类型](build_types.md) 59 | * [签名配置](signing_configurations.md) 60 | * [运行ProGuard](running_proguard.md) 61 | * [依赖,Android库和多项目设置](dependencies,_android_libraries_and_multi-project_setup.md) 62 | * [依赖二进制包](dependencies_on_binary_packages.md) 63 | * [本地包](local_packages.md) 64 | * [远程文件](remote_artifacts.md) 65 | * [多项目设置](multi_project_setup.md) 66 | * [库工程](library_projects.md) 67 | * [创建一个库工程](creating_a_library_project.md) 68 | * [普通项目和库项目的区别](differences_between_a_project_and_a_library_project.md) 69 | * [引用一个库工程](referencing_a_library.md) 70 | * [库工程发布](library_publication.md) 71 | * [测试](testing.md) 72 | * [基本原理和配置](basics_and_configuration.md) 73 | * [运行测试](running_tests.md) 74 | * [测试Android库工程](testing_android_libraries.md) 75 | * [测试报告](test_reports.md) 76 | * [独立工程](single_projects.md) 77 | * [多工程报告](multi-projects_reports.md) 78 | * [Lint支持](lint_support.md) 79 | * [构建变种版本](build_variants.md) 80 | * [产物定制](product_flavors.md) 81 | * [构建类型+产物定制=构建变种版本](build_type_+_product_flavor_=_build_variant) 82 | * [产物定制配置](product_flavor_configuration.md) 83 | * [源组件和依赖](sourcesets_and_dependencies.md) 84 | * [构建和任务](building_and_tasks.md) 85 | * [测试](testing.md) 86 | * [多定制的变种版本](multi-flavor_variants.md) 87 | * [高级构建的自定义](advanced_build_customization.md) 88 | * [构建选项](build_options.md) 89 | * [Java编译选项](java_compilation_options.md) 90 | * [aapt选项](aapt_options.md) 91 | * [dex选项](dex_options.md) 92 | * [操作tasks](manipulating_tasks.md) 93 | * [构建类型和产物定制的属性引用](buildtype_and_product_flavor_property_reference.md) 94 | * [使用sourceCompatibility 1.7](using_sourcecompatibility_17.md) 95 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | * [序言](README.md) 4 | * [简介](11_goals_of_the_new_build_system.md) 5 | * [新构建系统的目标](goals_of_the_new_build_system.md) 6 | * [为什么使用Gradle?](why_gradle.md) 7 | * [配置](req.md) 8 | * [基础工程](requirements.md) 9 | * [简单构建文件](031_simple_build_files.md) 10 | * [工程结构](project_structure.md) 11 | * [配置工程结构](configuring_the_structure.md) 12 | * [构建任务](build_tasks.md) 13 | * [通用任务](general_tasks.md) 14 | * [Java工程任务](java_project_tasks.md) 15 | * [Android任务](android_tasks.md) 16 | * [基本的构建自定义](basic_build_customization.md) 17 | * [Manifest属性](manifest_entries.md) 18 | * [构建类型](build_types.md) 19 | * [签名配置](signing_configurations.md) 20 | * [运行ProGuard](running_proguard.md) 21 | * [依赖,Android库和多项目设置](dependencies,_android_libraries_and_multi-project_setup.md) 22 | * [依赖二进制包](dependencies_on_binary_packages.md) 23 | * [本地包](local_packages.md) 24 | * [远程文件](remote_artifacts.md) 25 | * [多项目设置](multi_project_setup.md) 26 | * [库工程](library_projects.md) 27 | * [创建一个库工程](creating_a_library_project.md) 28 | * [普通项目和库项目的区别](differences_between_a_project_and_a_library_project.md) 29 | * [引用一个库工程](referencing_a_library.md) 30 | * [库工程发布](library_publication.md) 31 | * [测试](testing.md) 32 | * [基本原理和配置](basics_and_configuration.md) 33 | * [运行测试](running_tests.md) 34 | * [测试Android库工程](testing_android_libraries.md) 35 | * [测试报告](test_reports.md) 36 | * [独立工程](single_projects.md) 37 | * [多工程报告](multi-projects_reports.md) 38 | * [Lint支持](lint_support.md) 39 | * [构建变种版本](build_variants.md) 40 | * [产物定制](product_flavors.md) 41 | * [构建类型+产物定制=构建变种版本](build_type_+_product_flavor_=_build_variant.md) 42 | * [产物定制配置](product_flavor_configuration.md) 43 | * [源组件和依赖](sourcesets_and_dependencies.md) 44 | * [构建和任务](building_and_tasks.md) 45 | * [测试](testing.md) 46 | * [多定制的变种版本](multi-flavor_variants.md) 47 | * [高级构建的自定义](advanced_build_customization.md) 48 | * [构建选项](build_options.md) 49 | * [Java编译选项](java_compilation_options.md) 50 | * [aapt选项](aapt_options.md) 51 | * [dex选项](dex_options.md) 52 | * [操作tasks](manipulating_tasks.md) 53 | * [构建类型和产物定制的属性引用](buildtype_and_product_flavor_property_reference.md) 54 | * [使用sourceCompatibility 1.7](using_sourcecompatibility_17.md) 55 | 56 | -------------------------------------------------------------------------------- /_book/GLOSSARY.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Glossary | 说明 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 |
38 | 39 | 40 |
41 |
42 | 43 |
44 | 971 |
972 | 973 |
974 |
975 |
976 | 977 | 978 | 979 | 980 | 1007 | 1008 | 1009 | 1010 |
1011 | 1012 | 1013 |
1014 |
1015 | 1016 | 1017 |
1018 |
1019 | 1020 | 1021 | 1022 | 1023 | 1024 |
1025 |
1026 |
1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 | 1041 |

1042 | 1043 | 说明 1044 |

1045 |
1046 | 1047 |
1048 |
1049 | 1050 | 1051 | 1052 |
1053 |
1054 |
1055 | 1056 | 1057 | 1058 |
1059 |
1060 | 1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1068 | 1069 | 1070 | 1071 | 1072 | 1078 | 1079 | 1080 | 1081 | 1082 | 1083 | -------------------------------------------------------------------------------- /_book/build_tasks.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 构建任务 | 说明 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |
37 | 38 | 39 |
40 |
41 | 42 |
43 | 970 |
971 | 972 |
973 |
974 |
975 | 976 | 977 | 978 | 979 | 1006 | 1007 | 1008 | 1009 |
1010 | 1011 | 1012 |
1013 |
1014 | 1015 | 1016 |
1017 |
1018 | 1019 | 1020 | 1021 | 1022 | 1023 |
1024 |
1025 |
1026 | 1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 |

1041 | 1042 | 说明 1043 |

1044 |
1045 | 1046 |
1047 |
1048 | 1049 | 1050 |
1051 | 1052 |

构建任务

1053 | 1054 | 1055 |
1056 | 1057 | 1058 |
1059 |
1060 |
1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1068 |
1069 |
1070 | 1071 | 1072 | 1073 | 1074 | 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | 1081 | 1082 | 1088 | 1089 | 1090 | 1091 | 1092 | 1093 | -------------------------------------------------------------------------------- /_book/build_variants.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 构建变种版本 | 说明 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |
37 | 38 | 39 |
40 |
41 | 42 |
43 | 970 |
971 | 972 |
973 |
974 |
975 | 976 | 977 | 978 | 979 | 1006 | 1007 | 1008 | 1009 |
1010 | 1011 | 1012 |
1013 |
1014 | 1015 | 1016 |
1017 |
1018 | 1019 | 1020 | 1021 | 1022 | 1023 |
1024 |
1025 |
1026 | 1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 |

1041 | 1042 | 说明 1043 |

1044 |
1045 | 1046 |
1047 |
1048 | 1049 | 1050 |
1051 | 1052 |

构建变种版本

1053 | 1054 | 1055 |
1056 | 1057 | 1058 |
1059 |
1060 |
1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1068 |
1069 |
1070 | 1071 | 1072 | 1073 | 1074 | 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | 1081 | 1082 | 1088 | 1089 | 1090 | 1091 | 1092 | 1093 | -------------------------------------------------------------------------------- /_book/building_and_tasks.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 构建和任务 | 说明 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |
37 | 38 | 39 |
40 |
41 | 42 |
43 | 970 |
971 | 972 |
973 |
974 |
975 | 976 | 977 | 978 | 979 | 1006 | 1007 | 1008 | 1009 |
1010 | 1011 | 1012 |
1013 |
1014 | 1015 | 1016 |
1017 |
1018 | 1019 | 1020 | 1021 | 1022 | 1023 |
1024 |
1025 |
1026 | 1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 |

1041 | 1042 | 说明 1043 |

1044 |
1045 | 1046 |
1047 |
1048 | 1049 | 1050 |
1051 | 1052 |

构建和任务

1053 | 1054 | 1055 |
1056 | 1057 | 1058 |
1059 |
1060 |
1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1068 |
1069 |
1070 | 1071 | 1072 | 1073 | 1074 | 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | 1081 | 1082 | 1088 | 1089 | 1090 | 1091 | 1092 | 1093 | -------------------------------------------------------------------------------- /_book/cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/cover.jpg -------------------------------------------------------------------------------- /_book/cover_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/cover_small.jpg -------------------------------------------------------------------------------- /_book/gitbook/fonts/fontawesome/FontAwesome.otf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/fontawesome/FontAwesome.otf -------------------------------------------------------------------------------- /_book/gitbook/fonts/fontawesome/fontawesome-webfont.eot: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/fontawesome/fontawesome-webfont.eot -------------------------------------------------------------------------------- /_book/gitbook/fonts/fontawesome/fontawesome-webfont.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/fontawesome/fontawesome-webfont.ttf -------------------------------------------------------------------------------- /_book/gitbook/fonts/fontawesome/fontawesome-webfont.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/fontawesome/fontawesome-webfont.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/250.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/250.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/250i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/250i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/400.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/400.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/400i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/400i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/700.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/700.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/700i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/700i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/900.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/900.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/merriweather/900i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/merriweather/900i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/300.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/300.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/300i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/300i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/400.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/400.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/400i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/400i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/600.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/600.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/600i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/600i.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/700.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/700.woff -------------------------------------------------------------------------------- /_book/gitbook/fonts/opensans/700i.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/fonts/opensans/700i.woff -------------------------------------------------------------------------------- /_book/gitbook/images/apple-touch-icon-precomposed-152.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/images/apple-touch-icon-precomposed-152.png -------------------------------------------------------------------------------- /_book/gitbook/images/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/_book/gitbook/images/favicon.ico -------------------------------------------------------------------------------- /_book/gitbook/plugins/gitbook-plugin-mathjax/plugin.js: -------------------------------------------------------------------------------- 1 | require(["gitbook"], function(gitbook) { 2 | MathJax.Hub.Config({ 3 | tex2jax: { 4 | processEscapes: true 5 | } 6 | }); 7 | 8 | 9 | gitbook.events.bind("page.change", function() { 10 | MathJax.Hub.Typeset() 11 | }); 12 | }); 13 | 14 | -------------------------------------------------------------------------------- /_book/gitbook/print.css: -------------------------------------------------------------------------------- 1 | .link-inherit{color:inherit}.link-inherit:hover,.link-inherit:focus{color:inherit}.hidden{display:none}.hljs-comment,.hljs-title{color:#8e908c}.hljs-variable,.hljs-attribute,.hljs-tag,.hljs-regexp,.ruby .hljs-constant,.xml .hljs-tag .hljs-title,.xml .hljs-pi,.xml .hljs-doctype,.html .hljs-doctype,.css .hljs-id,.css .hljs-class,.css .hljs-pseudo{color:#c82829}.hljs-number,.hljs-preprocessor,.hljs-pragma,.hljs-built_in,.hljs-literal,.hljs-params,.hljs-constant{color:#f5871f}.ruby .hljs-class .hljs-title,.css .hljs-rules .hljs-attribute{color:#eab700}.hljs-string,.hljs-value,.hljs-inheritance,.hljs-header,.ruby .hljs-symbol,.xml .hljs-cdata{color:#718c00}.css .hljs-hexcolor{color:#3e999f}.hljs-function,.python .hljs-decorator,.python .hljs-title,.ruby .hljs-function .hljs-title,.ruby .hljs-title .hljs-keyword,.perl .hljs-sub,.javascript .hljs-title,.coffeescript .hljs-title{color:#4271ae}.hljs-keyword,.javascript .hljs-function{color:#8959a8}.hljs{display:block;background:white;color:#4d4d4c;padding:.5em}.coffeescript .javascript,.javascript .xml,.tex .hljs-formula,.xml .javascript,.xml .vbscript,.xml .css,.xml .hljs-cdata{opacity:.5}.book-chapter{display:none}.exercise,.quiz{margin:1cm 0;padding:.4cm;page-break-inside:avoid;border:3px solid #ddd}.exercise .exercise-header,.quiz .exercise-header{margin-bottom:.4cm;padding-bottom:.2cm;border-bottom:1px solid #ddd}.exercise .question,.quiz .question{margin-top:.4cm}body{font-family:sans-serif;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;line-height:1.4;color:#333;overflow:hidden;line-height:1.6;word-wrap:break-word;display:block}body>*:first-child{margin-top:0!important}body>*:last-child{margin-bottom:0!important}body a{background:transparent}body a:active,body a:hover{outline:0}body strong{font-weight:bold}body h1{font-size:2em;margin:.67em 0}body img{border:0}body hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0}body pre{overflow:auto}body code,body pre{font-family:monospace,monospace;font-size:1em}body table{border-collapse:collapse;border-spacing:0}body td,body th{padding:0}body *{-moz-box-sizing:border-box;box-sizing:border-box}body a{color:#4183c4;text-decoration:none}body a:hover,body a:focus,body a:active{text-decoration:underline}body hr{height:0;margin:15px 0;overflow:hidden;background:transparent;border:0;border-bottom:1px solid #ddd}body hr:before,body hr:after{display:table;content:" "}body hr:after{clear:both}body h1,body h2,body h3,body h4,body h5,body h6{margin-top:15px;margin-bottom:15px;line-height:1.1}body h1{font-size:30px}body h2{font-size:21px}body h3{font-size:16px}body h4{font-size:14px}body h5{font-size:12px}body h6{font-size:11px}body blockquote{margin:0}body ul,body ol{padding:0;margin-top:0;margin-bottom:0}body ol ol{list-style-type:lower-roman}body dd{margin-left:0}body code,body pre{font-family:Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px}body pre{margin-top:0;margin-bottom:0}body .markdown-body>*:first-child{margin-top:0!important}body .markdown-body>*:last-child{margin-bottom:0!important}body .anchor{position:absolute;top:0;bottom:0;left:0;display:block;padding-right:6px;padding-left:30px;margin-left:-30px}body .anchor:focus{outline:0}body h1,body h2,body h3,body h4,body h5,body h6{position:relative;margin-top:1em;margin-bottom:16px;font-weight:bold;line-height:1.4}body h1{padding-bottom:.3em;font-size:2.25em;line-height:1.2;border-bottom:1px solid #eee}body h2{padding-bottom:.3em;font-size:1.75em;line-height:1.225;border-bottom:1px solid #eee}body h3{font-size:1.5em;line-height:1.43}body h4{font-size:1.25em}body h5{font-size:1em}body h6{font-size:1em;color:#777}body p,body blockquote,body ul,body ol,body dl,body table,body pre{margin-top:0;margin-bottom:16px}body hr{height:4px;padding:0;margin:16px 0;background-color:#e7e7e7;border:0 none}body ul,body ol{padding-left:2em}body ol ol,body ol ul{margin-top:0;margin-bottom:0}body dl{padding:0}body dl dt{padding:0;margin-top:16px;font-size:1em;font-style:italic;font-weight:bold}body dl dd{padding:0 16px;margin-bottom:16px}body blockquote{padding:0 15px;color:#777;border-left:4px solid #ddd}body blockquote>:first-child{margin-top:0}body blockquote>:last-child{margin-bottom:0}body table{display:block;width:100%;overflow:auto}body table th{font-weight:bold}body table th,body table td{padding:6px 13px;border:1px solid #ddd}body table tr{background-color:#fff;border-top:1px solid #ccc}body table tr:nth-child(2n){background-color:#f8f8f8}body img{max-width:100%;-moz-box-sizing:border-box;box-sizing:border-box;page-break-inside:avoid}body code{padding:0;padding-top:.2em;padding-bottom:.2em;margin:0;font-size:85%;background-color:#f7f7f7;border-radius:3px}body code:before,body code:after{letter-spacing:-0.2em;content:"\00a0"}body pre>code{padding:0;margin:0;font-size:100%;white-space:pre;background:transparent;border:0}body .highlight pre,body pre{padding:16px;overflow:auto;font-size:85%;line-height:1.45;background-color:#f7f7f7;border:0;border-radius:3px}body pre{word-wrap:normal}body pre code{display:inline;max-width:initial;padding:0;margin:0;overflow:initial;line-height:inherit;word-wrap:normal;background-color:transparent;border:0}body pre code:before,body pre code:after{content:normal}body .highlight{background:#fff} -------------------------------------------------------------------------------- /_book/glossary_index.json: -------------------------------------------------------------------------------- 1 | [] -------------------------------------------------------------------------------- /_book/publish.sh: -------------------------------------------------------------------------------- 1 | #! /bin/bash 2 | echo "==== start publish book =====" && 3 | git add . && 4 | git commit -m 'publish books' && 5 | git push && 6 | echo '==== publish book success ====' 7 | echo 8 | 9 | -------------------------------------------------------------------------------- /aapt_options.md: -------------------------------------------------------------------------------- 1 | # aapt选项 2 | ``` groovy 3 | android { 4 | aaptOptions { 5 | noCompress 'foo', 'bar' 6 | ignoreAssetsPattern "!.svn:!.git:!.ds_store:!*.scc:.*:_*:!CVS:!thumbs.db:!picasa.ini:!*~" 7 | } 8 | } 9 | ``` 10 | 这个将影响所有使用`aapt`的task 11 | -------------------------------------------------------------------------------- /advanced_build_customization.md: -------------------------------------------------------------------------------- 1 | # 高级构建的自定义 2 | -------------------------------------------------------------------------------- /android_tasks.md: -------------------------------------------------------------------------------- 1 | # Android任务 2 | Android插件使用了相同的约定，使它可以兼容其他插件，并且额外增加了标识性的任务: 3 | * **assemble** 4 | 组合工程所有输出的任务 5 | * **check** 6 | 执行所有检查的任务 7 | * **connectedCheck** 8 | 在一个连接的设备或者模拟器上执行检查，它们可以在所有连接的设备上并行执行检查 9 | * **deviceCheck** 10 | 使用APIs连接远程设备执行检查.主要用于CI(持续集成)服务上. 11 | * **build** 12 | 执行assemble和check两个任务 13 | * **clean** 14 | 这个任务会清空工程的输出 15 | 16 | 17 | 新的标志性任务是必须的，为了能够保证在没有设备连接的情况下执行定期检查. 18 | 要注意的是**build**并不依赖于**deviceCheck**，或者**connectedCheck** 19 | 20 | 一个android工程只要有两种输出：debug apk和release apk.每个输出都有各自标志性的任务，可以方便的单独构建它们: 21 | * **assemble** 22 | * **assembleDebug** 23 | * **assembleRelease** 24 | 25 | 它们都依赖于构建一个apk所需要执行多个步骤的其他一些任务. 26 | **assemble**任务依赖了上面的两个，所以会构建出两个APK. 27 | 28 | > 提示:Gradle在命令行上支持驼峰语法来命名它们的任务名称.例如. 29 | ``` gradle 30 | gralde aR 31 | ``` 32 | 等同与输入 33 | ``` gradle 34 | gradle assembleRelease 35 | ``` 36 | 只要没有其它命令匹配`aR` 37 | 38 | check任务也有他自己的依赖: 39 | * **check** 40 | * **lint** 41 | * **connectedCheck** 42 | * **connectedAndroidTest** 43 | * **connectedUiAutomatorTest**(还么有实现) 44 | * **deviceCheck** 45 | * 这个任务依赖于其它实现了测试扩展点的插件被创建的时候 46 | 47 | 最后，插件为所有的构建类型(**debug, release, test**)创建了`install/uninstall`任务，只要它们是可以被安装的(需要签名过的). 48 | 49 | -------------------------------------------------------------------------------- /basic_build_customization.md: -------------------------------------------------------------------------------- 1 | # 基本的构建自定义 2 | Android插件提供了大量DSL，直接从构建系统中自定义大部分事情. 3 | -------------------------------------------------------------------------------- /basics_and_configuration.md: -------------------------------------------------------------------------------- 1 | # 基本原理和配置 2 | 正如前面提到的，在**main** sourceSet下面的就是**androidTest** sourceSet，默认路径在`src/androidTest/`下。 4 | 从这个测试_sourceSet_中可以构建出一个使用Android测试框架，并且可以发布到设备上测试应用的测试apk。这里包含了单元测试，集成测试，和后续的UI自动测试。 5 | 6 | 测试程序manifest中的``结构是自动生成的，但是你可以创建`src/androidTest/AndroidManifest.xml`文件来增加其他的组件到测试的manifest中。 7 | 8 | 下面是配置测试程序的一些值，可以在``节点中增加： 9 | * **testPackageName** 10 | * **testInstrumentationRunner** 11 | * **testHandleProfiling** 12 | * **testFunctionalTest** 13 | 14 | 正如前面所看到的，这些配置在**defaultConfig **对象中配置: 15 | ``` groovy 16 | android { 17 | defaultConfig { 18 | testPackageName "com.test.foo" 19 | testInstrumentationRunner "android.test.InstrumentationTestRunner" 20 | testHandleProfiling true 21 | testFunctionalTest true 22 | } 23 | } 24 | ``` 25 | 在测试应用程序manifest文件中，`instrumentation`节点中的`testPackageName`属性会自动使用测试应用的package名称，即使这个名称已经在**defaultConfig **或者是_Build Type_对象中自定义过。这也是manifest文件自动生成的一个原因。 26 | 27 | 另外，这个_sourceSet_也可以配置自己的依赖。 28 | 默认情况下，应用程序和它拥有的依赖会被添加到测试应用的classpath中，但是也可以通过下面的方式进行扩展 29 | ``` groovy 30 | dependencies { 31 | androidTestCompile 'com.google.guava:guava:11.0.2' 32 | } 33 | ``` 34 | 测试应用通过**assembleTest** task来构建。它不依赖main中的**assemble** task，不过需要手动来设置它，使它可以自动运行。 35 | 36 | 目前只有一个_Build Type_被测试。默认情况是**debug** _Build Type_,但是可以通过下面的方式进行重新配置： 37 | ``` groovy 38 | android { 39 | ... 40 | testBuildType "staging" 41 | } 42 | ``` 43 | 44 | -------------------------------------------------------------------------------- /build_options.md: -------------------------------------------------------------------------------- 1 | # 构建选项 2 | -------------------------------------------------------------------------------- /build_tasks.md: -------------------------------------------------------------------------------- 1 | # 构建任务 2 | -------------------------------------------------------------------------------- /build_type_+_product_flavor_=_build_variant.md: -------------------------------------------------------------------------------- 1 | # 构建类型+产物定制=构建变种版本 2 | 正如前面看到的，每一个 _Build Type_都会生成一个新的APK。 3 | 4 | _Prduct Flavors_同样有这个效果：工程的输出将会组合所有的可能,_Build Types_和_Product Flavor_(如果有Flavor定义存在的话) 5 | 6 | 每一种组合(包含_Build Type_和_Product Flavor_)，就是一个_Build Variant_(构建变种版本). 7 | 8 | 例如，在上面的例子中，声明的Favory与默认的`debug`和`release`两个_Build Type_将会生成以下的4个_Build Variants_: 9 | * Flavor1 - debug 10 | * Flavor1 - release 11 | * Flavor2 - debug 12 | * Flavor2 - release 13 | 14 | 工程中如果么有定义flavor同样还是有_Build Variants_，但是只是用的默认的flavor和配置。默认的flavor/config是没有名字的，所以生成的Build Variant的列表和Build Type列表一样。 15 | -------------------------------------------------------------------------------- /build_types.md: -------------------------------------------------------------------------------- 1 | # 构建类型 2 | 默认情况下，Android插件会自动建立构建应用程序的debug和release版本的工程. 3 | 它们的区别主要是能否在一个安全(non dev)的设备上调试,以及APK是如何签名. 4 | 5 | debug版本使用了通用的`name/password`对自动创建的密钥证书进行签名(为了防止在构建过程中出现认证请求).release版本在构建过程中不进行签名，而是需要后面再进行签名. 6 | 7 | 这个配置是通过一个叫**BuildType**对象来完成的.默认情况下,两个实例会被创建,一个**debug**和一个**release** 8 | 9 | Android插件允许像创建其他*构建类型*那样来自定义这两个实例.可以在**buildTypes**的DSL容器中完成: 10 | ``` groovy 11 | android { 12 | buildTypes { 13 | debug { 14 | applicationIdSuffix ".debug" 15 | } 16 | 17 | jnidebug.initWith(buildTypes.debug) 18 | jnidebug { 19 | packageNameSuffix ".jnidebug" 20 | jnidebugBuild true 21 | } 22 | } 23 | } 24 | ``` 25 | 26 | 上面的代码片段实现了以下功能： 27 | * 配置默认的**debug**构建类型: 28 | * 设置包名为``.debug,以便能够在同一个设备上安装*debug*和*release*版本的apk 29 | * 创建了名为**jnidebug**的新*BuildType*,并且配置为是**debug**构建类型的一个副本. 30 | * 继续配置**jnidebug**，可以构建JNI组件,而且增加了一个不同的包名后缀. 31 | 32 | 33 | -------------------------------------------------------------------------------- /build_variants.md: -------------------------------------------------------------------------------- 1 | # 构建变种版本 2 | 新的构建系统其中的一个目标就是，允许为同一个应用构建不同的版本。 3 | 4 | 这里有两个主要的应用场景： 5 | 1. 同一个应用不同版本 6 | 例如：一个免费的demo版本，一个收费的专业版本。 7 | 2. 同一个应用打包成不同的apk，发布到google play。 8 | 点击该链接[more](http://developer.android.com/google/play/publishing/multiple-apks.html)，查看更多信息 9 | 3. 综合1和2的情况 10 | 11 | 这个目标就是同一个工程能够生成不同的APK，取代使用一个库工程，两个或者两个以上的应用工程来生成APK的方式。 12 | 13 | -------------------------------------------------------------------------------- /building_and_tasks.md: -------------------------------------------------------------------------------- 1 | # 构建和任务 2 | 我们前面提到的每一个_Build Type_会创建自己的 `assemble ` task,但是Build Variant是Build Type和Product Flavor的组合。 3 | 4 | 当_Product Flavors_使用的时候，将会创建更多的assemble-type task： 5 | 1. assemble 6 | 2. assemble 7 | 3. assemble 8 | 9 | `#1` 允许直接构建一个Variant版本,例如`assembleFlavor1Debug` 10 | 11 | `#2` 允许构建指定Build Type的所有APK，例如assembleDebug将会构建Flavor1Debug和Flavor2Debug两个Variant版本。 12 | 13 | `#3` 允许构建指定flavor的所有APK，例如assembleFlavor1将会构建Flavor1Debug和Flavor1Release两个Variant版本。 14 | 15 | 另外，`assemble` task会构建所有可能组合的Variant版本 16 | 17 | -------------------------------------------------------------------------------- /buildtype_and_product_flavor_property_reference.md: -------------------------------------------------------------------------------- 1 | # 构建类型和产物定制的属性引用 2 | coming soon 3 | 4 | 对于Gradle的task（DefaultTask，JavaCompile，Copy，Zip），请参考Gradle文档。 5 | -------------------------------------------------------------------------------- /configuring_the_structure.md: -------------------------------------------------------------------------------- 1 | # 配置工程结构 2 | 当默认的工程结构不适用时，就可能需要去配置它.根据Gradle文档，根据下面的代码可以重新配置Java工程的sourceSets： 3 | ``` groovy 4 | sourceSets { 5 | main { 6 | java { 7 | srcDir 'src/java' 8 | } 9 | resources { 10 | srcDir 'src/resources' 11 | } 12 | } 13 | } 14 | ``` 15 | > **注意：** **srcDir**将会被添加到已存在的源文件目录中(这个在Gradle文档中没有提到，但是实际上确实是这样执行了) 16 | 17 | 要替换默认的源文件目录，你需要使用一个数组路径的**srcDirs**来替代.下面是使用调用对象的另外一种不同的方法： 18 | ``` groovy 19 | sourceSets { 20 | main.java.srcDirs = ['src/java'] 21 | main.resources.srcDirs = ['src/resources'] 22 | } 23 | ``` 24 | 想了解更多的信息，可以查看Gradle文档中[Java插件](http://gradle.org/docs/current/userguide/java_plugin.html)部分. 25 | 26 | Android插件使用了类似的语法，因为使用了它自己的sourceSets，这些配置会被添加到**android**对象中. 27 | 下面这个例子,使用了旧工程结构的main代码，并把**androidTest**的sourceSet映射到tests目录中. 28 | ``` groovy 29 | android { 30 | sourceSets { 31 | main { 32 | manifest.srcFile 'AndroidManifest.xml' 33 | java.srcDirs = ['src'] 34 | resources.srcDirs = ['src'] 35 | aidl.srcDirs = ['src'] 36 | renderscript.srcDirs = ['src'] 37 | res.srcDirs = ['res'] 38 | assets.srcDirs = ['assets'] 39 | } 40 | 41 | androidTest.setRoot('tests') 42 | } 43 | } 44 | ``` 45 | > 注意：因为旧的结构把所有的源文件(java, aidl, renderscript, and java resources)放在同一个目录中,所以我们需要重新映射所有的sourceSet新组件到同一个**src**目录下. 46 | 47 | > 注意：**setRoot()**会移动所有的sourceSet(包括它的子目录)到新的目录.例子中把**src/androidTest/***移动到**tests/*** 48 | 49 | 这是在Android中特有的，在Java sourceSets中不起作用. 50 | 51 | 上述的就是工程迁移的简单示例. 52 | 53 | 54 | -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/cover.jpg -------------------------------------------------------------------------------- /cover_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeungeek/GradlePlugin_UserGuide/4e2526e4bf14fc52652f473924a33426e2987ec7/cover_small.jpg -------------------------------------------------------------------------------- /creating_a_library_project.md: -------------------------------------------------------------------------------- 1 | # 创建一个库工程 2 | 3 | 一个库工程跟一个常规的Android工程很相似，只是有部分不同. 4 | 5 | 既然构建库跟构建工程不同，那肯定用不同的插件，但是两个插件内部其实共享大部分同样的代码，且由同一个jar提供：com.android.tools.build.gradle 6 | 7 | ``` 8 | buildscript { 9 | repositories { 10 | mavenCentral() 11 | } 12 | 13 | dependencies { 14 | classpath 'com.android.tools.build:gradle:0.5.6' 15 | } 16 | } 17 | 18 | apply plugin: 'android-library' 19 | 20 | android { 21 | compileSdkVersion 15 22 | } 23 | ``` 24 | 25 | 这里创建了一个库工程，使用API 15编译，SourceSets dependencies的处理就跟在应用工程中一样，且可以用同样的方式自定义. 26 | -------------------------------------------------------------------------------- /dependencies,_android_libraries_and_multi-project_setup.md: -------------------------------------------------------------------------------- 1 | # 依赖,Android库和多项目设置 2 | Gradle工程可以依赖于其他组件.这些组件可以是外部的二进制包,或者是其他Gradle工程. 3 | -------------------------------------------------------------------------------- /dependencies_on_binary_packages.md: -------------------------------------------------------------------------------- 1 | # 依赖二进制包 2 | -------------------------------------------------------------------------------- /dex_options.md: -------------------------------------------------------------------------------- 1 | # dex选项 2 | ``` groovy 3 | android { 4 | dexOptions { 5 | incremental false 6 | preDexLibraries = false 7 | jumboMode = false 8 | javaMaxHeapSize "2048M" 9 | } 10 | } 11 | ``` 12 | 这个将影响所有使用dex的task。 13 | -------------------------------------------------------------------------------- /differences_between_a_project_and_a_library_project.md: -------------------------------------------------------------------------------- 1 | # 普通项目和库项目的区别 2 | 3 | 一个库工程主要输出一个 `aar` 包(代表Android存档)，这是个编译文件(类似jar包或者.so文件)和资源文件(manifest，res，assets)的组合. 4 | 5 | 库工程还可以生成一个测试apk来独立测试. 6 | 7 | assembleDebug assembleRelease会调起同样的anchor task，所以用通过命令行去构建是无差别的 8 | 9 | 至于其他的，库工程跟应用工程是一样的，都有`build type`，`product flavors`，可以生成多个版本的aar 10 | 11 | 注意，大多数的Build Type配置不支持库工程，然而你可以使用自定义`sourceSets`来配置库内容是用于工程使用还是测试使用. 12 | -------------------------------------------------------------------------------- /general_tasks.md: -------------------------------------------------------------------------------- 1 | # 通用任务 2 | 3 | 添加一个插件到构建文件中，就会自动创建一组可执行的构建任务.Java和Android插件都有此功能. 4 | 下面的是约定的构建任务: 5 | * **assemble** 6 | 组合工程所有输出的任务 7 | * **check** 8 | 执行所有检查的任务 9 | * **build** 10 | 执行assemble和check两个任务 11 | * **clean** 12 | 这个任务会清空工程的输出 13 | 14 | **assemble**，**check**和**build**这三个任务实际上不做任何事.它们只是一个标记，目的是让plugins添加实际需要的可以完成工作的任务. 15 | 16 | 这就允许你去调用相同的任务，无论是什么类型的工程，或者是工程应用了任何插件. 17 | 例如,使用了*findbugs*插件将会创建一个新的任务，并且让**check**任务依赖它， 18 | 当 **check** task被调用的时候,这个新的task 19 | 先会被调用. 20 | 21 | 在命令行中执行以下命令,你可以获取更多高级别的任务: 22 | ``` groovy 23 | gradle tasks 24 | ``` 25 | 查看task之间依赖关系的完整列表，可以执行以下命令 26 | ``` groovy 27 | gradle tasks --all 28 | ``` 29 | >注意：Gradle会自动监视一个声明了输入和输出的task. 30 | 执行两次工程未变化的**build**，Gradle会使用UP-TO-DATE通知所有任务，也就意味着不需要做任何工作.这让任务之间可以相互正确的依赖，不用去执行不必要的构建操作. 31 | -------------------------------------------------------------------------------- /goals_of_the_new_build_system.md: -------------------------------------------------------------------------------- 1 | # 新构建系统的目标 2 | 3 | 新构建系统的目标: 4 | * 让重用代码和资源变得更加容易 5 | * 使创建同一个应用程序的多个版本根据容易，不管是多apk的发布还是同一个应用的不同定制版本 6 | * 使构建过程根据容易配置，扩展和自定义 7 | * 优秀IDE的集成 8 | -------------------------------------------------------------------------------- /java_compilation_options.md: -------------------------------------------------------------------------------- 1 | # Java编译选项 2 | ``` groovy 3 | android { 4 | compileOptions { 5 | sourceCompatibility = "1.6" 6 | targetCompatibility = "1.6" 7 | } 8 | } 9 | ``` 10 | 默认值是“1.6”，这个设置会影响所有编译Java源代码的task。 11 | -------------------------------------------------------------------------------- /java_project_tasks.md: -------------------------------------------------------------------------------- 1 | # Java工程任务 2 | Java插件创建了两个主要的任务，是main标识任务的依赖 3 | * **assemble** 4 | * **jar** 5 | 这个任务创建了所有输出 6 | * **check** 7 | * **test** 8 | 这个任务执行所有的测试 9 | 10 | **jar**任务本身直接或者间接依赖于其他任务: 11 | 像**classes**将会编译Java源码. 12 | **testClasses**会编译所有的测试，却很少被调用，因为**test**依赖于它(与**classes**任务类似) 13 | 14 | 通常情况下，你可能只需要调用**assemble**和**check**任务，可以忽略其他的任务. 15 | 16 | 你可以在件中[Java 插件](http://gradle.org/docs/current/userguide/java_plugin.html)中查看完整的任务列表和他们描述. 17 | 18 | 19 | -------------------------------------------------------------------------------- /library_projects.md: -------------------------------------------------------------------------------- 1 | # 库工程 2 | -------------------------------------------------------------------------------- /library_publication.md: -------------------------------------------------------------------------------- 1 | # 库工程发布 2 | 默认情况下,一个库只会发布它的_release_ Variant(变种)版本.这个版本通过库项目被其他工程引用,不论它们本身构建了什么版本.这是由于Gradle的限制,我们正在努力消除这个临时的限制. 3 | 4 | 使用下面的代码,你可以控制哪个Variant版本为发行版 5 | ``` groovy 6 | android { 7 | defaultPublishConfig "debug" 8 | } 9 | ``` 10 | 注意这里发布的配置名称引用的时完整的Variant版本名称._Release_和_debug_只能在项目中没有其他特性版本下适用.如果你想改变默认的发布版本，你可以使用这个特性： 11 | ``` groovy 12 | android { 13 | defaultPublishConfig "flavor1Debug" 14 | } 15 | ``` 16 | 将库项目的所有变种版本发布也是有可能的。我们计划允许在一般的项目与项目进行依赖(类似于上面所说的情况)，但是由于Gradle的限制(我们正在努力修复这个问题)，目前还没有实现这种功能。
17 | 默认情况下没有启用发布所有变种版本的功能。使用下面的代码启用它: 18 | ``` groovy 19 | android { 20 | publishNonDefault true 21 | } 22 | ``` 23 | 理解发布多个Variant版本意味着发布多个aar文件，而不是一个aar文件包含多个Variant版本这个很重要。每个aar包含了一个单独的Variant版本.
24 | 发布一个Variant版本意味着构建一个可用的aar文件作为Gradle项目的输出构件。无论是被发布到maven仓库，还是被作为另一个项目的库项目依赖。
25 | Gradle有个默认构建的概念。当添加以下配置后就会使用到： 26 | ``` groovy 27 | compile project(':libraries:lib2') 28 | ``` 29 | 创建一个其他发布构建的依赖，你需要指定使用哪个： 30 | ``` groovy 31 | dependencies { 32 | flavor1Compile project(path: ':lib1', configuration: 'flavor1Release') 33 | flavor2Compile project(path: ':lib1', configuration: 'flavor2Release') 34 | } 35 | ``` 36 | > **重要:**注意已发布的配置是一个完整的variant版本，包含了构建的类型，需要像上面一样的格式被引用
37 | > **重要:**当启用非默认发布，maven发布插件将会发布其它Variant版本作为扩展包（按分类器分类）。这意味着不能真正的兼容发布到maven仓库。你应该另外发布一个单一的Variant版本到仓库中，或者允许发布所有配置以支持跨项目依赖。 38 | -------------------------------------------------------------------------------- /lint_support.md: -------------------------------------------------------------------------------- 1 | # Lint支持 2 | > Lint: [Lint](https://developer.android.com/tools/help/lint.html) 3 | 4 | 从0.7.0 版本开始，你可以为一个指定的Variant(变种)运行lint，或者是所有的Variant都运行lint。它将会生成一个描述哪个指定的Variant存在问题的报告。 5 | 6 | 你可以通过以下lint选项配置。通常情况下你只需配置其中一部分，下面是所有的可用选项。 7 | ``` groovy 8 | android { 9 | lintOptions { 10 | // set to true to turn off analysis progress reporting by lint 11 | quiet true 12 | // if true, stop the gradle build if errors are found 13 | abortOnError false 14 | // if true, only report errors 15 | ignoreWarnings true 16 | // if true, emit full/absolute paths to files with errors (true by default) 17 | //absolutePaths true 18 | // if true, check all issues, including those that are off by default 19 | checkAllWarnings true 20 | // if true, treat all warnings as errors 21 | warningsAsErrors true 22 | // turn off checking the given issue id's 23 | disable 'TypographyFractions','TypographyQuotes' 24 | // turn on the given issue id's 25 | enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' 26 | // check *only* the given issue id's 27 | check 'NewApi', 'InlinedApi' 28 | // if true, don't include source code lines in the error output 29 | noLines true 30 | // if true, show all locations for an error, do not truncate lists, etc. 31 | showAll true 32 | // Fallback lint configuration (default severities, etc.) 33 | lintConfig file("default-lint.xml") 34 | // if true, generate a text report of issues (false by default) 35 | textReport true 36 | // location to write the output; can be a file or 'stdout' 37 | textOutput 'stdout' 38 | // if true, generate an XML report for use by for example Jenkins 39 | xmlReport false 40 | // file to write report to (if not specified, defaults to lint-results.xml) 41 | xmlOutput file("lint-report.xml") 42 | // if true, generate an HTML report (with issue explanations, sourcecode, etc) 43 | htmlReport true 44 | // optional path to report (default will be lint-results.html in the builddir) 45 | htmlOutput file("lint-report.html") 46 | 47 | // set to true to have all release builds run lint on issues with severity=fatal 48 | // and abort the build (controlled by abortOnError above) if fatal issues are found 49 | checkReleaseBuilds true 50 | // Set the severity of the given issues to fatal (which means they will be 51 | // checked during release builds (even if the lint target is not included) 52 | fatal 'NewApi', 'InlineApi' 53 | // Set the severity of the given issues to error 54 | error 'Wakelock', 'TextViewEdits' 55 | // Set the severity of the given issues to warning 56 | warning 'ResourceAsColor' 57 | // Set the severity of the given issues to ignore (same as disabling the check) 58 | ignore 'TypographyQuotes' 59 | } 60 | } 61 | ``` 62 | -------------------------------------------------------------------------------- /local_packages.md: -------------------------------------------------------------------------------- 1 | # 本地包 2 | 配置一个外部的jar包依赖，你需要在compile配置中添加一个依赖。 3 | ``` groovy 4 | dependencies { 5 | compile files('libs/foo.jar') 6 | } 7 | 8 | android { 9 | ... 10 | } 11 | ``` 12 | > 注意： 13 | 该dependencies的DSL标签是标准Gradle API中的一部分,所以它不属于android标签. 14 | 15 | 这个compile配置将被用于编译main application.它里面的所有依赖都会被添加到编译classpath中,**同时**也会被打包最终的APK.以下是添加依赖时可能用到的其他一些配置选项: 16 | * compile 主程序 17 | * androidTestCompile 测试程序 18 | * debugCompile debug构建类型 19 | * releaseCompile release构建类型 20 | 21 | 因为不可能去构建一个没有关联任何构建类型的APK,APK默认配置了两个或两个以上的编译配置：compile和``Compile.创建一个新的构建类型将会自动创建一个基于该名字的新配置. 22 | 23 | 对于debug版本需要使用一个自定义库(为了反馈实例化的崩溃信息等),但分布时不需要，或者它们依赖于同一个库的不同版本时会非常有用. 24 | 25 | 26 | -------------------------------------------------------------------------------- /manifest_entries.md: -------------------------------------------------------------------------------- 1 | # Manifest属性 2 | 通过DSL可以配置下面的manifest属性: 3 | * minSdkVersion 4 | * targetSdkVersion 5 | * versionCode 6 | * versionName 7 | * applicationId(有效的包名--查看[ApplicationId versus PackageName](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename)了解更多信息) 8 | * Package Name for the test application 9 | * Instrumentation test runner 10 | 11 | 例子： 12 | ``` groovy 13 | android { 14 | compileSdkVersion 19 15 | buildToolsVersion "19.0.0" 16 | 17 | defaultConfig { 18 | versionCode 12 19 | versionName "2.0" 20 | minSdkVersion 16 21 | targetSdkVersion 16 22 | } 23 | } 24 | ``` 25 | 在**android**元素中的**defaultConfig**定义了所有的配置. 26 | 27 | 在android插件的先前版本使用`packageName`来配置manifest的`packageName`属性. 28 | 从0.11.0版本开始,你应该在`build.gradle`中使用`applicationId`来配置manifest的`packageName`属性. 29 | 这是被用来消除在应用程序的packageName(程序的ID)和java包名之间的混乱. 30 | 31 | 在构建文件中定义的强大之处是它的动态性. 32 | 例如.可以从文件中或者是自定义的逻辑代码中读取版本名称: 33 | 34 | ``` groovy 35 | 36 | def computeVersionName() { 37 | ... 38 | } 39 | 40 | android { 41 | compileSdkVersion 19 42 | buildToolsVersion "19.0.0" 43 | 44 | defaultConfig { 45 | versionCode 12 46 | versionName computeVersionName() 47 | minSdkVersion 16 48 | targetSdkVersion 16 49 | } 50 | } 51 | ``` 52 | >注意: 不要使用使用在给定范围内已经存在的getter方法可能引起冲突的方法名.例如，在`defaultConfig { ...}`中调用`getVersionName()`会自动使用defaultConfig.getVersionName()方法去替代自定义的方法. 53 | 54 | 如果一个属性不是通过DSL来设置的，一些默认的值将被使用.下表是可能用到的默认值: 55 | 56 | Property Name| Default value in DSL object | Default value 57 | ----|------|---- 58 | **versionCode**|-1| value from manifest if present 59 | **versionName**|null| value from manifest if present 60 | **minSdkVersion**|-1| value from manifest if present 61 | **targetSdkVersion**|-1| value from manifest if present 62 | **applicationId**|null| value from manifest if present 63 | **testApplicationId**|null|applicationId + “.test” 64 | **testInstrumentationRunner**|null|android.test.InstrumentationTestRunner 65 | **signingConfig**|null|null 66 | **proguardFile**|N/A (set only)|N/A (set only) 67 | **proguardFiles**|N/A (set only)|N/A (set only) 68 | 69 | 如果你在构建脚本中使用了自定义逻辑来查询这些属性，第二列的值就变得很重要.例如,你可能会写: 70 | ``` groovy 71 | if (android.defaultConfig.testInstrumentationRunner == null) { 72 | // assign a better default... 73 | } 74 | ``` 75 | 如果这值一直为`null`,那么在构建的时候将被替换成第3列的默认值,但是在DSL中没有包含该值,所以你无法查询该值 76 | 除非是真的有必要才会如此定义，这是为了预防解析应用的manifest文件. 77 | -------------------------------------------------------------------------------- /manipulating_tasks.md: -------------------------------------------------------------------------------- 1 | # 操作task 2 | 基础Java工程有一组有限的taskask相互处理生成一个输出。 3 | `classes`task是一个编译java源码的task。在build.gradle脚本中可以很容易的去使用`classes`task。这个是**project.tasks.classes**的缩写。 4 | 5 | 在Android项目中，就相对比较复些。因为Android项目中有大量相同的task，它们的名字是基于_Build Types_和_Product Flavors_生成。 6 | 7 | 为了解决这个问题，Android对象有两个属性: 8 | * **applicationVariants **(适用于app Plugin) 9 | * **libraryVariants**(只适用于library plugin) 10 | * **testVariants**(两者都适用) 11 | 12 | 这三个都会分别返回一个ApplicationVariant、LibraryVariant和TestVariant对象的[DomainObjectCollection](http://www.gradle.org/docs/current/javadoc/org/gradle/api/DomainObjectCollection.html) 13 | 14 | 注意使用了这三个collection中其中一个都会触发所对应的task。意味着使用了collection后不需要重新配置。 15 | 16 | DomainObjectCollection可以直接访问所有对象，或者通过过滤器进行方便的筛选。 17 | ``` groovy 18 | android.applicationVariants.all { variant -> 19 | .... 20 | } 21 | ``` 22 | 以上三个variant对象共享下面的这些属性: 23 | 24 | Property Name| Property Type| Description 25 | ----|------|---- 26 | name|String| Variant的名字，必须是唯一的 27 | description|String| Human readable description of the variant. 28 | dirName|String|subfolder name for the variant. Guaranteed to be unique. Maybe more than one folder, ie “debug/flavor1” 29 | baseName|String|Variant输出的基础名字，必须唯一. 30 | outputFile|File|The output of the variant. This is a read/write property. 31 | processManifest|ProcessManifest|处理Manifest的task. 32 | aidlCompile|AidlCompile|The task that compiles the AIDL files. 33 | renderscriptCompile|RenderscriptCompile|The task that compiles the Renderscript files. 34 | mergeResources|MergeResources|The task that merges the resources. 35 | mergeAssets|MergeAssets|The task that merges the assets. 36 | processResources|ProcessAndroidResources|处理并编译资源文件的task. 37 | generateBuildConfig|GenerateBuildConfig| The task that generates the BuildConfig class. 38 | javaCompile|JavaCompile|The task that compiles the Java code. 39 | processJavaResources|Copy|处理Java资源的task 40 | assemble|DefaultTask|Variant的标志性assemble task 41 | 42 | ApplicationVariant附加属性: 43 | 44 | Property Name| Property Type| Description 45 | ----|------|---- 46 | buildType|BuildType|The BuildType of the variant. 47 | productFlavors|List|Variant的ProductFlavor。一般不为空但也允许空值. 48 | mergedFlavor|ProductFlavor|android.defaultConfig和variant.productFlavors的合并. 49 | signingConfig|SigningConfig|Variant使用的SigningConfig对象 50 | isSigningReady|boolean| true if the variant has all the information needed to be signed. 51 | testVariant|BuildVariant|将会测试这个Variant的TestVariant 52 | dex|Dex|将代码打包成dex的task。如果这个Variant是个库，这个值可以为空. 53 | packageApplication|PackageApplication|The task that makes the final APK. Can be null if the variant is a library. 54 | zipAlign|ZipAlign|The task that zipaligns the apk. Can be null if the variant is a library or if the APK cannot be signed. 55 | install|DefaultTask|The installation task. Can be null. 56 | uninstall|DefaultTask|The uninstallation task. 57 | 58 | LibraryVariant属性： 59 | 60 | Property Name| Property Type| Description 61 | ----|------|---- 62 | buildType|BuildType|The BuildType of the variant. 63 | mergedFlavor|ProductFlavor|The defaultConfig values 64 | testVariant|BuildVariant|The Build Variant that will test this variant. 65 | packageLibrary|Zip|用于打包库项目的AAR文件。如果是个库项目，这个值不能为空. 66 | 67 | TestVariant 属性： 68 | 69 | Property Name| Property Type| Description 70 | ----|------|---- 71 | buildType|BuildType|The BuildType of the variant 72 | productFlavors|List|Variant的ProductFlavor。一般不为空但也允许空值. 73 | mergedFlavor|ProductFlavor|android.defaultConfig和variant.productFlavors的合并. 74 | signingConfig|SigningConfig|Variant使用的SigningConfig对象 75 | isSigningReady|boolean| true if the variant has all the information needed to be signed. 76 | testVariant|BuildVariant|将会测试这个Variant的TestVariant 77 | dex|Dex|将代码打包成dex的task。如果这个Variant是个库，这个值可以为空. 78 | packageApplication|PackageApplication|The task that makes the final APK. Can be null if the variant is a library. 79 | zipAlign|ZipAlign|The task that zipaligns the apk. Can be null if the variant is a library or if the APK cannot be signed. 80 | install|DefaultTask|The installation task. Can be null. 81 | uninstall|DefaultTask|The uninstallation task. 82 | connectedAndroidTest|DefaultTask|在连接设备上行执行Android测试的task. 83 | providerAndroidTest|DefaultTask|The task that runs the android tests using the extension API. 84 | 85 | Android task特有类型API： 86 | * ProcessManifest 87 | * File manifestOutputFile 88 | * AidlCompile 89 | * File sourceOutputDir 90 | * RenderscriptCompile 91 | * File sourceOutputDir 92 | * File resOutputDir 93 | * MergeResources 94 | * File outputDir 95 | * MergeAssets 96 | * File outputDir 97 | * ProcessAndroidResources 98 | * File manifestFile 99 | * File resDir 100 | * File assetsDir 101 | * File sourceOutputDir 102 | * File textSymbolOutputDir 103 | * File packageOutputFile 104 | * File proguardOutputFile 105 | * GenerateBuildConfig 106 | * File sourceOutputDir 107 | * Dex 108 | * File outputFolder 109 | * PackageApplication 110 | * File resourceFile 111 | * File dexFile 112 | * File javaResourceDir 113 | * File jniDir 114 | * File outputFile 115 | * 直接在Variant对象中使用“outputFile”可以改变最终的输出文件夹 116 | * ZipAlign 117 | * File inputFile 118 | * File outputFile 119 | * 直接在Variant对象中使用“outputFile”可以改变最终的输出文件夹 120 | 121 | 每个task类型的API的限制，主要是由于Gradle的工作方式和Android plugin的配置方式. 122 | 123 | 首先，Gradle意味着拥有的task只能配置输入输出的路径和一些可能使用的选项标记。因此，task只能定义一些输入和输出。 124 | 125 | 其次，大部分的task的输入都不是单一的，一般都混合了_sourceSet_,_Build Types_和_Product Flavors_.为了保持构建文件的简洁和 126 | 可读性，就会让开发者通过DSL语言来修改这些对象来配置构建过程，而不是去深入来修改输入和task的选项。 127 | 128 | 另外需要注意，除了ZipAlign task外，其它所有类型有需要设置私有数据来使它们运行。这就意味着不可能手动的为这些类型，创建新的task。 129 | 130 | 这些API可能会被更改，一般来说，当前API是围绕着那些给定输入和输出的task，来添加额外的处理(如果可能的话)。欢迎反馈意见，特别是那些没有预见的需求。 131 | 132 | 对于其他的Gradle task(DefaultTask, JavaCompile, Copy, Zip),请参考Gradle文档。 133 | -------------------------------------------------------------------------------- /multi-flavor_variants.md: -------------------------------------------------------------------------------- 1 | # 多定制的变种版本 2 | 在一些情况下，一个应用可能需要基于多个标准来创建多个版本。 3 | 4 | 例如，Google Play中的multi-apk支持4个不同的过滤器。区分创建的不同APK的每一个过滤器要求能够使用多维的Product Flavor。 5 | 6 | 假如有个游戏需要一个免费版本和一个付费的版本，并且需要在multi-apk支持中使用ABI过滤器（译注：ABI，应用二进制接口，优点是不需要改动应用的任何代码就能够将应用迁移到任何支持相同ABI的平台上）。这个游戏应用需要3个ABI和两个特定应用版本，因此就需要生成6个APK（没有因计算不同Build Types生成的Variant版本）。 7 | 8 | 然而，注意到在这个例子中，为三个ABI构建的付费版本源代码都是相同，因此创建6个flavor来实现不是一个好办法。 相反的，使用两个flavor维度，并且自动构建所有可能的Variant组合。 9 | 10 | 这个功能的实现就是使用Flavor Dimensions。每一个flavorDimension 代表一个维度，并且flavor都被分配到一个指定的Dimension中。 11 | ``` groovy 12 | android { 13 | ... 14 | 15 | flavorDimensions "abi", "version" 16 | 17 | productFlavors { 18 | freeapp { 19 | flavorDimension "version" 20 | ... 21 | } 22 | 23 | x86 { 24 | flavorDimension "abi" 25 | ... 26 | } 27 | } 28 | } 29 | ``` 30 | android.flavorDimensions数组按照先后排序定义了可能使用的dimension。每一个Product Flavor都被分配到一个dimension中。 31 | 32 | 上面的例子中将Product Flavor分为两个维度，为别为abi维度[x86,arm,mips]和version维度[freeapp,paidapp]，再加上默认的Build Type有[debug,release]，这将会组合生成以下的Build Variant 33 | * x86-freeapp-debug 34 | * x86-freeapp-release 35 | * arm-freeapp-debug 36 | * arm-freeapp-release 37 | * mips-freeapp-debug 38 | * mips-freeapp-release 39 | * x86-paidapp-debug 40 | * x86-paidapp-release 41 | * arm-paidapp-debug 42 | * arm-paidapp-release 43 | * mips-paidapp-debug 44 | * mips-paidapp-release 45 | 46 | `android.flavorDimensions`中定义的dimension排序非常重要 47 | 48 | 每一个Variant版本的配置由几个Product Flavor对象决定: 49 | * android.defaultConfig 50 | * 一个来自abi维度的对象 51 | * 一个来自version维度的对象 52 | 53 | dimension中的排序决定了哪一个flavor覆盖哪一个，这对于资源来说非常重要，因为一个flavor中的值会替换定义在低优先级的flavor中的值 54 | 55 | dimension使用最高的优先级定义，因此在上面例子中的优先级为： 56 | ``` groovy 57 | abi > version > defaultConfig 58 | ``` 59 | Multi-flavors项目同样拥有额外的sourceSet，类似于Variant的sourceSet，只是少了Build Type: 60 | * android.sourceSets.x86Freeapp 61 | Location src/x86Freeapp/ 62 | * android.sourceSets.armPaidapp 63 | Location src/armPaidapp/ 64 | * etc... 65 | 66 | 这允许在flavor-combination的层次上进行定制.它们拥有过比基础的flavor sourceSet更高的优先级，但是优先级低于Build Type的sourceSet。 67 | 68 | -------------------------------------------------------------------------------- /multi-projects_reports.md: -------------------------------------------------------------------------------- 1 | # 多工程报告 2 | 一个工程中配置了多个应用和库，当同一个时间运行所有测试时，它会生成一份包含了所有测试结果的报告，这个非常有用。 3 | 4 | 为了实现这个目标，在同一个依赖文件需要使用不同的插件。可以通过以下方式实现： 5 | ``` groovy 6 | buildscript { 7 | repositories { 8 | mavenCentral() 9 | } 10 | 11 | dependencies { 12 | classpath 'com.android.tools.build:gradle:0.5.6' 13 | } 14 | } 15 | 16 | apply plugin: 'android-reporting' 17 | ``` 18 | 这个必须添加到工程的根目录下，例如和settings.gradle在同一个目录下。 19 | 20 | 然后，在根目录下，执行下面这个命令会运行所有测试，并合并所有的报告： 21 | ``` groovy 22 | gradle deviceCheck mergeAndroidReports --continue 23 | ``` 24 | > 注意：`--continue`选项保证能够执行所有测试，不管子工程的运行是否失败。如果没有这个选项，第一个失败测试就会终止全部的测试，导致一些项目不能够执行测试。 25 | -------------------------------------------------------------------------------- /multi_project_setup.md: -------------------------------------------------------------------------------- 1 | # 多项目设置 2 | 使用多项目设置，Gradle项目可以依赖其他Gradle项目. 3 | 4 | 多项目设置的实现通常是在一个根项目路径下，包含了所有子项目的文件夹. 5 | 6 | 例如,给定以下的项目结构: 7 | ``` groovy 8 | MyProject/ 9 | + app/ 10 | + libraries/ 11 | + lib1/ 12 | + lib2/ 13 | ``` 14 | 我们可以定义3个项目.Gradle会按照下面的名称去映射: 15 | ``` groovy 16 | :app 17 | :libraries:lib1 18 | :libraries:lib2 19 | ``` 20 | 每个项目都有属于自己的`build.gradle`来声明项目是如何构建的. 21 | 另外,在项目的根目录下有个`setting.gradle`. 22 | 这些文件的目录结构: 23 | ``` groovy 24 | MyProject/ 25 | | settings.gradle 26 | + app/ 27 | | build.gradle 28 | + libraries/ 29 | + lib1/ 30 | | build.gradle 31 | + lib2/ 32 | | build.gradle 33 | ``` 34 | `setting.gradle`文件内容很简单： 35 | ``` groovy 36 | include ':app', ':libraries:lib1', ':libraries:lib2' 37 | ``` 38 | 这里定义了哪个文件夹才是真正的Gradle项目. 39 | 40 | 其中:app项目可能依赖一些库,可以通过声明下面的这些依赖来解决: 41 | ``` groovy 42 | dependencies { 43 | compile project(':libraries:lib1') 44 | } 45 | ``` 46 | 更多关于多项目配置的信息，请参考[多项目配置](http://gradle.org/docs/current/userguide/multi_project_builds.html) 47 | -------------------------------------------------------------------------------- /product_flavor_configuration.md: -------------------------------------------------------------------------------- 1 | # 产物定制配置 2 | 每一个flavor都是通过闭包来配置： 3 | ``` groovy 4 | android { 5 | ... 6 | 7 | defaultConfig { 8 | minSdkVersion 8 9 | versionCode 10 10 | } 11 | 12 | productFlavors { 13 | flavor1 { 14 | packageName "com.example.flavor1" 15 | versionCode 20 16 | } 17 | 18 | flavor2 { 19 | packageName "com.example.flavor2" 20 | minSdkVersion 14 21 | } 22 | } 23 | } 24 | ``` 25 | 注意**android.productFlavors.* **对象与**android.defaultConfig**对象的ProductFlavor类型是相同的。意味着它们共享一样的属性。 26 | 27 | defaultConfig为所有的flavor提供基本的配置，每一个flavor都可以重设这些配置的值。在上面的例子中，最终的结果： 28 | * flavor1 29 | * packageName: com.example.flavor1 30 | * minSdkVersion: 8 31 | * versionCode: 20 32 | * flavor2 33 | * packageName: com.example.flavor2 34 | * minSdkVersion: 14 35 | * versionCode: 10 36 | 37 | 通常情况下，_Build Type_配置会覆盖其他的配置。例如，，_Build Type_中的packageNameSuffix 会被追加到 Product Flavor的packageName 上。 38 | 39 | 也有一些情况是一些设置可以同时在Build Type和Product Flavor中设置。在这种情况下，按照个别为主的原则决定。 40 | 41 | 例如：signingConfig就是其中一个例子。`signingConfig`允许通过设置android.buildTypes.release.signingConfig为所有release共享相同的SigningConfig。或者通过设置android.productFlavors.*.signingConfig为每一个release包设置独立的SigningConfig 42 | -------------------------------------------------------------------------------- /product_flavors.md: -------------------------------------------------------------------------------- 1 | # 产物定制 2 | 一个产物定制定义了从工程中构建一个应用的自定义版本。一个单一的工程可以同时定义不同的定制产物。 3 | 4 | 这个新的设计概念，是为了解决不同版本之间微小的差异。虽然工程生成了多个定制的版本，但本质上都是同一个应用，这种方式比使用库工程的方式个更好。 5 | 6 | 产物定制需要在`productFlavors`DSL容器中声明： 7 | ``` groovy 8 | android { 9 | .... 10 | 11 | productFlavors { 12 | flavor1 { 13 | ... 14 | } 15 | 16 | flavor2 { 17 | ... 18 | } 19 | } 20 | } 21 | ``` 22 | 这里创建了两个flavor，名为`flavor1`和`flavor2` 23 | 24 | > 注意：flavor的命名不能与已存在的Build Type或者androidTest这个sourceSet有冲突。 25 | -------------------------------------------------------------------------------- /project_structure.md: -------------------------------------------------------------------------------- 1 | # 工程结构 2 | 上面提到的基本构建文件需要一个默认的文件结构.Gradle遵循约定优于配置的概念. 在尽可能的情况下提供合理的默认参数. 3 | 基本的工程有两个名为"source sets"组件.就是main source code和test code.它们分别位于: 4 | * src/main/ 5 | * src/androidTest/ 6 | 7 | 里面的每个文件目录都对应了相应的源组件. 8 | 对于Java插件和Android插件，他们对应的Java源代码和Java资源目录： 9 | * java/ 10 | * resources/ 11 | 12 | 对于Android插件，有额外的文件和文件目录： 13 | * AndroidManifest.xml 14 | * res/ 15 | * assets/ 16 | * aidl/ 17 | * rs/ 18 | * jni/ 19 | 20 | **注意：** src/androidTest/AndroidManifest.xml是不需要的，因为它会自动创建. 21 | 22 | 23 | -------------------------------------------------------------------------------- /publish.sh: -------------------------------------------------------------------------------- 1 | #! /bin/bash 2 | echo "==== start publish book =====" && 3 | git add . && 4 | git commit -m 'publish books' && 5 | git push && 6 | echo '==== publish book success ====' 7 | echo 8 | 9 | -------------------------------------------------------------------------------- /referencing_a_library.md: -------------------------------------------------------------------------------- 1 | # 引用一个库工程 2 | 3 | 引用一个库就跟引用其他工程一样： 4 | 5 | ``` 6 | dependencies { 7 | compile project(':libraries:lib1') 8 | compile project(':libraries:lib2') 9 | } 10 | ``` 11 | 12 | 注意: 如果你有多个库，那么这个顺序很重要，这就好像旧的构建系统，在project.properties文件中的依赖顺序一样重要。 13 | -------------------------------------------------------------------------------- /remote_artifacts.md: -------------------------------------------------------------------------------- 1 | # 远程文件 2 | Gradle支持从Maven或者Ivy仓库中拉取构件. 3 | 首先必须将仓库添加到列表中，然后需要声明依赖的Maven或者Ivy构件名称. 4 | ``` groovy 5 | repositories { 6 | mavenCentral() 7 | } 8 | 9 | 10 | dependencies { 11 | compile 'com.google.guava:guava:11.0.2' 12 | } 13 | 14 | android { 15 | ... 16 | } 17 | ``` 18 | >注意: mavenCentral()是指定仓库URL的快捷方法.Gradle支持远程和本地的仓库. 19 | 20 | >注意: Gradle遵循依赖递归.这意味着，如果一个依赖中又有自己的依赖，那么所有的构件都会被拉取下来. 21 | 22 | 更多关于设置依赖的信息,请查看[Gralde用户指南](http://gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html)，和[DSL文档](http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.dsl.DependencyHandler.html). 23 | -------------------------------------------------------------------------------- /req.md: -------------------------------------------------------------------------------- 1 | # 配置 2 | * Gradle1.10 1.11 1.12使用插件0.11.1版本 3 | * SDK Build Tools 版本19.0.0.一些特性需要更高版本。 4 | 5 | 6 | 译者注：gradle目前已经是2.1版本，插件0.12.+ 7 | 8 | 最新可以关注: http://www.gradle.org/ 9 | 10 | -------------------------------------------------------------------------------- /requirements.md: -------------------------------------------------------------------------------- 1 | # 基础工程 2 | 一个Gradle工程的构建描述，定义在工程根目录下的build.gradle文件中. 3 | -------------------------------------------------------------------------------- /running_proguard.md: -------------------------------------------------------------------------------- 1 | # 运行ProGuard 2 | 从`Gradle Plugin for ProGuard version 4.10`后就开始支持`ProGuard`.ProGuard插件是自动应用，而且任务是自动创建的,如果构建类型的`minifyEnabled`属性被设置成运行ProGuard. 3 | ``` groovy 4 | android { 5 | buildTypes { 6 | release { 7 | minifyEnabled true 8 | proguardFile getDefaultProguardFile('proguard-android.txt') 9 | } 10 | } 11 | 12 | productFlavors { 13 | flavor1 { 14 | } 15 | flavor2 { 16 | proguardFile 'some-other-rules.txt' 17 | } 18 | } 19 | } 20 | ``` 21 | 构建变种使用在它的构建类型和产物定制中声明的规则文件. 22 | 23 | 这里有两个默认规则文： 24 | * proguard-android.txt 25 | * proguard-android-optimize.txt 26 | 27 | 两个文件在SDK的路径下.使用`getDefaultProguardFile()`方法会返回文件的全路径.它们除了是否进行优化之外,其它都是相同的. 28 | -------------------------------------------------------------------------------- /running_tests.md: -------------------------------------------------------------------------------- 1 | # 运行测试 2 | 正如前面提到的，标志性task **connectedCheck** 需要一个连接的设备来启动。 3 | 这个过程依赖**androidTest** task，所以也会运行该任务。这个task会执行下面这些任务： 4 | * 确认应用和测试应用都被构建(依赖**assembleDebug**和) 5 | **assembleDebug** 6 | * 安装这两个应用 7 | * 运行测试 8 | * 卸载这两个应用 9 | 10 | 如果多于一个设备连接，所有的测试都会同时运行在所有连接的设备上。如果其中一个设备测试失败，那么其他设备也算是测试失败。 11 | 12 | 所有的测试结果被保存为xml文件，路径： 13 | ``` groovy 14 | build/androidTest-results 15 | ``` 16 | (类似于junit的报告被保存在build/test-results目录下) 17 | 18 | 同样，路径可以自定义配置： 19 | ``` groovy 20 | android { 21 | ... 22 | 23 | testOptions { 24 | resultsDir = "$project.buildDir/foo/results" 25 | } 26 | } 27 | ``` 28 | **android.testOptions.resultsDir **的值通过**Project.file(String)**获取。 29 | -------------------------------------------------------------------------------- /signing_configurations.md: -------------------------------------------------------------------------------- 1 | # 签名配置 2 | 签名一个应用程序需要以下文件: 3 | * keystore 4 | * keystore密码 5 | * key的别名(alias) 6 | * key密码 7 | * 存储类型 8 | 9 | 位置,键名,两个密码和存储类型一起组成了这个签名配置(*SigningConfig*) 10 | 11 | 默认情况下, **debug**被配置成使用debug keystore,keystore使用了已知的密码和一个已知密码的默认key. 12 | debug keystore的位置在`$HOME/.android/debug.keystore`，如果不存在则会自动创建该文件. 13 | 14 | **debug**构建类型会自动使用**debug**的签名配置. 15 | 16 | 默认配置中可以创建其他配置或者自定义构建.通过**signingConfigs** DSL容器来完成: 17 | ``` groovy 18 | android { 19 | signingConfigs { 20 | debug { 21 | storeFile file("debug.keystore") 22 | } 23 | 24 | myConfig { 25 | storeFile file("other.keystore") 26 | storePassword "android" 27 | keyAlias "androiddebugkey" 28 | keyPassword "android" 29 | } 30 | } 31 | 32 | buildTypes { 33 | foo { 34 | debuggable true 35 | jniDebuggable true 36 | signingConfig signingConfigs.myConfig 37 | } 38 | } 39 | } 40 | ``` 41 | 42 | 上面的代码片段修改了debug keystore的位置到工程的根目录下.设置使用了上述的配置会自动影响其他的构建类型,在上述的例子就是**debug**的构建类型. 43 | 44 | 上述的代码片段使用了新的配置来创建新的签名配置和新的构建类型. 45 | 46 | > 注意: 47 | 只有在默认的路径下的debug keystore会自动创建.改变了debug keystore路径不会按需进行创建.使用默认debug keystore的路径来创建一个不同名称的SigningConfig，还是会在默认路径下创建keystore.换句话说,是否会自动创建keystore，不是根据配置的名称，而是根据keystore的路径. 48 | 49 | **注意:** 50 | > keystore的路径经常使用工程的根路径,也可以使用绝对路径，虽然这样是不推荐的(除了自动创建出来的debug keystore). 51 | 52 | 53 | **注意:** 54 | > **如果你将这些文件添加到版本控制中，你可能不想把密码存储在文件中.下面的`Stack Overflow`解答提供了如何从控制台或者从环境变量中读取密码的方法:** http://stackoverflow.com/questions/18328730/how-to-create-a-release-signed-apk-file-using-gradle 55 | **我们以后会在这个指南中更新更多的详细信息** 56 | -------------------------------------------------------------------------------- /single_projects.md: -------------------------------------------------------------------------------- 1 | # 独立工程 2 | 一个工程将会自动生成测试运行。默认位置： 3 | ``` groovy 4 | build/reports/androidTests 5 | ``` 6 | 7 | 这个和jUnit报告所在位置类似，`build/reports/tests`，其他的报告通常位于` build/reports//`。 8 | 9 | 该位置可以自定义 10 | ```groovy 11 | android { 12 | ... 13 | 14 | testOptions { 15 | reportDir = "$project.buildDir/foo/report" 16 | } 17 | } 18 | ``` 19 | 报告会合并运行在不同设备上的测试结果。 20 | -------------------------------------------------------------------------------- /sourcesets_and_dependencies.md: -------------------------------------------------------------------------------- 1 | # 源组件和依赖 2 | 与Build Type类似，Product Flavor也会通过它们自己的sourceSet提供代码和资源。 3 | 4 | 上面的例子会创建4个_sourceSets_: 5 | * android.sourceSets.flavor1 6 | 位于src/flavor1/ 7 | * android.sourceSets.flavor2 8 | 位于src/flavor2/ 9 | * android.sourceSets.androidTestFlavor1 10 | 位于src/androidTestFlavor1/ 11 | * android.sourceSets.androidTestFlavor2 12 | 位于src/androidTestFlavor2/ 13 | 14 | 这些sourceSet用于构建APK，与android.sourceSets.main 和Build Type的sourceSet类似. 15 | 16 | 下面的规则用于处理所有使用的sourceSet来构建一个APK 17 | * 多个文件夹中的所有的源代码(src/*/java)合并成一个输出 18 | * 所有的Manifest文件都会合并成一个Manifest文件，类似于Build Type，允许Product Flavor可以拥有不同的的组件和权限声明 19 | * 所有使用的资源（Android res和assets）遵循的优先级为Build Type会覆盖Product Flavor，最终覆盖main sourceSet的资源 20 | * 每一个Build Variant都会根据资源生成自己的R类（或者其它一些源代码）。Variant互相之间没有什么是共享的。 21 | 22 | 最终，跟_Build Types_一样，_Product Flavors_也有自己的依赖。例如，如果使用flavor来生成一个基于广告的应用版本和一个付费的应用版本，其中广告版本可能需要依赖于一个广告SDK，但是另一个不需要。 23 | ``` groovy 24 | dependencies { 25 | flavor1Compile "..." 26 | } 27 | ``` 28 | 在这个例子中，src/flavor1/AndroidManifest.xml文件中可能需要声明访问网络的权限。 29 | 30 | 每个Variant也可以创建额外的sourceSet： 31 | * android.sourceSets.flavor1Debug 32 | 位于src/flavor1Debug/ 33 | * android.sourceSets.flavor1Release 34 | 位于src/flavor1Release/ 35 | * android.sourceSets.flavor2Debug 36 | 位于src/flavor2Debug/ 37 | * android.sourceSets.flavor2Release 38 | 位于src/flavor2Release/ 39 | 40 | 这些sourceSet拥有比Build Type的sourceSet更高的优先级，并允许在Variant的层次上做一些定制。 41 | 42 | 43 | -------------------------------------------------------------------------------- /test_reports.md: -------------------------------------------------------------------------------- 1 | # 测试报告 2 | 当运行单元测试，Gradle会输出一份HTML报告，以便查看结果。Android插件也在上面构建，并且扩展HTML的报告文件，它将所有连接的设备的报告都合并到同一个文件里。 3 | -------------------------------------------------------------------------------- /testing.md: -------------------------------------------------------------------------------- 1 | # 测试 2 | 3 | 测试multi-flavors项目非常类似于测试简单的项目。 4 | 5 | `androidTest` sourceSet用于定义所有flavor共用的测试，但是每一个flavor也可以有它自己特有的测试 6 | 7 | 正如前面提到的，每一个flavor都会创建自己的测试sourceSet： 8 | * android.sourceSets.androidTestFlavor1 9 | 位于src/androidTestFlavor1/ 10 | * android.sourceSets.androidTestFlavor2 11 | 位于src/androidTestFlavor2/ 12 | 13 | 同样的，他们可以拥有自己的依赖： 14 | ``` groovy 15 | dependencies { 16 | androidTestFlavor1Compile "..." 17 | } 18 | ``` 19 | 这些测试可以通过main的标志性deviceCheck task或者main的androidTest task（当flavor被使用的时候这个task相当于一个标志性task）来执行 20 | 21 | 每一个flavor也拥有它们自己的task来这行这些测试：androidTest< VariantName>: 22 | * assembleFlavor1Test 23 | * installFlavor1Debug 24 | * installFlavor1Test 25 | * uninstallFlavor1Debug 26 | * ... 27 | 28 | 最终的HTML报告支持根据flavor合并生成。下面是测试结果和报告文件的路径，第一个是每一个flavor版本的结果，后面的是合并起来的结果： 29 | * build/androidTest-results/flavors/ 30 | * build/androidTest-results/all/ 31 | * build/reports/androidTests/flavors 32 | * build/reports/androidTests/all/ 33 | 34 | 可以自定义报告的路径，只需要改变根目录，然后创建per-flavor子目录和聚合报告目录results/reports. 35 | 36 | -------------------------------------------------------------------------------- /testing_android_libraries.md: -------------------------------------------------------------------------------- 1 | # 测试Android库工程 2 | 测试Android库工程和普通应用工程的方法类似。 3 | 4 | 唯一的不同在于整个库(包含它的依赖)都是作为依赖库被自动添加到测试应用中的。结果就是测试APK不仅仅包含了自己的代码，还包含了自己的库和它所有的依赖。 5 | 库的manifest被合并到测试应用manifest文件中(作为 6 | 一些项目引用这个库的壳)。 7 | 8 | **androidTest ** task只是安装(或者卸载)测试APK(因为没有其他APK被安装) 9 | 10 | 其它的都是普通工程类似的。 11 | 12 | 13 | -------------------------------------------------------------------------------- /using_sourcecompatibility_17.md: -------------------------------------------------------------------------------- 1 | # 使用sourceCompatibility 1.7 2 | 使用Android KitKat (buildToolsVersion 19)，你可以使用diamond operator，multi-catch，switch中使用字符串，try with resource等等。为了实现这个，添加下面的配置。 3 | ``` groovy 4 | android { 5 | compileSdkVersion 19 6 | buildToolsVersion "19.0.0" 7 | 8 | defaultConfig { 9 | minSdkVersion 7 10 | targetSdkVersion 19 11 | } 12 | 13 | compileOptions { 14 | sourceCompatibility JavaVersion.VERSION_1_7 15 | targetCompatibility JavaVersion.VERSION_1_7 16 | } 17 | } 18 | ``` 19 | > 注意： 你可以设置 use **minSdkVersion **的值小于19，不过你只能使用除了try with resources之外的其他语言特性。如果要想使用try with resources特性，你必须设置使用use **minSdkVersion **版本为19. 20 | 21 | 你同样需要确认Gradle是否使用1.7或者更高版本的JDK。(Android Gradle plugin也需要0.6.1或者更高版本。) 22 | -------------------------------------------------------------------------------- /why_gradle.md: -------------------------------------------------------------------------------- 1 | # 为什么使用Gradle? 2 | Gradle是一个优秀的根据系统和构建工具，它允许通过插件来创建自定义的构建逻辑。 3 | 4 | 以下的一些特性，让我们选择了Gradle： 5 | * 使用领域专用语言(DSL)来描述和控制构建逻辑 6 | * 构建文件基于Groovy，并允许通过DSL声明和使用代码混合来定义DSL元素和自定义的构建逻辑 7 | * 内置通过Maven和Ivy进行依赖管理 8 | * 相当灵活。允许使用最好的实现，但是不会强制实现的形式。 9 | * 插件提供DSL和API来定义构建文件 10 | * 优秀的API工具与IDE集成 11 | 12 | --------------------------------------------------------------------------------