Gradle Plugin User Guide

from——http://tools.android.com/tech-docs/new-build-system/user-guide

1 Introduction

Goals of the new Build System

The goals of the new build system are:

• Make it easy to reuse code and resources
• Make it easy to create several variants of an application, either for multi-apk distribution or for different flavors of an application
• Make it easy to configure, extend and customize the build process
• Good IDE integration

1.1 Why Gradle?

Gradle is an advanced build system as well as an advanced build toolkit allowing to create custom build logic through plugins. Here are some of its features that made us choose Gradle:

• Domain Specific Language (DSL) based on Groovy, used to describe and manipulate the build logic
• Build files are Groovy based and allow mixing of declarative elements through the DSL and using code to manipulate the DSL elements to provide custom logic.
• Built-in dependency management through Maven and/or Ivy.
• Very flexible. Allows using best practices but doesnrsquo;t force its own way of doing things.
• Plugins can expose their own DSL and their own API for build files to use.
• Good Tooling API allowing IDE integration

1.2 Requirements

• Gradle 2.2
• SDK with Build Tools 19.0.0. Some features may require a more recent version.

2 Basic Project Setup

A Gradle project describes its build in a file called build.gradle located in the root folder of the project. (See Gradle User Guide for an overview of the build system itself.)

2.1 Simple build files

The most simple Android project has the following build.gradle:

buildscript {

repositories {

jcenter()

}

dependencies {

classpath com.android.tools.build:gradle:1.3.1

}

}

apply plugin: com.android.application

android {

compileSdkVersion 23

buildToolsVersion '23.1.0'
}

There are 3 main areas to this Android build file:

buildscript { ... } configures the code driving the build. In this case, this declares that it uses the jCenter repository, and that there is a classpath dependency on a Maven artifact. This artifact is the library that contains the Android plugin for Gradle in version 1.3.1. Note: This only affects the code running the build, not the project. The project itself needs to declare its own repositories and dependencies. This will be covered later.

Then, the com.android.application plugin is applied. This is the plugin used for building Android applications.

Finally, android { ... } configures all the parameters for the android build. This is the entry point for the Android DSL. By default, only the compilation target, and the version of the build-tools are needed. This is done with the compileSdkVersion and buildtoolsVersion properties.

The compilation target is the same as the target property in the project.properties file of the old build system. This new property can either be assigned a int (the api level) or a string with the same value as the previous target property.

Important: You should only apply the com.android.application plugin. Applying the java plugin as well will result in a build error.

Note: You will also need a local.properties file to set the location of the SDK in the same way that the existing SDK requires, using the sdk.dir property.

Alternatively, you can set an environment variable called ANDROID_HOME. There

is no differences between the two methods, you can use the one you prefer.

Example local.properties file:

sdk.dir=/path/to/Android/Sdk

2.2 Project Structure

The basic build files above expects a default folder structure. Gradle follows the concept of convention over configuration, providing sensible default option values when possible. The basic project starts with two components called “source sets”, one for the main source code and one for the test code. These live respectively in:

• src/main/
• src/androidTest/

Inside each of these directories there are subdirectories for each source component. For both the Java and Android plugin, the location of the Java source code and the Java resources are:

• java/
• resources/

For the Android plugin, extra files and folders specific to Android:

• AndroidManifest.xml
• res/
• assets/
• aidl/
• rs/
• jni/
• jniLibs/

This means that *.java files for the main source set are located in src/main/java and the main manifest is src/main/AndroidManifest.xml

Note: src/androidTest/AndroidManifest.xml is not needed as it is created automatically.

2.2.1 Configuring the Structure

When the default project structure isnrsquo;t adequate, it is possible to configure it. See this page in gradle documentation for information how this can be done for pure-java projects.

The Android plugin uses a similar syntax, but because it uses its own sourceSets, this is done within the android block. Herersquo;s an example, using the old project structure (used in Eclipse) for the main code and remapping the androidTest

剩余内容已隐藏，支付完成后下载完整资料

---

Gradle 插件用户指南

摘自——http://tools.android.com/tech-docs/new-build-system/user-guide

1 介绍

新构建系统的目标

新构建系统的目标是：

·可以很容易地重用代码和资源

·可以很容易地创建应用程序的几个变种，无论是多APK分发还是不同定制版的应用程序

·可以很容易地配置、 扩展和自定义构建过程

·良好的IDE集成

1.1 为何选择Gradle？

Gradle 是一个先进的构建系统和构建工具，它允许通过插件创建自定义的构建逻辑。基于Gradle的以下特点，我们选择了它：

·域特定语言（DSL）来描述和处理构建逻辑

·构建文件基于Groovy，并允许通过 DSL来混合声明性元素，以及使用代码来处理 DSL 元素以提供自定义逻辑。

·基于 Maven 和 Ivy 的内置依赖管理。

·非常灵活。允许使用最佳实现，但并不强制自己的实现方式。

·插件可以提供自己的 DSL 和API供构建文件使用。

·良好的Tooling API 供 IDE 集成

要求

·Gradle 版本需要2.2

·SDK Build Tools版本要求为19.0.0。某些功能可能需要更新版本。

2 基本项目

Gradle 项目在项目的根文件夹里的build.gradle文件中描述它的构建逻辑。

2.1 简单的构建文件

最简单的Android项目具有以下build.gradle：

buildscript {

repositories {

jcenter()

}

dependencies {

classpath com.android.tools.build:gradle:1.3.1

}

}

apply plugin: com.android.application

android {

compileSdkVersion 23

buildToolsVersion '23.1.0'

}

这个Android构建文件有3个主要区域：

buildscript { ... }配置了驱动构建的代码。

在上面的这种情况中，它声明了使用 Maven 中央库，并且对一个Maven 文件有一个类路径依赖。这个文件是包含 Gradle Android 插件的 1.3.1版本的库

注： 这只会影响运行构建的代码，不会影响项目的源代码。项目本身需要定义它自己的仓库和依赖关系。稍后会提及这部分。

然后，和先前的提到的 Java 插件一样，这里配置使用了 android插件。

最后， android { ... }配置了用于 android 构建的所有参数。这是Android DSL的入口。

默认情况下，只需要配置编译目标，以及build-tools的版本。它通过compileSdkVersion和buildtoolsVersion属性来完成。

编译目标相当于旧的构建系统中project.properties 文件内的target属性。这个新的属性可以设置为一个 int 值 (表示api 级别），或者是和以前的target的值一样，设置为字符串。

重要提示：你应该只配置使用这个android插件。如果同时配置使用了java插件也会导致构建错误。

注意：您还需要local.properties文件，以使用sdk.dir属性以与现有SDK所需的方式相同的方式设置SDK的位置。

或者，您可以设置一个名为ANDROID_HOME的环境变量。这两种方法没有区别，您可以使用您喜欢的方法。

示例local.properties文件：

sdk.dir=/path/to/Android/Sdk

2.2 项目结构

上述的基本构建文件要求有一个默认的文件夹结构。Gradle 遵循约定大于配置的概念，在可能的情况下提供了合理的默认选项值。

基本项目开始于两个名为“source sets”的组件。即主源代码和测试代码。它们分别在：

·src/main/

·src/androidTest/

里面的每个文件夹中都存在对应的源代码组件的文件夹。

对于Java和Android插件，Java源代码和Java资源的位置如下：

·Java/

·resources/

对于Android 插件，Android所特有的额外的文件和文件夹是：

·AndroidManifest.xml

·res/

·assets/

·aidl /

·rs/

·jni/

·jniLibs/

这意味着主源集的* .java文件位于src / main / java中，主清单文件谓语是src / main / AndroidManifest.xml中

注意： src/androidTest/AndroidManifest.xml是不需要的，因为它会被自动创建。

2.2.1 配置项目结构

当默认项目结构不足时，可以对其进行配置。有关如何为纯java项目执行此操作的信息，请参阅gradle文档中的此页面。

Android插件使用类似的语法，但因为它使用自己的sourceSets ，这是在android块中完成的。 这是一个示例，使用旧的项目结构（在Eclipse中使用）作为主代码并将androidTest sourceSet重新映射到 tests 文件夹：

android {

sourceSets {

main {

manifest.srcFile AndroidManifest.xml

java.srcDirs = [src]

resources.srcDirs = [src]

aidl.srcDirs = [src]

renderscript.srcDirs = [src]

res.srcDirs = [res]

assets.srcDirs = [assets]

}

androidTest.setRoot(tests)

}

}

注意：因为旧的结构把所有源文件 （java、aidl、 renderscript和 java资源）都放在相同的文件夹中，我们需要重新映射sourceSet的所有这些新组件到相同的src文件夹中。

注意： setRoot()会将整个sourceSet （和它的子文件夹） 移到一个新的文件夹中。这将移动src/androidTest/*到tests/*下。这是 Android 专用的，不适用于 Java sourceSets。

2.3 构建任务

2.1 常规任务

将插件应用于构建文件会自动创建一组要运行的构建任务。Java插件和Android插件都可以做到这一点。 任务约定如下：

·assemble

组装项目输出的任务。

·check

运行所有检查的任务。

·build

此任务同时进行 assemble 和 check。

·clean

此任务清除项目的输出。

assemble，check和build这些任务，实际上不做任何事情。他们是锚记任务，用于让插件添加实际的任务去做这些事情。这允许您能够调用同样的任务，无论项目的类型是什么，或者是配置使用了什么插件

这使您可以始终调用相同的任务，无论项目类型是什么，或者应用了哪些插件。例如，应用findbugs插件将创建一个新任务，并 根据它进行check，每当调用check任务时都会调用它。

您可以从命令行获得运行以下命令的高级任务：

gradle tasks

要获取完整列表并查看运行的任务之间的依赖关系：

Gradle tasks -all

注意： Gradle会自动监视任务的已声明输入和输出。

在不更改项目的情况下运行build任务两次，将使Gradle将所有任务报告为UP-TO-DATE，这意味着不需要任何工作。这允许任务在不需要不必要的构建操作的情况下正确地相互依赖。

2.2 Java项目任务

以下是java插件创建的两个最重要的任务，即主要锚点任务的依赖关系：

·assemble

·jar

此任务创建输出。

·check

·test

此任务运行测试。

jar任务本身会直接或间接地依赖其他任务： 例如，classes任务用于编译 Java 代码。 测试是使用testClasses编译的，但调用它很少被调用，因为test 依赖于它（以及class）。

通常，您可能只会调用 assemble或 check，而忽略其他任务。您可以在此处查看 Java插件的完整任务集及其描述。

2.3 Android任务

Android插件使用相同的约定与其他插件保持兼容，并添加了一个额外的锚任务：

·assemble

组装项目输出的任务。

·check

运行所有check的任务。

·connectedCheck

运行需要连接设备或仿真器的检查。它们将并行运行在所有连接的设备上。

·deviceCheck

使用API​​运行检查以连接到远程设备。这用于CI服务器。

·build

此任务同时进行 assemble 和 check

·clean

此任务清除项目的输出。

新的锚点任务是必要的，以便能够在不需要连接设备的情况下运行定期检查。请注意，build不依赖于 deviceCheck或connectedCheck。

Android项目至少有两个输出：调试APK和发布APK。其中每个都有自己的锚任务，以便于单独构建它们：

·assemble

·assembleDebug

·assembleRelease

它们都依赖于执行构建APK所需的多个步骤的其他任务。该assemble任务则依赖于这两个任务，因此调用将建立双方的APKs。

提示：在命令行上，Gradle 支持任务名称的驼峰命名法的简写。例如：

gradle aR

相当于输入：

gradle assembleRelease

只要没有其他任务匹配aR ，check锚记任务就有自己的依赖关系：

·check

·lint

·connectedCheck

·connectedA ndroidTest

·deviceCheck

·这取决于其他插件实现测试扩展点时创建的任务。

剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[19940]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

您可能感兴趣的文章

• 使用金属伪影减少算法从 CT 数据生成的数字模型的准确性外文翻译资料
• 彩色光流外文翻译资料
• 云环境下基于虚拟机配置文件针对DDOS攻击的最优网络攻击探测方法外文翻译资料
• 监控大视频数据分析中的模糊逻辑: 综述、挑战和研究方向外文翻译资料
• PeopleSoft人力资源管理系统实施外文翻译资料
• 图像绗缝的纹理合成与转移外文翻译资料
• 管理云中的资源:Chrome扩展到OpenStack外文翻译资料
• 一种基于凸显区域检测和SPBVM的美学QR码新算法外文翻译资料
• 微信小程序-所有你需要知道外文翻译资料
• Java核心技术卷II高级特性外文翻译资料