Gradle for Android 翻譯 -1

英文版電子書下載

參考： Gradle for Android  

1、從 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的構建文件有幾個必需的元素：

buildscript {
   repositories {
        jcenter()    //存儲庫
   }
   dependencies {
       classpath 'com.android.tools.build:gradle:1.2.3'
 } 
}

 

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代碼塊由插件定義，能夠爲每一個項目配置：

android {
       compileSdkVersion 22
       buildToolsVersion "22.0.1"
}

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指望的簡單應用程序的文件夾結構：

MyApp
  ├── build.gradle
  ├── settings.gradle
  └── app
      ├── build.gradle
      ├── build    //The output of the build process
      ├── libs    //These are external libraries (.jar or .aar)
      └── src
          └── main
              ├── java    //The source code for the app
              │   └── com.package.myapp
              └── res    //These are app-related resources (drawables, layouts, strings, and so on)
                  ├── drawable
                  ├── layout
                  └── 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智能手錶應用程序的項目，則默認狀況下這些模塊被稱爲 application和 wearable。

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的版本以及有關您設置的一些額外信息。

PS：若是 gradle-wrapper.properties 中的 distributionUrl 指定的不是本地路徑的 Gradle，而是網絡路徑，那麼執行此命令後，無論本地是否是已經下載過此版本的Gradle，都會從新下載，且時間會很是長。

若是你正在轉換一個Eclipse項目，默認狀況下，wrapper將不會出現。 在這種狀況下，可使用Gradle生成它，可是您須要首先安裝Gradle來獲取wrapper。

在您下載並安裝Gradle並將其添加到PATH後，建立一個包含如下三行的 build.gradle 文件（白注：在根目錄下的 build.gradle 文件中添加如下代碼便可）：

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

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生成的全部文件：

myapp/
├── gradlew    //針對Linux和Mac系統的shell腳本文件， A shell script on Linux and Mac OS X
├── gradlew.bat    //針對windows系統的bat文件，A batch file on Microsoft Windows
└── gradle/wrapper/
    ├── gradle-wrapper.jar    //A JAR file that is used by the batch file and shell script
    └── 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的文件：

#Sat May 30 17:41:49 CEST 2015
   distributionBase=GRADLE_USER_HOME
   distributionPath=wrapper/dists
   zipStoreBase=GRADLE_USER_HOME
   zipStorePath=wrapper/dists
   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面板中的一致。

> Task :tasks

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.

Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
clean - Deletes the build directory.
cleanBuildCache - Deletes the build cache directory.
compileDebugAndroidTestSources
compileDebugSources
compileDebugUnitTestSources
compileReleaseSources
compileReleaseUnitTestSources
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.

Build Setup tasks
-----------------
init - Initializes a new Gradle build.

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'project'.
components - Displays the components produced by root project 'project'. [incubating]
dependencies - Displays all dependencies declared in root project 'project'.
dependencyInsight - Displays the insight into a specific dependency in root project 'project'.
dependentComponents - Displays the dependent components of components in root project 'project'. [incubating]
help - Displays a help message.
model - Displays the configuration model of root project 'project'. [incubating]
projects - Displays the sub-projects of root project 'project'.
properties - Displays the properties of root project 'project'.
tasks - Displays the tasks runnable from root project 'project' (some of the displayed tasks may belong to subprojects).

Install tasks
-------------
installDebug - Installs the Debug build.
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
uninstallAll - Uninstall all applications.
uninstallDebug - Uninstalls the Debug build.
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
uninstallRelease - Uninstalls the Release build.

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
lintVitalRelease - Runs lint on just the fatal issues in the release build.
test - Run unit tests for all variants.
testDebugUnitTest - Run unit tests for the debug build.
testReleaseUnitTest - Run unit tests for the release build.

To see all tasks and more detail, run gradlew tasks --all

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 Android Studio 
    1.1.1 保持最新    Staying up to date
1.3 建立新項目    Creating a new project
1.5 遷移出Eclipse    Migrating from Eclipse
    1.5.1 使用導入嚮導    Using the import wizard
    1.5.2 手動遷移    Migrating manually
            保持舊的項目結構    Keeping the old project structure
            轉換到新的項目結構    Converting to the new project structure
            遷移庫   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