4、Dependencies。Android Libraries and Multi-project setup（依赖关系，Android库和多项目设置）
Gradle项目能够依赖于其他组件。这些组件能够是外部二进制包，或者是其他的Gradle项目。
4.1 Dependencies on binary packages（依赖二进制包）
4.1.1 Local packages（本地包）
配置一个外部库的jar包依赖。你须要在compile配置中加入一个依赖。
dependencies {
compile files('libs/foo.jar')
}
android {
...
}注意：这个dependencies DSL标签是标准Gradle API中的一部分。所以它不属于android标签。
这个compile配置将被用于编译main application。它里面的全部东西都被会被加入到编译的classpath中，同一时候也会被打包进终于的APK。
下面是加入依赖时可能用到的其他一些配置选项：
* compile：main application（主module）。
* androidTestCompile：test application（測试module）。
* debugCompile：debug Build Type（debug类型的编译）。
* releaseCompile：release Build Type（公布类型的编译）。
由于没有可能去构建一个没有关联不论什么Build Type（构建类型）的APK，APK默认配置了两个或两个以上的编译配置：compile和<buildtype>Compile.
创建一个新的Build Type将会自己主动创建一个基于它名字的新配置。
这对于debug版本号须要使用一个自己定义库（为了反馈实例化的崩溃信息等）但公布版本号不须要。或者它们依赖于同一个库的不同版本号时会很实用。
4.2.2 Remote artifacts（远程文件）
Gradle支持从Maven或者Ivy仓库中拉取文件。
首先必须将仓库加入到列表中，然后必须在依赖中声明Maven或者Ivy声明的文件。
repositories {
mavenCentral()
}
dependencies {
compile 'com.google.guava:guava:11.0.2'
}
android {
...
}
注意：mavenCentral()是指定仓库URL的简单方法。Gradle支持远程和本地仓库。
注意：Gradle会遵循依赖关系的传递性。这意味着假设一个依赖本身依赖于其他东西，这些东西也会一并被拉取回来。
很多其它关于设置依赖关系的信息，请參考Gradle用户指南和DSL文档。
4.2 Multi project setup（多项目设置）
Gradle项目也能够通过使用多项目配置依赖于其他Gradle项目。
多项目配置的实现一般是在一个根项目路径下将全部项目作为子目录包括进去。
比如，给定下面项目结构：
MyProject/
+ app/
+ libraries/
+ lib1/
+ lib2/
我们能够定义3个项目。
Grand将会依照下面名字映射它们：
:app
:libraries:lib1
:libraries:lib2
每个项目都拥有自己的build.gradle文件来声明自己怎样构建。
另外，在根文件夹下另一个setting.gradle文件用于声明全部项目。
这些文件的结构例如以下：
MyProject/
| settings.gradle
+ app/
| build.gradle
+ libraries/
+ lib1/
| build.gradle
+ lib2/
| build.gradle
当中setting.gradle的内容很easy：
include ':app', ':libraries:lib1', ':libraries:lib2'
这里定义了哪一个目录才是真正的Gradle项目。
当中:app项目可能依赖于这些库，这是通过下面依赖配置声明的：
dependencies {
compile project(':libraries:lib1')
}
很多其它关于多项目配置的信息请參考这里。
4.3 Library projects（库项目）
在上面的多项目配置中。:libraries:lib1和:libraries:lib2可能是一个Java项目，而且:app这个Android项目将会使用它们的jar包输出。
可是。假设你想要共享代码来訪问Android API或者使用Android样式的资源，那么这些库就不能是通常的Java项目，而应该是Android库项目。
4.3.1 Creating a Library Project（创建一个库项目）
一个库项目与通常的Android项目很类似，仅仅是有一点小差别。
虽然构建库项目不同于构建应用程序，它们使用了不同的plugin。可是在内部这些plugin共享了大部分同样的代码。而且它们都由同样的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编译SourceSet的库项目，而且依赖关系的配置方法与应用程序项目的配置方法一样，相同也支持自己定义配置。
4.3.2 Differences between a Project and a Library Project（普通项目和库项目之间的差别）
一个库项目的main输出是一个.aar包（它代表Android的归档文件）。它组合了编译代码（比如jar包或者是本地的.so文件）和资源（manifest。res。assets）。
一个库项目相同也能够独立于应用程序生成一个測试用的apk来測试。
标识Task相同适用于库项目（assembleDebug，assembleRelease），因此在命令行上与构建一个项目没有什么不同。
其余的部分，库项目与应用程序项目一样。它们都拥有build type和product flavor，也能够生成多个aar版本号。
记住大部分Build Type的配置不适用于库项目。可是你能够依据库项目是否被其他项目使用或者是否用来測试来使用自己定义的sourceSet改变库项目的内容。
4.3.3 Referencing a Library（引用一个库项目）
引用一个库项目的方法与引用其他项目的方法一样：
dependencies {
compile project(':libraries:lib1')
compile project(':libraries:lib2')
}注意：假设你要引用多个库，那么排序将很重要。这类似于旧构建系统里面的project.properties文件里的依赖排序。
4.3.4 Library Publication（库项目公布）
普通情况下一个库仅仅会公布它的release Variant（变种）版本号。
这个版本号将会被全部引用它的项目使用，而无论它们本身自己构建了什么版本号。这是因为Gradle的限制，我们正在努力消除这个问题，所以这仅仅是暂时的限制。
你能够控制哪一个Variant版本号作为发行版：
android {
defaultPublishConfig "debug"
}
注意这里的公布配置名称引用的是完整的Variant版本号名称.Relesae，debug仅仅适用于项目中没有其他特性版本号的时候使用。假设你想要使用其他Variant版本号代替默认的公布版本号，你能够：
android {
defaultPublishConfig "flavor1Debug"
}
将库项目的全部Variant版本号都公布也是可能的。我们计划在一般的项目依赖项目（类似于上述所说的）情况下同意这样的做法，可是因为Gradle的限制（我们也在努力修复这个问题）如今还不太可能。
默认情况下没有启用公布全部Variant版本号。能够通过下面启用：
android {
publishNonDefault true
}
理解公布多个Variant版本号意味着公布多个arr文件而不是一个arr文件包括全部Variant版本号是很重要的。每个arr包都包括一个单一的Variant版本号。
公布一个变种版本号意味着构建一个可用的arr文件作为Gradle项目的输出文件。
不管是公布到一个maven仓库，还是其他项目须要创建一个这个库项目的依赖都能够使用到这个文件。
Gradle有一个默认文件的概念。当加入下面配置后就会被使用到：
compile project(':libraries:lib2')
创建一个其他公布文件的依赖，你须要指定详细使用哪一个：
dependencies {
flavor1Compile project(path: ':lib1', configuration: 'flavor1Release')
flavor2Compile project(path: ':lib1', configuration: 'flavor2Release')
}
重要：注意已公布的配置是一个完整的Variant版本号。当中包含了build type，而且须要像以上一样被引用。
重要：当启用非默认公布，maven公布插件将会公布其他Variant版本号作为扩展包（按分类器分类）。这意味着不能真正的兼容公布到maven仓库。
你应该另外公布一个单一的Variant版本号到仓库中，或者同意公布全部配置以支持跨项目依赖。