最近赶项目,白天基本没时间,只有晚上在家的时候才能看一看。昨天晚上只翻译完了第四章,今天就只发第四章吧。
本文译自Android官方技术文档《Gradle Plugin User Guide》,原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide。
翻译不易,转载请注明CSDN博客上的出处:
http://blog.csdn.net/maosidiaoxian/article/details/41955809
前三章见《Android官方技术文档翻译——Gradle 插件用户指南(1-3)》。
翻译工作耗时费神,如果你觉得本文翻译得还OK,请点一下“顶”,我在精神上会倍受鼓励的,谢谢。翻译如有错讹,敬请指正。
依赖、 Android Library和多项目设置
Gradle 项目可以对其他组件具有依赖关系。这些组件可以是外部的二进制包,或其他的 Gradle 项目。
二进制包的依赖
本地包
要配置一个外部库 jar 包的依赖,您需要在compile配置中添加一个依赖关系。
dependencies {compile files('libs/foo.jar')}android {...}
注意:dependencies DSL 元素是标准的 Gradle API 的一部分,不属于android 元素内。
compile配置用于编译主应用程序。里面的所有内容都会被添加到编译类路径,并且打包到最终生成的 apk 当中。
下面是添加依赖时其他可能用到的配置:
- compile: 主应用程序
- androidTestCompile: 测试的应用程序
- debugCompile: debug Build Type
- releaseCompile: release Build Type.
创建一个新的Build Type会基于它的名字自动创建一个新的配置。
这可能会有用,比如debug版本需要使用一个自定义库(例如报告崩溃的信息),而release版本则不需要,或者是他们依赖于同一个库的不同版本的情况下。
远程文件
Gradle 支持从 Maven 和 Ivy 仓库中拉取文件。
首先,这个仓库必须添加到列表当中,然后必须用Maven 或 Ivy 声明文件的方式声明这个依赖。
首先,这个仓库必须添加到列表当中,然后必须用Maven 或 Ivy 声明文件的方式声明这个依赖。
repositories {mavenCentral()}dependencies {compile 'com.google.guava:guava:11.0.2'}android {...}
注: mavenCentral()是指定maven中央仓库的URL的快捷方法。Gradle支持远程和本地仓库。
注:Gradle 将遵循所有依赖关系的传递性。这意味着,如果一个依赖有它自己的依赖关系,这些依赖也会被拉取。
有关设置依赖关系的更多信息,请参阅 Gradle 用户指南(这里),和DSL文档(这里)。
多项目设置
Gradle 项目也可以通过使用多项目设置依赖于其他的 Gradle 项目。
一个多项目设置通常是通过让所有的项目作为给定根项目的子文件夹来实现。
例如,给定以下项目结构:
一个多项目设置通常是通过让所有的项目作为给定根项目的子文件夹来实现。
例如,给定以下项目结构:
MyProject/+ app/+ libraries/+ lib1/+ lib2/
我们可以识别出3个项目。Gradle 将通过以下名称引用它们:
:app:libraries:lib1:libraries:lib2
每一个项目都有其自己的build.gradle文件,定义自己如何构建。
此外,在根路径下还将有一个叫settings.gradle的文件用于声明所有的项目。
这些文件的结构如下:
MyProject/| settings.gradle+ app/| build.gradle+ libraries/+ lib1/| build.gradle+ lib2/| build.gradle
settings.gradle的内容很简单:
include ':app', ':libraries:lib1', ':libraries:lib2'
它定义了哪个文件夹实际上是一个 Gradle 项目。
该:app项目可能依赖于libraries,这是通过声明如下的依赖关系来配置的:
dependencies {compile project(':libraries:lib1')}
关于多项目设置的更多常用信息请参阅这里。
库项目
在上面的多项目的设置中,:libraries:lib1和:libraries:lib2可以是Java项目,而:app Android项目将会使用到它们的jar包输出。
但是,如果你想共享访问了 Andr??oid API或使用了 Android-style的资源的代码,这些库项目就不能是普通的Java项目,而应该是 Andr??oid Library 项目。
创建库项目
Library项目与普通的 Android 项目非常相似,只有一些不同。
由于构建库项目与构建应用程序有些不同不同,所以使用的是不同的插件。这两个插件内部共享了大部分的相同的代码,并且它们都由同样的com.android.tools.build.gradle jar 包提供。
由于构建库项目与构建应用程序有些不同不同,所以使用的是不同的插件。这两个插件内部共享了大部分的相同的代码,并且它们都由同样的com.android.tools.build.gradle jar 包提供。
buildscript {repositories {mavenCentral()}dependencies {classpath 'com.android.tools.build:gradle:0.5.6'}}apply plugin: 'android-library'android {compileSdkVersion 15}
上面的例子中创建了一个使用API?? 15编译的库项目。SourceSets和依赖关系与它们在应用程序项目中的处理方式一样,并且支持同样方式的自定义。
普通项目和Library 项目之间的区别
一个 Library 项目主要输出的是一个.aar包(它代表Android的归档文件)。它组合了编译代码(如一个jar文件或原生的.so文件)和资源(manifest,res,assets)。
一个库项目还可以生成测试apk,独立于应用程序测试这个库。
库项目用着同样的锚任务(assembleDebug, assembleRelease),所以构建这样一个项目的命令也没有任何区别。
对于其他的内容,库项目和应用程序项目的行为是一样的。。他们都有构建类型(build types)和产品定制(product flavors),并且都可以生成多个版本的aar。
需要注意的是,Build Type的大部分配置都不适用库项目。但是,您可以根据一个库项目是否被其他项目使用还是被测试,使用自定义 sourceSet 来更改库项目的内容。
引用一个库项目
引用一个库库和引用其他任何项目的方法是一样的:
dependencies {compile project(':libraries:lib1')compile project(':libraries:lib2')}
注意: 如果您有多个库,那么排序将非常重要。这类似于旧的生成系统中, project.properties 文件的依赖项的顺序的重要性。
库项目发布
默认情况下,一个库项目只发布它的release variant。这variant将被所有引用该库的项目使用,无论那些项目构建的是哪种variant。这是由于 Gradle 限制而有的一个临时限制,我们正在努力消除这个问题。
您可以控制要发布哪一个variant
android {defaultPublishConfig "debug"}
注意,这个发布的配置名称引用的是完整的 variant 名称。release和debug,只在没有定义flavor时适用。如果你想在使用flavors时更改默认的发布variant,你可以这样写:
android {defaultPublishConfig "flavor1Debug"}
默认情况下没有启用发布所有variant。要启用它们可以这样做:
android {publishNonDefault true}
发布多个variants意味着发布多个aar文件,而不是发布一个包含多个variants的aar文件,能意识到这一点是非常重要的。每一个 aar 包都是包含一个单一的variant。
发布一个variant,意识着让这个可用的 aar 作为 Gradle 项目的输出文件。这个文件将会在发布到一个maven仓库中,或者另一个项目创建对这个项目依赖时用到。
Gradle 有一个默认文件的概念。它就是在编写下面的代码时用到的:
compile project(':libraries:lib2')
若要创建对一个项目的另一个已发布的文件的依赖,您需要指定使用哪一个:
dependencies {flavor1Compile project(path: ':lib1', configuration: 'flavor1Release')flavor2Compile project(path: ':lib1', configuration: 'flavor2Release')}
重要说明:当启用非默认的发布时,Maven 发布插件将把这些额外的variant作为额外的包(按分类器分类)发布。这意味着它对发布到一个 maven 仓库并不是真正的兼容。您应该只向一个仓库发布一个单一的 variant,或者是,为项目之间的依赖启用所有的发布配置。