Manifest entries (Manifest属性)
通过SDL可以配置一下manifest选项:
- minSdkVersion
- targetSdkVersion
- versionName
- applicationId (有效的包名 -- 更多详情请查阅ApplicationId 对比 PackageName)
- package Name for the test application
- Instrumentation test runner
例如:
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
versionCode 12
versionName "2.0"
minSdkVersion 16
targetSdkVersion 16
}
}
在android
元素中的defaultConfig
元素中定义所有配置。
之前的Android Plugin版本使用packageName来配置manifest文件中的packageName属性。从0.11.0版本开始,你需要在build.gradle文件中使用applicationId来配置manifest文件中的packageName属性。 这是为了消除应用程序的packageName(也是程序的ID)和java包名所引起的混乱。
在构建文件中定义的强大之处在于它是动态的。 例如,可以从一个文件中或者其它自定义的逻辑代码中读取版本信息:
def computeVersionName() {
...
}
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
versionCode 12
versionName computeVersionName()
minSdkVersion 16
targetSdkVersion 16
}
}
注意:不要使用与在给定范围内的getter方法可能引起冲突的方法名。例如,在defaultConfig{...}中调用getVersionName()将会自动调用defaultConfig.getVersionName()方法,你自定义的getVersionName()方法就被取代掉了。
如果一个属性没有使用DSL进行设置,一些默认的属性值将会被使用。以下表格是可能使用到的值:
Property Name | Default value in DSL object | Default value |
---|---|---|
versionCode | -1 | value from manifest if present |
versionName | null | value from manifest if present |
minSdkVersion | -1 | value from manifest if present |
targetSdkVersion | -1 | value from manifest if present |
applicationId | null | value from manifest if present |
testApplicationId | null | applicationId + “.test” |
testInstrumentationRunner | null | android.test.InstrumentationTestRunner |
signingConfig | null | null |
proguardFile | N/A (set only) | N/A (set only) |
proguardFiles | N/A (set only) | N/A (set only) |
如果你在构建脚本中使用自定义代码逻辑请求这些属性,那么第二列的值将非常重要。例如,你可能会写:
if (android.defaultConfig.testInstrumentationRunner == null) {
// assign a better default...
}
如果这个值一直保持null,那么在构建执行期间将会实际替换成第三列的默认值。但是在DSL元素中并没有包含这个默认值,所以,你无法查询到这个值。 除非是真的需要,这是为了预防解析应用的manifest文件。
Build Types(构建类型)
默认情况下,Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试,以及APK如何签名。
Debug版本采用使用通用的name/password键值对自动创建的数字证书进行签名,以防止构建过程中出现请求信息。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()
或者直接使用闭包来配置它。
以下是一些可能使用到的属性和默认值:
Property name | Default values for debug | Default values for release / other |
---|---|---|
debuggable | true | false |
jniDebugBuild | false | false |
renderscriptDebugBuild | false | false |
renderscriptOptimLevel | 3 | 3 |
applicationIdSuffix | null | null |
versionNameSuffix | null | null |
signingConfig | android.signingConfigs.debug | null |
zipAlign | false | true |
runProguard | false | false |
proguardFile | N/A (set only) | N/A (set only) |
proguardFiles | N/A (set only) | N/A (set only) |
除了以上属性之外,Build Type还会受项目源码和资源影响: 对于每一个Build Type都会自动创建一个匹配的sourceSet。默认的路径为:
src/<buildtypename>/
这意味着BuildType名称不能是main或者androidTest(因为这两个是由plugin强制实现的),并且他们互相之间都必须是唯一的。
跟其他sourceSet设置一样,Build Type的source set路径可以重新被定向:
android {
sourceSets.jnidebug.setRoot('foo/jnidebug')
}
另外,每一个Build Type都会创建一个新的assemble任务。
assembleDebug
和assembleRelease
两个Task在上面已经提到过,这里要讲这两个Task从哪里被创建。当debug
和release
构建类型被预创建的时候,它们的tasks就会自动创建对应的这个两个Task。
上面提到的build.gradle代码片段中也会实现assembleJnidebug
task,并且assemble
会像依赖于assembleDebug
和assembleRelease
一样依赖于assembleJnidebug
。
提示:你可以在终端下输入gradle aJ去运行assembleJnidebug task
。
可能会使用到的情况:
- release模式不需要,只有debug模式下才使用到的权限
- 自定义的debug实现
- 为debug模式使用不同的资源(例如当资源的值由绑定的证书决定)
BuildType的代码和资源通过以下方式被使用:
- manifest将被混合进app的manifest
- 代码行为只是另一个资源文件夹
- 资源将叠加到main的资源中,并替换已存在的资源。
signing configurations(签名配置)
对一个应用程序签名需要以下:
- 一个Keystory
- 一个keystory密码
- 一个key的别名
- 一个key的密码
- 存储类型
位置,键名,两个密码,还有存储类型一起形成了签名配置。
默认情况下,debug
被配置成使用一个debug keystory。 debug keystory使用了默认的密码和默认key及默认的key密码。 debug keystory的位置在$HOME/.android/debug.keystroe,如果对应位置不存在这个文件将会自动创建一个。
debug
Build Type(构建类型) 会自动使用debug
SigningConfig (签名配置)。
可以创建其他配置或者自定义内建的默认配置。通过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的路径来判断,而不是配置的名称。
注意:虽然经常使用项目根目录的相对路径作为keystore的路径,但是也可以使用绝对路径,尽管这并不推荐(除了自动创建出来的debug keystore)。
Running Proguard(运行 Proguard)
从Gradle Plugin for ProGuard version 4.10之后就开始支持ProGuard。ProGuard插件是自动添加进来的。如果Build Type的runProguard属性被设置为true,对应的task将会自动创建。
android {
buildTypes {
release {
runProguard true
proguardFile getDefaultProguardFile('proguard-android.txt')
}
}
productFlavors {
flavor1 {
}
flavor2 {
proguardFile 'some-other-rules.txt'
}
}
}
发布版本将会使用它的Build Type中声明的规则文件,product flavor(定制的产品版本)将会使用对应flavor中声明的规则文件。
这里有两个默认的规则文件:
- proguard-android.txt
- proguard-android-optimize.txt
这两个文件都在SDK的路径下。使用getDefaultProguardFile()可以获取这些文件的完整路径。它们除了是否要进行优化之外,其它都是相同的。