android-gradle-深入浅出-五:build-type.md

  • Android
  • Gradle
  • Android Studio
  • Task
  • Build Type

默认情况下,Android插件自动为项目构建一个debug和一个release版本的应用。这两个版本的不同主要体现在在非开发机上的调试功能以及APK的签名方式。debug版本使用一个用公开的name/password创建的key来签名(这样构建的时候就不需要提示输入密码了)。release版本在构建的时候不会进行签名,而是稍后在做。
这个可以使用gradle中的BuildType对象来进行配置。默认情况下,2个BuildType的实例会被创建,一个debug,一个release。Android插件允许自定义这两个实例,当然你也可以创建其他的build type。配置由buildTypes这个DSL来完成:

1
2
3
4
5
6
7
8
9
10
11
12
13
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jniDebuggable true
}
}
}

上面的代码完成了下列配置:
1.配置默认的debug Build Type
设置debug版本的报名为<应用id>.debug,这样就可以在设备上同时安装debug和release版本了。
2.创建一个新的BuildType,名字是jnidebug,同时配置它是复制自debug Build Type。
配置jnidebug开启debug版本的JNI组件,添加一个不同的包名后缀。

创建一个新的的Build Types非常简单,只需要在buildTypes下面通过调用initWith或者使用闭包添加一个新的元素。下表是可以配置的属性以及默认值:

属性明 debug版本默认值 release或其他版本 默认值
debuggable true false
jniDebuggable false false
renderscriptDebuggable false false
renderscriptOptimLevel 3 3
applicationIdSuffix null null
versionNameSuffix null null
signingConfig android.signingConfigs.debug null
zipAlignEnabled false true
minifyEnabled false false
proguardFile N/A (set only) N/A (set only)
proguardFiles N/A (set only) N/A (set only)

出了这些属性,Build Types还可以用来配置代码和资源文件。针对每一个Build Type,一个新的对应的sourceSet会被创建,这个sourceSet使用一个默认的路径src//。这就意味着Build Type的名字不能是main或者androidTest(这是由插件强制的),同时每个Build Type的名字必须是唯一的。

和其他的source sets一样,Build Type中的source set路径也是可以配置的

1
2
3
android {
sourceSets.jnidebug.setRoot('foo/jnidebug')
}

另外,对每一个Build Type,一个新的assemble任务会被创建.前面我已经讲过assembleDebug和assembleRelease任务了,这里就可解释这两个任务的来源了.当debug和release Build Types被预先创建的时候,他们对应的assemble任务也会被一起创建.

上面的build.gradle代码片段还会创建一个assembleJnidebug任务,assemble任务也会添加对assembleJniDebug任务的依赖,正如它对assembleDebug和assembleRelease任务的依赖一样。

小提示:你可以使用 gradle aJ命令来运行assembleJnidebug任务。

可能是使用场景:
仅在debug模式下使用的权限,release模式不使用。
debug时使用不同的实现
debug模式使用不同的资源(比如当一个资源的值依赖于签名的时候)

BuildType中的 代码/资源文件 将会被按照下列方式处理:
manifest配置会被merge到app manifest中
代码不会被merge,会被当做另一个代码目录(source folder)来使用
资源文件会覆盖同名的main中的资源文件

android-gradle-深入浅出四:自定义构建过程之配置manifest

  • Android
  • Gradle
  • Android Studio
  • Task

Android Gradle插件提供了大量的DSL来自定义构建过程。

配置Manifest条目

DSL提供了配置以下Manifest条目的功能:
minSdkVersion
targetSdkVersion
versionCode
versionName
applicationId (更加方便有效的包名 — 参考)
测试app的包名
Instrumentation test runner
示例:

1
2
3
4
5
6
7
8
9
10
11
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
versionCode 12
versionName "2.0"
minSdkVersion 16
targetSdkVersion 16
}
}

android元素中的defaultConfig元素就是我们用来配置Manifest的地方。早期版本的Android插件使用packageName来配置manifest中的packageName属性,从0.11.0开始,使用applicationId来代替packageName。这样可以消除应用的包名(其实就是应用的id)和java的包名之间的混淆。

更强大的是build文件中描述的配置可以是动态的,比如可以从文件或者自定义的逻辑中获取版本名称。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
def computeVersionName() {
...
}
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
versionCode 12
versionName computeVersionName()
minSdkVersion 16
targetSdkVersion 16
}
}

注意:不要使用作用域中的getter方法名作为函数名,比如在defaultConfig{}作用域中调用getVersionName()将会自动调用defaultConfig.getVersionName(),而不会调用自定义的方法。
如果某个属性的值没有使用DSL设置,这个属性将会使用某些默认值,下表展示了默认值的处理过程。

属性名 DSL对象中的默认值 默认值
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)

如果你想在build脚本中使用自定义的逻辑来查询这些属性,第二列中的值就很重要。比如,你可以编写如下的代码:

1
2
3
if (android.defaultConfig.testInstrumentationRunner == null) {
// assign a better default...
}

如果属性的值仍然是null,那么在构建的时候,就会使用第三列的默认值,但是DSL元素中并不包含这些默认值,因此你不能在程序中查询这些值。这样做的目的是仅在必要的时候(构建时)才会去解析manifest内容。

android-gradle-深入浅出三:build-task

  • Android
  • Gradle
  • Android Studio
  • Task

构建任务(Build Tasks)

java和Android通用的任务
在build文件中使用了Android或者Java插件之后就会自动创建一系列可以运行的任务。

Gradle中有如下一下默认约定的任务:

  1. assemble
    该任务包含了项目中的所有打包相关的任务,比如java项目中打的jar包,Android项目中打的apk
  2. check
    该任务包含了项目中所有验证相关的任务,比如运行测试的任务
  3. build
    该任务包含了assemble和check
  4. clean
    该任务会清空项目的所有的输出,删除所有在assemble任务中打的包

assemble, check 和 build 任务实际上并不做任何事情,它们其实只是为插件提供了一个钩子,真正的事情都是由插件来完成的。

这样的话,开发人员就不需要关心我到底运行的是一个java项目还是一个Android项目,也不用关心我到底使用了哪些gradle插件,因为我都可以调用这些约定的任务来完成构建。

比如使用findbugs插件会创建一个新的任务,并且使得check任务依赖于这个新建的任务,这样每次执行check任务的时候,都会执行这个新建的任务。

在命令行执行

1
gradle tasks

会列出所有主要的任务

如果想看到全部的任务和它们的依赖,可以运行:

1
gradle tasks --all

注意:Gradle会自动检查一个任务的输入和输出。比如连续两次运行build任务的,Gradle会报告所有的任务都已经是最新刚运行过的了,不需要再次运行。这样的话,任务之间就算是有相互依赖,也不会导致重复的执行。

Java项目常用的任务

Java plugin 主要创建了两个任务:

  1. jar
    assemble任务会依赖jar任务,看名字就知道这是负责打jar包的任务。jar任务本身又会依赖很多其他的任务,比如classes任务,classes任务会编译java代码
  2. test
    check任务会依赖test任务,这个任务会运行所有的测试。测试代码使用testClasses任务编译,但是我们基本不用手动运行testClasses任务因为test任务已经添加了对它的依赖。

通常情况下,我们只要运行assemble和check任务就够了。
想查看java插件提供的所有任务以及他们的依赖可以点这个链接

Android项目常用的任务

和其他gradle插件一样,Android插件也提供了一些默认的任务,比如assemble,check,build,clean,同时它也提供了一些自己特有的任务,比如:

  1. connectedCheck
    运行那些需要在真机或者模拟器上执行的检查任务,这些任务会并行地在所有连接的设备上运行
  2. deviceCheck
    使用APIs连接远程设备执行检查.主要用于CI(持续集成)服务上.
    上面两个任务都会执行 assemble 和 check任务。新加这两个任务是很有必要的,这样可以保证我们可以运行那些不需要连接设备的检查任务。

注意:build任务并不依赖于deviceCheck或者connectedCheck

一个Android项目通常至少会有两种输出:debug apk和release apk。对应的gradle中有两个任务可以分别输出不同的apk:
assembleDebug
assembleRelease
这两个任务又会依赖其他的任务来构建一个apk。assemble任务依赖这两个任务,调用assemble任务就会生成两种apk。

小提示: Gradle支持在命令行使用camel风格的缩写来代替任务的名字,比如:

1
gradle aR

等同于

1
gradle assembleRelease

只要没有其他任务的缩写也是’aR’

check相关的任务的依赖:
check依赖lint
connectedCheck依赖 connectedAndroidTest和connectedUiAutomatorTest (还没有实现)
deviceCheck依赖于那些实现了test扩展的插件所提供的任务

最后,Android gradle插件还提供了install和uninstall任务,用来安装和卸载apk