Manifest属性
通过SDL可以配置一下manifest选项：
- minSdkVersion
- targetSdkVersion
- versionName
- applicationId (有效的包名 -- 更多详情请查阅ApplicationId 对比 PackageName)
- package Name for the test application
- Instrumentation test runner
在android元素中的defaultConfig元素中定义所有配置。
在构建文件中定义的强大之处在于它是动态的。 例如，可以从一个文件中或者其它自定义的逻辑代码中读取版本信息：
def computeVersionName() {
...
}
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
versionCode 12
versionName computeVersionName()
minSdkVersion 16
targetSdkVersion 16
}
}
注意：不要使用与在给定范围内的getter方法可能引起冲突的方法名。例如，在defaultConfig{...}中调用getVersionName()将会自动调用defaultConfig.getVersionName()方法，你自定义的getVersionName()方法就被取代掉了。
Build Types构建类型
默认情况下，Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试，以及APK如何签名。
Debug版本可采用默认签名。Release版本在构建过程中没有签名，需要稍后再签名。
这些配置通过一个BuildType对象来配置。默认情况下，这两个实例都会被创建，分别是一个debug版本和一个release版本。
Android plugin允许像创建其他构建类型一样定制debug和release实例。这需要在buildTypes的DSL容器中配置：
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jnidebugBuild true
}
}
}
以上代码片段实现了以下功能：
- 配置默认的debug构建类型
- 将debug版本的包名设置为.debug以便能够同时在一台设备上安装debug和release版本的apk。
- 创建了一个名为jnidebug的新构建类型，并且这个构建类型是debug构建类型的一个副本。
- 继续配置jnidebug构建类型，允许使用JNI组件，并且也添加了不一样的包名后缀。
创建一个新的构建类型就是简单的在buildType标签下添加一个新的元素，并且可以使用initWith()或者直接使用闭包来配置它。
签名配置
对一个应用程序签名需要以下：
- 一个Keystory
- 一个keystory密码
- 一个key的别名
- 一个key的密码
- 存储类型
位置，键名，两个密码，还有存储类型一起形成了签名配置。
默认情况下，debug被配置成使用一个debug keystory。 debug keystory使用了默认的密码和默认key及默认的key密码。 debug keystory的位置在$HOME/.android/debug.keystroe，如果对应位置不存在这个文件将会自动创建一个。
可以创建其他配置或者自定义内建的默认配置。通过signingConfigs这个DSL容器来配置：
android {
signingConfigs {
debug {
storeFile file("debug.keystore")
}
myConfig {
storeFile file("other.keystore")
storePassword "android"
keyAlias "androiddebugkey"
keyPassword "android"
}
}
buildTypes {
foo {
debuggable true
jniDebugBuild true
signingConfig signingConfigs.myConfig
}
}
}
以上代码片段修改debug keystory的路径到项目的根目录下。在这个例子中，这将自动影响其他使用到debug构建类型的构建类型。
这里也创建了一个新的Single Config（签名配置）和一个使用这个新签名配置的新的Build Type（构建类型）。
注意：只有默认路径下的debug keystory不存在时会被自动创建。更改debug keystory的路径并不会自动在新路径下创建debug keystory。如果创建一个新的不同名字的SignConfig，但是使用默认的debug keystore路径来创建一个非默认的名字的SigningConing，那么还是会在默认路径下创建debug keystory。换句话说，会不会自动创建是根据keystory的路径来判断，而不是配置的名称。
依赖关系
Gradle项目可以依赖于其它组件。这些组件可以是外部二进制包，或者是其它的Gradle项目。
1. 本地二进制包依赖
可以在compile配置中，添加对本地jar包或aar包的依赖
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（发布类型的编译）。
APK默认配置了两个或两个以上的编译配置：compile和< buildtype >Compile. 创建一个新的Build Type将会自动创建一个基于它名字的新配置。
2. 远程二进制包依赖
Gradle支持从Maven或者Ivy仓库中拉取文件。首先必须将仓库添加到列表中，然后必须在依赖中声明Maven或者Ivy声明的文件。
repositories {
//maven仓库
mavenCentral()
}
dependencies {
//maven文件
compile 'com.google.guava:guava:11.0.2'
}
android {
...
}
注意：mavenCentral()是指定仓库URL的简单方法。Gradle支持远程和本地仓库。
3. 多项目设置
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的内容非常简单，这里定义了哪一个文件夹才是真正的Gradle项目。
include ':app', ':libraries:lib1', ':libraries:lib2'
其中:app项目可能依赖于这些库，这是通过以下依赖配置声明的：
dependencies {
compile project(':libraries:lib1')
}