Android Tools 翻译:Android Plugin for Gradle

以下内容翻译自官方文档

http://developer.android.com/tools/building/plugin-for-gradle.html


Android 构建系统为 Gradle 组成了一个 Android 插件。Gradle 是一个优秀的构建工具组,可以管理项目依赖和自定义构建逻辑。Android Studio 使用 Gradle wrapper 来完整地集成 Gradle 的 Android 插件。Gradle 的 Android 插件同样独立于 Android Studio。这意味着可以构建应用可以使用 Android Studio 或者命令行工具。

Build configuration

项目的构建配置放在 build.gradle 文件里,这些纯文本文件使用 Gradle 和 Android 插件携带的语法和选项来配置构建的各个方面:

  • Build variants。构建系统可以在一个相同的模块,使用不同的渠道和构建配置来创建多种 APK。当需要为应用发布不同的版本时,不需要为不同的版本创建不一样的项目和模块。

  • Dependencies。构建系统自动管理项目依赖,支持本地文件系统和远程仓库。可以避免我们去查找,下载或者复制项目依赖的包。

  • Manifest entries。构建系统在构建变量的配置时,能够修改一些 manifest 文件的元素。这些构建变量会重写 manifest 文件中已经存在的变量。当需要生成多个不同应用名,最小版本的 SDK,目标版本的 SDK等多个 APK 文件时这很有用。当有多个 manifest 文件存在,这些 manifest 的配置会按 buildType 和 productFlavor,/main 的 mainfest,库的 mainfest 的优先级顺序进行合并,

  • Signing。构建系统可以在构建配置中规定签名配置,可以在构建的过程中签名 APK。

  • ProGuard。构建系统可以不同类型的构建定义不同的 ProGuard 策略文件。可以在构建过程中运行 proGuard 来来类文件。

  • Testing。对于大部分模板,构建系统创建测试目录,androidTest 并且从项目中的测试代码生成测试 APK,所以不需要灵台创建测试项目。构建系统同样可以在构建的过程中运行测试。

Gradle 构建文件使用 DSL 语言 Groovy 的语法去描述和处理构建逻辑。Groovy 是动态语言,可以用来自定义构建逻辑,并且和 Gradle 的 Android 插件提供的 Android-specific 元素。

Build by convention

Android 构建系统为项目结构和其他的编译选项假设了一些合理的默认值。如果项目遵循这些约定,Gradle 构建文件会非常简单。当这些约定没有应用到项目中,构建系统的灵活性允许配置构建过程的各个方面。例如,如果需要更换模块目录的默认源码文件夹,可以在模块的构建文件中配置一个新的目录结构。

Projects and modules build settings

Android Studio 的一个项目代表了 Android 开发结构的最顶层。Android Studio 的项目包括项目文件和一个或者多个模块。一个模块是应用中可以用来构建,测试和调试的独立组件。模块包含了应用的源码和资源。Android Studio 项目可以包含这几种类型的模块:

  • Android 应用模块包含应用的代码,可能会依赖库模块,大部分 Android 应用只有一个应用模块。构建系统为应用模块生成 APK 包。
  • Android 库模块包含一些可复用的 Android 特有的代码和资源。构建系统为库模块生成 AAR 包。
  • App Engine 模块包含了为整合 App Engine 的代码和资源。
  • Java 库模块包含一些可复用代码。构建系统为这些 Java 库生成 JAR 包。

Android Studio 项目包含一个顶层的 Gradle 构建文件,可以用来为项目中的所有模块添加配置通用选项。每一个应用模块也有它们自己的 build.gradle 文件用来为模块进行特有的配置。

Project Build File

默认情况下,项目层次的 Gradle 文件使用 buildscript 去定义 Gradle 仓库和依赖。允许不同的项目使用不同的 Gradle 版本。支持 JCenter,Maven Central 或者 Ivy 仓库。下面这个例子声明了一个构建脚本,的使用 JCenter 仓库和一个包含 Gradle 1.0.1版本的 Android 插件的类路径。

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.0.1'

        // NOTE: Do not place your application dependencies here: they belong
        // in the individual module build.gradle files
    }
}

allprojects {
   repositories {
       jcenter()
   }
}

注意:这个 Android Studio 项目的 SDK 路径在 local.properties 文件中的 sdk.dir 配置中定义,或者使用了 ANDROID_HOME 环境变量。

Module Build File

应用模块的 Gradle 配置文件允许去配置模块的构建设置,包括重写 src/main 的 manifest 设置和设置打包选项。

  • android settings
    • compileSdkVersion
    • buildToolsVersion
  • defaultConfig and productFlavors

    • manifest 属性比如 applicationId,minSdkVersion,targetSdkVersion 和测试信息
  • buildTypes

    • 构建属性比如 debuggable,Proguard enabling,debug signing,version name and test information
  • dependencies

下面的例子应用了 Android 插件,使用默认的配置并且重写了一些 manifest 属性,创造两种构建类型:release 和 debug,并且声明了一些依赖关系。

apply plugin: 'com.android.application'

android {
    compileSdkVersion 20
    buildToolsVersion "20.0.0"

    defaultConfig {
        applicationId "com.mycompany.myapplication"
        minSdkVersion 13
        targetSdkVersion 20
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
         在它的        }
         debug {
            debuggable true
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:20.0.0'
    compile project(path: ':app2, configuration: 'android-endpoints')
}
```	

> 注意:可以为一些属性值注入构建逻辑,由函数方法来定义,然后由属性来调用,例如:


def computeVersionName() { … }

android { defaultConfig { versionName computeVersionName() … } } ```

Dependencies

Android Studio 的构建系统管理了项目的依赖,并且支持模块依赖,本地依赖和远程依赖。

Module Dependencies
一个应用模块可以在构建文件中包含它依赖的模块列表。当我们构建这些模块,构建系统和组合和包含这些需要的模块。

Local Dependencies
如果在本地文件系统中又二进制文档被模块依赖到,比如 JAR 文档,可以在构建文件中声明这些模块的依赖。

Remote Dependencies
如果一些依赖在远程仓库中,并不需要下载和拷贝它们。Android Studio 的构建系统支持远程仓库的依赖,比如 Maven,还有如 Ivy 的依赖管理者。

大部分软件库和工具可以在 Maven 仓库中找到。对于这些依赖,只需要去确定它们的 Maven 坐标,这些位置在远程仓库中的每一个元素都给了独自的定义。Maven 仓库的坐标格式为 group:name:version 。比如,使用版本 16.0.1 的 Google Guava 库的坐标为 com.google.guava:guava:16.0.1。

Maven Central Repository 被广泛地使用到库和工具的发布。

Build tasks

Android Studio 的构建系统定义了构建任务集合的层级结构:顶层或者锚任务启动依赖的任务去生产它们可收集的构建结果。顶层构建任务有:

assemble
构建项目输出

check
运行检查和测试

build
运行上面两任务

clean
执行清理操作

Android 插件提供了 connectCheck 和 deviceCheck 任务去检查连接、模拟和远程设备。

可以从 Android Studio 或者命令行中看到这些任务或者调用这些任务。

The Gradle wrapper

Android Studio 项目包含了 Gradle wrapper,由这些组成: - 一个 JAR 文件 - 一个属性文件 - 一个为 Windows 平台使用的 shell 脚本 - 一个为 Mac 和 Linux 平台使用的 shell 脚本

注意:需要提交所有的这些文件到代码控制系统中

使用 Gradle wrapper(而不是本地安装的 Gradle) 确保始终运行着在 local.properties 中定义好的 Gradle 版本。为项目配置更新的 Gradle 版本,可以编辑属性文件并且规定最新的版本。

Android Studio 从 Gradle wrapper 目录中读取属性文件到项目中,然后运行 wrapper。构建的变体由 build types 和 product flavors 组成。Product flavors 用来产生应用的版本,比如免费的还是付费的。Build types 表示每个应用包构建的包版本,比如 debug 和 release。构建系统为每个 product flavor 和 build type 生成 APK 文件。

添加两种 product flavors,带有默认 build types 的 demo 和 full 生成四种构建类型,每种都有属于它们的配置。

  • demoDebug

  • demoRelease

  • fullDebug

  • fullRelease

资源和 Android 应用源码合并:

  • 构建变体基于 buildType,和 productFlavor 构建设置

  • 主要的 sourceSet,通常位于 src/main/res

  • 库项目依赖,如果有资源,通常通过 aar 打包没进行访问

这些资源合并的顺序从低到高为 libraries/dependencies -> main src -> productFlavor -> buildType。

一些项目因为有只一种尺度,可以组合更多复杂的特性,但它们表现上还是同一个应用。例如,为了生成一个应用的 demo 或 full 版本,一些方案会针对特有的 CPU/ABI 包含一些特有的二进制代码。构建系统可以灵活地为每一个项目产生以下的构建变体:

  • x86-demoDebug

  • x86-demoRelease

  • x86-fullDebug

  • x86-fullRelease

  • arm-demoDebug

  • arm-demoRelease

  • arm-fullDebug

  • arm-fullRelease

  • mips-demoDebug

  • mips-demoRelease

  • mips-fullDebug

  • mips-fullRelease

这些项目会有两种构建类型(debug 和 release)和两种 product flavor,一种为应用类型(demo 或 full)和一种为 CPU/ABI(x86,ARM 或 MIPS)。

Source directories

为了构建每个应用的版本,构建系统从这些地方组合了源代码和资源:

  • src/main - 主要的源码目录

  • src/<buildType>/

  • src/<productFlavor>

注意:build type 和 product flavor 的目录是可选的,Android Studio 不会创建这些目录。如果在配置文件里添加了 build types 和 product flavors 可以创建这些目录。构建系统在这些目录没有被说明的情况下不会使用它们。

对于项目来说不需要定义任何的 flavors,构建系统使用 defaultConfig 设置,主要的应用目录和默认的 build tye 目录。例如,要生成默认的 debug 和 release 构建变体,没有指明 product flavors,构架系统会使用:

  • src/main/(default configuration)

  • src/release/(build type)

  • src/debug(build type)

如果项目定义了一些 product flavors,构建系统会合并 build type,product flavor 和 main source 目录。例如,为了生成 full-debug 的构建变体,构建系统合并了 build type,product flavor 和 main 目录:

  • src/main/(default configuration)

  • src/debug/(build type)

  • src/full/(flavor)

对于使用了 flavor dimensions,构建系统为每一个 dimension 合并一个 flavor。例如,生成 arm-demo-release 构建变体,构建系统合并了:

  • src/main/ (default configuration)

  • src/release/ (build type)

  • src/demo/ (flavor - app type dimension)

  • src/arm/ (flavor - ABI dimension)

这些目录的源码一起被使用到构建变体中。可以在不同目录有相同的命名只要没有在同一个变体中一起使用这些类。

构建系统同样合并了所有的 manifest 成单个 manifest,所以在最终的 manifest 中,构建变体可以定义不同的组件和访问权限。manifest 按这些从低到高的顺序合并 manifest libraries/dependencies -> main src -> productFlavor -> buildType。

构建系统从所有的源码目录合并了所有的资源。在一个构建变体中,如果不同的目录包含了资源有相同的命名,优先级顺序是:build type 资源覆盖 product flavor,覆盖 main source,覆盖其他库项目的资源。

注意:构建变体允许我们去复用应用其他版本的通用的 activites, 应用逻辑,资源。