标签:android gradle 项目结构 build task build type 签名配置
原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Basic-Project
一个Gradle项目的构建过程定义在build.gradle文件中,位于项目的根目录下。
一个最简单的Gradle纯Java项目的build.gradle文件包含以下内容:
apply plugin: 'java'这里引入了Gradle的Java插件。这个插件提供了所有构建和测试Java应用程序所需要的东西。
buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.11.1' } } apply plugin: 'android' android { compileSdkVersion 19 buildToolsVersion "19.0.0" }这里包括了Android build file的3个主要部分:
上面提到的基本的构建文件需要一个默认的文件夹结构。Gradle遵循约定优先于配置的概念,在可能的情况尽可能提供合理的默认配置参数。
基本的项目开始于两个名为“source sets”的组件,即main source code和test code。它们分别位于:
* src/main/
* src/androidTest/
里面每一个存在的文件夹对应相应的源组件。
对于Java plugin和Android plugin来说,它们的Java源代码和资源文件路径如下:
* java/
* resources/
但对于Android plugin来说,它还拥有以下特有的文件和文件夹结构:
* AndroidManifest.xml
* res/
* assets/
* aidl/
* rs/
* jni/
注意:src/androidTest/AndroidManifest.xml是不需要的,它会自动被创建。
3.2.1 Configuring the Structure(配置项目结构)
当默认的项目结构不适用的时候,你可能需要去配置它。根据Gradle文档,重新为Java项目配置sourceSets可以使用以下方法:
sourceSets { main { java { srcDir 'src/java' } resources { srcDir 'src/resources' } } }注意:srcDir将会被添加到指定的已存在的源文件夹中(这在Gradle文档中没有提到,但是实际上确实会这样执行)。
sourceSets { main.java.srcDirs = ['src/java'] main.resources.srcDirs = ['src/resources'] }
android { sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } androidTest.setRoot('tests') } }
以上也是将旧构建系统项目迁移到新构建系统需要做的迁移工作。
添加一个插件到构建文件中将会自动创建一系列构建任务(build tasks)去执行(注:gradle属于任务驱动型构建工具,它的构建过程是基于Task的)。Java plugin和Android plugin都会创建以下task:
* assemble:这个task将会组合项目的所有输出。
* check:这个task将会执行所有检查。
* build:这个task将会执行assemble和check两个task的所有工作
* clean:这个task将会清空项目的输出。
实际上assemble,check,build这三个task不做任何事情。它们只是一个Task标志,用来告诉android plugin添加实际需要执行的task去完成这些工作。
这就允许你去调用相同的task,而不需要考虑当前是什么类型的项目,或者当前项目添加了什么plugin。
例如,添加了findbugs plugin将会创建一个新的task并且让check task依赖于这个新的task。当check task被调用的时候,这个新的task将会先被调用。
在命令行环境中,你可以执行以下命令来获取更多高级别的task:
gradle tasks
gradle tasks --all
Java plugin主要创建了两个task,依赖于main task(一个标识性的task):
* assemble
* jar:这个task创建所有输出
* check
* test:这个task执行所有的测试。
jar task自身直接或者间接依赖于其他task:classes task将会被调用于编译java源码。
testClasses task用于编译测试,但是它很少被调用,因为test task依赖于它(类似于classes task)。
通常情况下,你只需要调用到assemble和check,不需要其他task。
你可以在Gradle文档中查看java plugin的全部task。
Android plugin使用相同的约定以兼容其他插件,并且附加了自己的标识性task,包括:
* assemble:这个task用于组合项目中的所有输出。
* check:这个task用于执行所有检查。
* connectedCheck:这个task将会在一个指定的设备或者模拟器上执行检查,它们可以同时在所有连接的设备上执行。
* deviceCheck:通过APIs连接远程设备来执行检查,这是在CL服务器上使用的。
* build:这个task执行assemble和check的所有工作。
* clean:这个task清空项目的所有输出。
这些新的标识性task是必须的,以保证能够在没有设备连接的情况下执行定期检查。
注意build task不依赖于deviceCheck或者connectedCheck。
一个Android项目至少拥有两个输出:debug APK(调试版APK)和release APK(发布版APK)。每一个输出都拥有自己的标识性task以便能够单独构建它们。
* assemble:
* assembleDebug
* assembleRelease
它们都依赖于其它一些tasks以完成构建一个APK需要多个步骤。其中assemble task依赖于这两个task,所以执行assemble将会同时构建出两个APK。
小提示:gradle在命令行终端上支持骆驼命名法的task简称,例如,执行gradle aR命令等同于执行gradle assembleRelease。
check task也拥有自己的依赖:
* check:
* lint
* connectedCheck:
* connectedAndroidTest
* connectedUiAutomatorTest(目前还没有应用到)
* deviceCheck: 这个test依赖于test创建时,其它实现测试扩展点的插件。
最后,只要task能够被安装(那些要求签名的task),android plugin就会为所有构建类型(debug,release,test)安装或者卸载。
Android plugin提供了大量DSL用于直接从构建系统定制大部分事情。
通过SDL可以配置一下manifest选项:
* minSdkVersion
* targetSdkVersion
* versionName
* 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 } }
def computeVersionName() { ... } android { compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { versionCode 12 versionName computeVersionName() minSdkVersion 16 targetSdkVersion 16 } }
如果一个属性没有使用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 |
packageName | packageName | value from manifest if present |
testPackageName | null | app package name + “.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元素中并没有包含这个默认值,所以,你无法查询到这个值。
android { buildTypes { debug { applicationIdSuffix ".debug" } jnidebug.initWith(buildTypes.debug) jnidebug { packageNameSuffix ".jnidebug" jnidebugBuild true } } }
以下是一些可能使用到的属性和默认值:
Property name | Default values for debug | Default values for release / other |
debuggable | debuggable | false |
jniDebugBuild | false | false |
renderscriptDebugBuild | false | false |
renderscriptOptimLevel | 3 | 3 |
packageNameSuffix | 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) |
src/<buildtypename>/这意味着BuildType名称不能是main或者androidTest(因为这两个是由plugin强制实现的),并且他们互相之间都必须是唯一的。
android { sourceSets.jnidebug.setRoot('foo/jnidebug') }
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构建类型的构建类型。
android { buildTypes { release { runProguard true proguardFile getDefaultProguardFile('proguard-android.txt') } } productFlavors { flavor1 { } flavor2 { proguardFile 'some-other-rules.txt' } } }
Android Gradle Plugin指南(二)——基本项目,布布扣,bubuko.com
Android Gradle Plugin指南(二)——基本项目
标签:android gradle 项目结构 build task build type 签名配置
原文地址:http://blog.csdn.net/qinxiandiqi/article/details/37757475