当前位置:   article > 正文

Gradle for Android 翻译 -1

Gradle for Android 翻译 -1
参考: Gradle for Android  

一、从 Gradle 和 AS 开始

【Getting Started with Gradle  and Android Studio】

When Google introduced Gradle and Android Studio, they had some goals in mind. They wanted to make it easier to reuse code, create build variants, and configure and customize the build process. On top of that, they wanted good IDE integration, but without making the build system dependent on the IDE. Running Gradle from the command line or on a continuous integration server will always yield the same results as running a build from Android Studio. 


We will refer to Android Studio occasionally throughout the book, because it often provides a simpler way of setting up projects, dealing with changes, and so on. If you do not have Android Studio installed yet, you can download it from the Android developer website ( http://developer.android.com/sdk/index.html ). 


In this chapter, we will cover the following topics:

  • Getting to know Android Studio
  • Understanding Gradle basics
  • Creating a new project
  • Getting started with the Gradle wrapper
  • Migrating from Eclipse


当Google推出Gradle和Android Studio时,他们有一些目标。他们希望能够更轻松地重用代码,创建构建变量,以及配置和定制构建过程。最重要的是,他们希望有良好的IDE集成,但是不要使构建系统依赖于IDE。通过命令行或持续集成服务器运行Gradle将始终产生与通过Android Studio运行构建相同的结果。

我们将在本书中偶尔提及Android Studio,因为它经常提供一个更简单的方法来设置项目,处理更改等等。 如果您还没有安装Android Studio,可以从Android开发者网站下载。

在本章中,我们将介绍以下主题:

  • 开始了解Android Studio
  • 了解Gradle基础
  • 创建一个新的项目
  • 开始使用Gradle wrapper
  • 从Eclipse迁移


理解基本的Gradle *

【Understanding Gradle basics】
In order for an Androi d project to be built using Gradle, you need to set up a build  script. This will always be called  build.gradle , by convention. You will notice,  as we go through the basics, that Gradle favors convention over configuration and  generally provides default values for settings and properties. This makes it a lot  easier to get started with a lot less configuration than that found in systems such as  Ant or Maven, which have been the de facto build systems for Android projects for  a long time. You do not need to absolutely comply with these conventions though,  as it is usually possible to override them if needed.

Gradle build scripts are not written in the traditional XML, but in a domain-specific  language (DSL) based on Groovy, a dynamic language for the Java Virtual Machine  (JVM). The team behind Gradle believes that using a declarative, DSL-style approach  based on a dynamic language has significant advantages over using the more  procedural, free-floating style of Ant, or any XML-based approach used by many  other build systems.

That does not mean you need to know Groovy to get started with your build scripts.  It is easy to read, and if you already know Java, the learning curve is not that steep.  If you want to start creating your own tasks and plugins (which we will talk about  in later chapters), it is useful to have a deeper understanding of Groovy. However,  because it is based on the JVM, it is possible to write code for your custom plugins in  Java or any other JVM-based language.

为了使用Gradle构建Android项目,您需要设置构建脚本。这将总是被称为build.gradle,按照惯例。在我们了解基本知识的时候,您会注意到,Gradle偏向约定而不是配置,并且通常会为设置和属性提供默认值。这使得比使用Ant或Maven这样的系统容易得多,那些系统实际上已经成为Android项目的构建系统很长一段时间了。尽管如此,您并不需要绝对遵守这些约定,因为如果需要的话,通常可以重写它们。
Gradle构建脚本不是用传统的XML编写的,而是用基于Groovy的DSL(Domain Specified Language,领域专用语言)编写的,Groovy是基于JVM的一种动态语言。Gradle背后的团队认为,使用基于动态语言的声明式DSL风格的方法,比使用......   或任何其他基于XML的构建系统,具有明显的优势
这并不意味着您需要了解Groovy才能开始构建脚本。该语言很容易阅读,如果你已经知道Java,学习曲线并不那么陡峭。如果您想开始创建自己的tasks和插件(我们将在后面的章节中讨论),那么对Groovy有更深入的了解是非常有用的。但是,因为它基于JVM,所以可以使用Java或任何其他基于JVM的语言(比如最近比较火热的kotlin)编写自定义插件的代码


Project和tasks

【Projects and tasks】
The two most important concepts in Gradle are projects and tasks. 
Every build  is made up of at least one project, and every project contains one or more tasks.
Every build.gradle file represents a project. Tasks are then simply defined inside  the build script. 
When initializing the build process, Gradle assembles Project and  Task objects based on the build file. 
A Task object consists of a list of  Action objects,  in the order they need to be executed. 
An Action object is a block of code that is  executed, similar to a method in Java.

在gradle中有两大重要的概念,分别是project和tasks

每一个构建都由至少一个project组成,每个project都至少包含一个tasks

每一个build.gradle文件代表着一个project,tasks在build.gradle中定义

当初始化构建进程时,gradle会基于build文件,组合所有的project和tasks。

一个tasks包含了一系列的动作,它们会按照顺序执行

一个动作就是一段被执行的代码,它们很像Java中的方法


build生命周期

【The build lifecycle】
Executing a Gradle build is, in its simplest form, just executing actions on tasks,  which are dependent on other tasks. 
To simplify the build process, the build tools  create a dynamic model of the workflow as a Directed Acyclic Graph (DAG). 
This means all the tasks are processed one after the other and loops are not possible
Once a task has been executed, it will not be called again. 
Tasks without dependencies  will always be run before the others
The dependency graph is generated during the  configuration phase of a build. 

A Gradle build has three phases: 
•  Initialization: This is where the  Project instance is created. If there are  multiple modules, each with their own  build.gradle file, multiple projects  will be created.
•  Configuration: In this phase, the build scripts are executed, creating and  configuring all the tasks for every project object.
•  Execution: This is the phase where Gradle determines which tasks should be  executed. Which tasks should be executed depends on the arguments passed  for starting the build and what the current directory is.

执行Gradle构建最简单的形式就是,执行 task中的action(这些action 依赖于其他 task)
为了简化构建过程,构建工具创建了一个有向无环图(DAG)的工作流动态模型。
这意味着所有的task将被一个接一个地处理,循环是不可能的。
一旦一个task被执行,它将不会被再次被调用。
没有依赖关系的task将始终在其他task之前运行。
依赖关系图是在构建的配置阶段生成的。

一次构建将会经历下列三个阶段:

  • 初始化阶段:project实例在这儿创建,如果有多个模块,即有多个build.gradle文件,多个project将会被创建。
  • 配置阶段:在该阶段,build.gradle脚本将会执行,为每个project创建和配置所有的tasks。
  • 执行阶段:这一阶段,gradle会决定哪一个tasks会被执行。哪一个tasks会被执行完全依赖于,开始构建时传入的参数,和当前所在的文件夹位置等。

build配置文件

【The build configuration file】
In order to have Gradle build a project, there always needs to be a  build.gradle  file. A build file for Android has a few required elements:...
This is where the actual build is configured. 

In the repositories block, the JCenter repository is configured as a source of dependencies for the build script. JCenter is a preconfigured Maven repository and requires no extra setup; Gradle has you covered. There are several repositories available straight from Gradle and it is easy to add your own, either local or remote. 


The build script block also defines a dependency on Android build tools as a classpath Maven artifact. This is where the Android plugin comes from. The Android plugin provides everything needed to build and test applications. Every Android project needs to apply the Android plugin using this line:

apply plugin: 'com.android.application' 

Plugins are used to extend the capabilities of a Gradle build script. Applying a plugin to a project makes it possible for the build script to define properties and use tasks that are defined in the plugin. 


If you are building a library, you need to apply 'com.android. library' instead. You cannot use both in the same module because that would result in a build error. A module can be either an Android application or an Android library, not both. 


When using the Android plugin, Android-specific conventions can be configured and tasks only applicable to Android will be generated. The Android block in the following snippet is defined by the plugin and can be configured per project: 

android { compileSdkVersion 22 buildToolsVersion "22.0.1" } 

This is where the Android-specific part of the build is configured. The Android plugin provides a DSL tailored to Android's needs. The only required properties are the compilation target and the build tools. The compilation target, specified by compileSdkVersion , is the SDK version that should be used to compile the app. It is good practice to use the latest Android API version as the compilation target. 


There are plenty of customizable properties in the  build.gradle file. We will discuss the most important properties in Chapter 2, Basic Build Customization, and more possibilities throughout the rest of the book.


为了让Gradle构建一个项目,总是需要一个build.gradle文件。Android的构建文件有几个必需的元素:
  1. buildscript {
  2. repositories {
  3. jcenter() //存储库
  4. }
  5. dependencies {
  6. classpath 'com.android.tools.build:gradle:1.2.3'
  7. }
  8. }
 
1
buildscript {
2
   repositories {
3
        jcenter()    //存储库
4
   }
5
   dependencies {
6
       classpath 'com.android.tools.build:gradle:1.2.3'
7
 } 
8
}

这就是对实际构建所做的配置。


在存储库块中,JCenter存储库被配置为构建脚本的依赖关系的来源。 JCenter是一个预先配置的Maven仓库,不需要额外的设置,Gradle中有你的覆盖。从Gradle中可以直接找到几个存储库,很容易添加你自己的或本地的或远程的。

构建脚本块还将Android构建工具的依赖性定义为类路径Maven构件。这就是Android plugin的来源之处。Android插件提供了构建和测试应用程序所需的一切。每个Android项目都需要使用这一行来应用Android插件:

apply plugin: 'com.android.application'
1
1
 
1
apply plugin: 'com.android.application'

插件用于扩展Gradle构建脚本的功能。在一个项目中使用插件,这样该项目的构建脚本就可以定义该插件定义好的属性和使用它的tasks。


注意:当你在开发一个依赖库时,你应该使用:

apply plugin: 'com.android.library'
 
1
apply plugin: 'com.android.library'

你不能在同一个模块中使用两者,这会导致构建错误。模块可以是Android应用程序或Android库,而不能两者都是。


使用Android插件时,可以配置特定于Android的约定,并仅生成适用于Android的task。以下代码段中的Android代码块由插件定义,可以为每个项目配置:

  1. android {
  2. compileSdkVersion 22
  3. buildToolsVersion "22.0.1"
  4. }
4
4
 
1
android {
2
       compileSdkVersion 22
3
       buildToolsVersion "22.0.1"
4
}

这是构建Android特定部分的地方。Android插件提供了一个适合Android需求的DSL。唯一需要的属性是编译目标和构建工具。由compileSdkVersion指定的编译目标是用于编译应用程序的SDK版本。使用最新的Android API版本作为编译目标是一个很好的做法。

build.gradle文件中有很多可定制的属性。我们将在第二章“基本构建定制”中讨论最重要的属性,以及通过本书其余部分讨论更多可能性。


项目结构

【The project structure】
Compared to the old Eclipse projects, the folder structure for Android projects has changed considerably. As mentioned earlier, Gradle favors convention over configuration and this also applies to the folder structure. 

This is the folder structure that Gradle expects for a simple app:  ... 

Gradle projects usually have an extra level at the root. This makes it easier to add extra modules at a later point. All source code for the app goes into the app folder. The folder is also the name of the module by default and does not need to be named app. If you use Android Studio to create a project with both a mobile app and an Android Wear smartwatch app, for example, the modules are called application and wearable by default. 

Gradle makes use of a concept called source set. The official Gradle documentation explains that a source set is a group of source files, which are compiled and executed together. For an Android project,  main is the source set that contains all the source code and resources for the default version of the app. When you start writing tests for your Android app, you will put the source code for the tests inside a separate source set called  androidTest , which only contains tests. 

与旧的Eclipse项目相比,Android项目的文件夹结构发生了很大变化。正如前面提到的,Gradle偏向于"约定优于配置",这也适用于文件夹结构。
这是Gradle期望的简单应用程序的文件夹结构:
  1. MyApp
  2. ├── build.gradle
  3. ├── settings.gradle
  4. └── app
  5. ├── build.gradle
  6. ├── build //The output of the build process
  7. ├── libs //These are external libraries (.jar or .aar)
  8. └── src
  9. └── main
  10. ├── java //The source code for the app
  11. │ └── com.package.myapp
  12. └── res //These are app-related resources (drawables, layouts, strings, and so on)
  13. ├── drawable
  14. ├── layout
  15. └── etc.
15
15
 
1
MyApp
2
  ├── build.gradle
3
  ├── settings.gradle
4
  └── app
5
      ├── build.gradle
6
      ├── build    //The output of the build process
7
      ├── libs    //These are external libraries (.jar or .aar)
8
      └── src
9
          └── main
10
              ├── java    //The source code for the app
11
                 └── com.package.myapp
12
              └── res    //These are app-related resources (drawables, layouts, strings, and so on)
13
                  ├── drawable
14
                  ├── layout
15
                  └── etc.

Gradle项目通常在根目录上有一个额外的级别。这使得稍后添加额外的模块变得更容易。应用程序所有源代码被放在app文件夹中。该文件夹也是默认模块的名称,并且 不是必须被命名为app。例如,如果您使用Android Studio创建一个包含移动应用程序和Android Wear智能手表应用程序的项目,则默认情况下这些模块被称为 applicationwearable

Gradle使用了一个叫做source set的概念,Gradle官方文档解释说:一个source set就是一系列资源文件,它们被一起编译和执行。对于Android项目,main就是一个包含了应用程序默认版本所有源代码和资源的source set当你开始为你的Android应用程序编写测试时,你将把测试的源代码放在一个名为androidTest的独立源代码集中,它只包含测试。


Gradle Wrapper入门

【Getting started with the Gradle Wrapper】
Gradle is a tool that is under constant development, and new versions could potentially break backward compatibility. Using the Gradle Wrapper is a good way to avoid issues and to make sure builds are reproducible. 

The Gradle Wrapper provides a batch file on Microsoft Windows and a shell script on other operating systems. When you run the script, the required version of Gradle is downloaded (if it is not present yet) and used automatically for the build. The idea behind this is that every developer or automated system that needs to build the app can just run the wrapper, which will then take care of the rest. This way, it is not required to manually install the correct version of Gradle on a developer machine or build server. Therefore, it is also recommended to add the wrapper files to your version control system. 

Running the Gradle Wrapper is not that different from running Gradle directly. You just execute  gradlew on Linux and Mac OS X and  gradlew.bat on Microsoft Windows, instead of the regular  gradle command.

Gradle是一个不断发展的工具, 新版本可能会破坏向后兼容性。使用Gradle Wrapper是避免此问题并确保构建可重复的好方法。
Gradle Wrapper 提供了一个Windows系统上 batch文件(批处理文件)和其他操作系统上的shell脚本 文件。当你运行这个脚本时,将会下载所需的Gradle版本(如果它还不存在),并自动用于构建。这个背后的想法是,每个需要构建应用程序的开发人员或自动化系统都可以运行Gradle Wrapper,然后由其来处理。这样,就 不需要在开发人员的机器上或构建服务器上手动安装正确版本的Gradle。因此,我们还建议您将Gradle Wrapper文件添加到您的版本控制系统中。
运行Gradle Wrapper与直接运行Gradle没有什么不同。您只需在Linux和Mac OS X上执行gradlew,在Microsoft Windows上执行 gradlew.bat,以代替使用常规的 gradle命令。


获取Gradle Wrapper

【Getting the Gradle Wrapper】

For your convenience, every new Android project includes the Gradle Wrapper, so when you create a new project, you do not have to do anything at all to get the necessary files. It is, of course, possible to install Gradle manually on your computer and use it for your project, but the Gradle Wrapper can do the same things and guarantee that the correct version of Gradle is used. There is no good reason not to use the wrapper when working with Gradle outside of Android Studio. 


You can check if the Gradle Wrapper is present in your project by navigating to the project folder and running  ./gradlew –v from the terminal or  gradlew.bat –v from Command Prompt. Running this command displays the version of Gradle and some extra information about your setup. If you are converting an Eclipse project, the wrapper will not be present by default. In this case, it is possible to generate it using Gradle, but you will need to install Gradle first to get the wrapper.


After you have downloaded and installed Gradle and added it to your  PATH , create a build.gradle file containing these three lines: 

task wrapper(type: Wrapper) { gradleVersion = '2.4' } 

After that, run  gradle wrapper to generate the wrapper files. 


In recent versions of Gradle, you can also run the wrapper task without modifying the  build.gradle file, because it is included as a task by default. In that case, you can specify the version with the  --gradle-version parameter, like this: 

$ gradle wrapper --gradle-version 2.4 

If you do not specify a version number, the wrapper is configured to use the Gradle version that the task is executed with. 


These are all the files generated by the wrapper task:...

The  gradle-wrapper.properties file is the one that contains the configuration and determines what version of Gradle is used:...

You can change the distribution URL if you want to use a customized Gradle distribution internally. This also means that any app or library that you use could have a different URL for Gradle, so be sure to check whether you can trust the properties before you run the wrapper. 


Android Studio is kind enough to display a notification when the Gradle version used in a project is not up to date and will suggest automatically updating it for you. Basically, Android Studio changes the configuration in the  gradle-wrapper. properties file and triggers a build, so that the latest version gets downloaded.


PS:Android Studio uses the information in the properties to determine which version of Gradle to use, and it runs the wrapper from the Gradle Wrapper directory inside your project. However, it does not make use of the shell or bash scripts, so you should not customize those.


为了方便起见,每个新的Android项目都包含了Gradle Wrapper,所以当你创建一个新的项目时,你不需要做任何事情来获取必要的文件。当然,可以在您的计算机上手动安装Gradle,并将其用于您的项目,但Gradle Wrapper可以做同样的事情,并保证使用正确版本的Gradle。在Android Studio之外使用Gradle时,没有理由不使用Gradle Wrapper


您可以通过导航到项目文件夹并从终端或命令行运行【gradlew -v】或【gradlew.bat -v】来检查项目中是否存在Gradle Wrapper。运行此命令将显示Gradle的版本以及有关您设置的一些额外信息。

795730-20171129220425636-641449889.png
PS:如果 gradle-wrapper.properties 中的 distributionUrl 指定的不是本地路径的 Gradle,而是网络路径,那么执行此命令后,不管本地是不是已经下载过此版本的Gradle,都会重新下载,且时间会非常长。
795730-20171129220425870-1868254031.png

如果你正在转换一个Eclipse项目,默认情况下,wrapper将不会出现。 在这种情况下,可以使用Gradle生成它,但是您需要首先安装Gradle来获取wrapper。


在您下载并安装Gradle并将其添加到PATH后,创建一个包含以下三行的 build.gradle 文件(白注:在根目录下的 build.gradle 文件中添加以下代码即可):

  1. task wrapper(type: Wrapper) {
  2. gradleVersion = '2.4'
  3. }
x
 
1
task wrapper(type: Wrapper) {
2
    gradleVersion = '2.4'
3
}

之后,运行Gradle Wrapper来生成Wrapper文件(白注:添加上述代码后同步一下即可生成完整的 gradle 目录)。


在最近的Gradle版本中,你也可以在不修改 build.gradle 文件的情况下运行 wrapper task,因为默认情况下它被包含为一个task。在这种情况下,您可以使用【--gradle-version】参数指定版本,如下所示:

gradle wrapper --gradle-version 2.4 
 
1
gradle wrapper --gradle-version 2.4 

如果不指定版本号,则将wrapper配置为使用执行task的Gradle版本。


下列是由wrapper task生成的所有文件:

  1. myapp/
  2. ├── gradlew //针对Linux和Mac系统的shell脚本文件, A shell script on Linux and Mac OS X
  3. ├── gradlew.bat //针对windows系统的bat文件,A batch file on Microsoft Windows
  4. └── gradle/wrapper/
  5. ├── gradle-wrapper.jar //A JAR file that is used by the batch file and shell script
  6. └── gradle-wrapper.properties //配置文件,A properties file,用于确定使用哪个版本的Gradle
x
 
1
myapp/
2
├── gradlew    //针对Linux和Mac系统的shell脚本文件, A shell script on Linux and Mac OS X
3
├── gradlew.bat    //针对windows系统的bat文件,A batch file on Microsoft Windows
4
└── gradle/wrapper/
5
    ├── gradle-wrapper.jar    //A JAR file that is used by the batch file and shell script
6
    └── gradle-wrapper.properties    //配置文件,A  properties file,用于确定使用哪个版本的Gradle

【gradle-wrapper.properties】文件是一个包含配置并确定使用哪个版本的Gradle的文件:

  1. #Sat May 30 17:41:49 CEST 2015
  2. distributionBase=GRADLE_USER_HOME
  3. distributionPath=wrapper/dists
  4. zipStoreBase=GRADLE_USER_HOME
  5. zipStorePath=wrapper/dists
  6. distributionUrl=https\://services.gradle.org/distributions/gradle-2.4-all.zip
 
1
#Sat May 30 17:41:49 CEST 2015
2
   distributionBase=GRADLE_USER_HOME
3
   distributionPath=wrapper/dists
4
   zipStoreBase=GRADLE_USER_HOME
5
   zipStorePath=wrapper/dists
6
   distributionUrl=https\://services.gradle.org/distributions/gradle-2.4-all.zip

如果您想在内部使用定制的Gradle,则可以更改URL(可以使用本地路径)。这也意味着您使用的任何应用程序或库都可能具有不同的Gradle URL,因此请务必在运行wrapper之前检查是否可以信任这些属性。

如果项目中使用的Gradle版本不是最新的,Android Studio会提供足够的通知,并且会建议您自动更新。基本上,Android Studio更改gradle-wrapper.properties中的配置并触发构建,以便下载最新版本。


注意:Android Studio使用properties中的信息来确定使用哪个版本的Gradle,并运行你工程中Gradle Wrapper目录的wrapper。但是,它并没有使用shell或bash脚本,所以你不应该自定义这些。


运行基本build任务

【Running basic build tasks】
In the terminal or command prompt, navigate to the project directory and run the  Gradle Wrapper with the  tasks command: gradlew tasks
This will print out a list of all the available tasks. If you add the --all parameter, you will get a more detailed overview with the dependencies for every task. 
PS:On Microsoft Windows, you need to run gradlew.bat, and on Linux and Mac OS X, the full command is ./gradlew. For the sake of brevity, we will just write gradlew throughout this book. 

To build the project while you are developing, run the assemble task with the debug configuration: $ gradlew assembleDebug 
This task will create an APK with the debug version of the app. By default, the Android plugin for Gradle saves the APK in the directory  MyApp/app/build/ outputs/apk

PS:Abbreviated task names To avoid a lot of typing in the terminal, Gradle also provides abbreviated Camel case task names as shortcuts. For example, you can execute assembleDebug by running gradlew assDeb, or even gradlew aD, from the command-line interface. There is one caveat to this though. It will only work as long as the Camel case abbreviation is unique. As soon as another task has the same abbreviation, this trick does not work anymore for those tasks.

Besides  assemble , there are three other basic tasks:
  • check:runs all the checks, this usually means running tests on a connected device or emulator
  • build:triggers both  assemble and  check
  • clean:cleans the output of the project
We will discuss these tasks in detail in Chapter 2, Basic Build Customization.

在终端或命令提示符下,导航到项目目录并使用tasks命令运行 Gradle Wrapper:
gradlew tasks
 
1
gradlew tasks

这将打印出所有可用task列表(白注:第一次使用此命令会下载一些东西,大概要六到八分钟)。如果添加--all参数,则可以获得有关每个task的依赖性的更详细概述。

白注:这些列表和AS中Gradle面板中的一致。

795730-20171129220426151-69372659.png

  1. > Task :tasks
  2. ------------------------------------------------------------
  3. All tasks runnable from root project
  4. ------------------------------------------------------------
  5. Android tasks
  6. -------------
  7. androidDependencies - Displays the Android dependencies of the project.
  8. signingReport - Displays the signing info for each variant.
  9. sourceSets - Prints out all the source sets defined in this project.
  10. Build tasks
  11. -----------
  12. assemble - Assembles all variants of all applications and secondary packages.
  13. assembleAndroidTest - Assembles all the Test applications.
  14. assembleDebug - Assembles all Debug builds.
  15. assembleRelease - Assembles all Release builds.
  16. build - Assembles and tests this project.
  17. buildDependents - Assembles and tests this project and all projects that depend on it.
  18. buildNeeded - Assembles and tests this project and all projects it depends on.
  19. clean - Deletes the build directory.
  20. cleanBuildCache - Deletes the build cache directory.
  21. compileDebugAndroidTestSources
  22. compileDebugSources
  23. compileDebugUnitTestSources
  24. compileReleaseSources
  25. compileReleaseUnitTestSources
  26. mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.
  27. Build Setup tasks
  28. -----------------
  29. init - Initializes a new Gradle build.
  30. Help tasks
  31. ----------
  32. buildEnvironment - Displays all buildscript dependencies declared in root project 'project'.
  33. components - Displays the components produced by root project 'project'. [incubating]
  34. dependencies - Displays all dependencies declared in root project 'project'.
  35. dependencyInsight - Displays the insight into a specific dependency in root project 'project'.
  36. dependentComponents - Displays the dependent components of components in root project 'project'. [incubating]
  37. help - Displays a help message.
  38. model - Displays the configuration model of root project 'project'. [incubating]
  39. projects - Displays the sub-projects of root project 'project'.
  40. properties - Displays the properties of root project 'project'.
  41. tasks - Displays the tasks runnable from root project 'project' (some of the displayed tasks may belong to subprojects).
  42. Install tasks
  43. -------------
  44. installDebug - Installs the Debug build.
  45. installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
  46. uninstallAll - Uninstall all applications.
  47. uninstallDebug - Uninstalls the Debug build.
  48. uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
  49. uninstallRelease - Uninstalls the Release build.
  50. Verification tasks
  51. ------------------
  52. check - Runs all checks.
  53. connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
  54. connectedCheck - Runs all device checks on currently connected devices.
  55. connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
  56. deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
  57. deviceCheck - Runs all device checks using Device Providers and Test Servers.
  58. lint - Runs lint on all variants.
  59. lintDebug - Runs lint on the Debug build.
  60. lintRelease - Runs lint on the Release build.
  61. lintVitalRelease - Runs lint on just the fatal issues in the release build.
  62. test - Run unit tests for all variants.
  63. testDebugUnitTest - Run unit tests for the debug build.
  64. testReleaseUnitTest - Run unit tests for the release build.
  65. To see all tasks and more detail, run gradlew tasks --all
  66. To see more detail about a task, run gradlew help --task <task>
x
 
1
> Task :tasks
2
 
          
3
------------------------------------------------------------
4
All tasks runnable from root project
5
------------------------------------------------------------
6
 
          
7
Android tasks
8
-------------
9
androidDependencies - Displays the Android dependencies of the project.
10
signingReport - Displays the signing info for each variant.
11
sourceSets - Prints out all the source sets defined in this project.
12
 
          
13
Build tasks
14
-----------
15
assemble - Assembles all variants of all applications and secondary packages.
16
assembleAndroidTest - Assembles all the Test applications.
17
assembleDebug - Assembles all Debug builds.
18
assembleRelease - Assembles all Release builds.
19
build - Assembles and tests this project.
20
buildDependents - Assembles and tests this project and all projects that depend on it.
21
buildNeeded - Assembles and tests this project and all projects it depends on.
22
clean - Deletes the build directory.
23
cleanBuildCache - Deletes the build cache directory.
24
compileDebugAndroidTestSources
25
compileDebugSources
26
compileDebugUnitTestSources
27
compileReleaseSources
28
compileReleaseUnitTestSources
29
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.
30
 
          
31
Build Setup tasks
32
-----------------
33
init - Initializes a new Gradle build.
34
 
          
35
Help tasks
36
----------
37
buildEnvironment - Displays all buildscript dependencies declared in root project 'project'.
38
components - Displays the components produced by root project 'project'. [incubating]
39
dependencies - Displays all dependencies declared in root project 'project'.
40
dependencyInsight - Displays the insight into a specific dependency in root project 'project'.
41
dependentComponents - Displays the dependent components of components in root project 'project'. [incubating]
42
help - Displays a help message.
43
model - Displays the configuration model of root project 'project'. [incubating]
44
projects - Displays the sub-projects of root project 'project'.
45
properties - Displays the properties of root project 'project'.
46
tasks - Displays the tasks runnable from root project 'project' (some of the displayed tasks may belong to subprojects).
47
 
          
48
Install tasks
49
-------------
50
installDebug - Installs the Debug build.
51
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
52
uninstallAll - Uninstall all applications.
53
uninstallDebug - Uninstalls the Debug build.
54
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
55
uninstallRelease - Uninstalls the Release build.
56
 
          
57
Verification tasks
58
------------------
59
check - Runs all checks.
60
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
61
connectedCheck - Runs all device checks on currently connected devices.
62
connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
63
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
64
deviceCheck - Runs all device checks using Device Providers and Test Servers.
65
lint - Runs lint on all variants.
66
lintDebug - Runs lint on the Debug build.
67
lintRelease - Runs lint on the Release build.
68
lintVitalRelease - Runs lint on just the fatal issues in the release build.
69
test - Run unit tests for all variants.
70
testDebugUnitTest - Run unit tests for the debug build.
71
testReleaseUnitTest - Run unit tests for the release build.
72
 
          
73
To see all tasks and more detail, run gradlew tasks --all
74
 
          
75
To see more detail about a task, run gradlew help --task <task>


注意:在Microsoft Windows上,您需要运行gradlew.bat,在Linux和Mac OS X上,完整的命令是./gradlew。为了简洁起见,我们在整本书中只是写作gradlew 。


要在开发过程中构建项目,请使用调试配置运行组合的task(白注:第一次使用此命令也会下载一些东西):

gradlew assembleDebug
 
1
gradlew assembleDebug

此task将使用该应用程序的调试版本创建一个APK(白注:这和在Gradle面板中双击 build/assembleDebug 的效果一致)。默认情况下,Gradle的Android插件将APK保存在 MyApp/app/build/outputs/apk 目录中。


注意:使用缩写的task名称是为了避免在终端中输入大量的内容,Gradle还提供骆驼风格缩写task名称作为快捷键。例如,可以通过从命令行界面运行gradlew assDeb来执行assembleDebug,甚至可以是aD。但这里有一个警告,仅仅当骆驼风格的缩写是唯一的情况下它才会起作用。一旦另一个任务具有相同的缩写,这个技巧就不再适用于这些task。


除了assemble外,还有另外三个基本的任务:

  • check:运行所有检查,这通常意味着在连接的设备或模拟器上运行测试
  • build:触发assemble和check命令
  • clean:清理项目的输出

我们将在第2章基本构建定制中详细讨论这些任务。


总结

【Summary】
We started the chapter by looking at the advantages of Gradle and why it is more useful than other build systems currently in use. We briefly looked at Android Studio and how it can help us by generating build files. 

After the introduction, we took a look at the Gradle Wrapper, which makes maintenance and sharing projects a lot easier. We created a new project in Android Studio, and you now know how to migrate an Eclipse project to Android Studio and Gradle, both automatically and manually. You are also capable of building projects with Gradle in Android Studio, or straight from the command-line interface. 

In the next few chapters, we will look at ways to customize the build, so you can further automate the build process and make maintenance even easier. We will start by examining all the standard Gradle files, exploring basic build tasks, and customizing parts of the build in the next chapter.

我们首先看了看Gradle的优势,以及为什么它比目前使用的其他构建系统更有用。我们简要地介绍了Android Studio以及它是如何通过生成构建文件来帮助我们的。
介绍之后,我们看了一下Gradle Wrapper,这使得维护和共享项目变得更容易。我们在Android Studio中创建了一个新项目,现在您知道如何自动和手动将Eclipse项目迁移到Android Studio和Gradle。您也可以在Android Studio中使用Gradle构建项目,也可以直接从命令行界面进行构建。

在接下来的几章中,我们将研究如何定制构建,以便您可以进一步自动化构建过程,并使维护更加容易。 我们将开始检查所有标准的Gradle文件,探索基本的构建任务,并在下一章中定制构建的部分内容。

PS:第一章翻译部分省略掉了以下内容,因为这些内容都比较基础,且和Gradle没啥关系。
  1. 1.1 Android Studio
  2. 1.1.1 保持最新 Staying up to date
  3. 1.3 创建新项目 Creating a new project
  4. 1.5 迁移出Eclipse Migrating from Eclipse
  5. 1.5.1 使用导入向导 Using the import wizard
  6. 1.5.2 手动迁移 Migrating manually
  7. 保持旧的项目结构 Keeping the old project structure
  8. 转换到新的项目结构 Converting to the new project structure
  9. 迁移库 Migrating libraries
 
1
1.1 Android Studio 
2
    1.1.1 保持最新    Staying up to date
3
1.3 创建新项目    Creating a new project
4
1.5 迁移出Eclipse    Migrating from Eclipse
5
    1.5.1 使用导入向导    Using the import wizard
6
    1.5.2 手动迁移    Migrating manually
7
            保持旧的项目结构    Keeping the old project structure
8
            转换到新的项目结构    Converting to the new project structure
9
            迁移库   Migrating libraries
2017-11-8

转载于:https://www.cnblogs.com/baiqiantao/p/7805272.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/AllinToyou/article/detail/722811
推荐阅读
相关标签
  

闽ICP备14008679号