Gradle for Android学习笔记(一)
每一个build.gradle文件代表一个project,一个project会有多个tasks
如Android工程:包含Android tasks,build tasks,build setup tasks,help tasks,install tasks,other tasks.
gradlew命令
gradlew -help—->查看命令
gradlew tasks—->查看root project有多少个task
gradlew tasks –all—->查看详细的tasks
gradlew -v/gradlew.bat -v—->查看Gradle版本及其他信息
gradlew assembleDebug—->创建一个debug版本的app,在app/build/outputs/apk目录下,也可以执行简称:gradlew assDeb或gradlew aD
gradlew :app:assembleDebug—->指定module名称执行assemble任务创建debug版本apk文件。
Android Tasks简述
Base tasks:定义了tasks,但没有实现
- assemble
- clean
- check
- build
Android tasks:实现了base tasks的行为
- assemble:对每一个build type创建一个apk
assemble tasks默认依赖assembleDebug和assembleRelease
- clean:移除所有的编译产生的文件
- check:执行Lint检查,如果Lint检测到问题,可以中断编译
- build:在assemble和check都运行
Project中build.gradle文件,对多个Module统一管理
如果你的工程有多个Android项目,可以把共同的设置写在allprojects中,如
allprojects{
apply plugin:'com.android.application'
android{
compileSdkVersion 24
buildToolsVersion "24.0.0"
}
}
这样要求你的module都是Android app,当然有更好的一个写法,可以在project中的build文件中定义一个ext{},如:
ext{
compileSdkVersion = 24
buildToolsVersion = "24.0.0"
}
在Module中的build文件中的android{}中使用,如:
android{
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
}
自定义task
在build.gradle中自定义tasks任务,如:
ext{
local="hello local"
}
task print<<{
println local
println ok //task可以执行gradle.properties文件中的配置
}
在gradle.properties文件中
ok='hello property'
Native Library:
android默认支持native library,当然你需要 在Module中创建一个jniLib目录,如:
android{
...
sourceSets.main{
jniLibs.srcDir 'src/main/libs'
}
}
使用.aar文件
repositories{
flatDir{
dirs 'aars'
}
}
dependencies{
compile(name:'libraryname',ext:'aar')
}
Dependency的概念:
- compile:默认,大多数应用都全部依赖于它
- apk:仅仅添加包,不参与编译。仅仅作为Jar依赖,添加代lib库中可能导致error
- provided:这个依赖不会被打包。仅仅作为Jar依赖,添加代lib库中可能导致error
- testCompile:添加测试的依赖
- androidTestCompile:添加测试的依赖。
- debugCompile:debug版本的依赖。
- releaseProvided:release版本不打包。
自定义buildTypes{}
在module项目中会自动生成一个release版本的build type,同时也有一个默认的debug版本(只不过隐藏了,可以对它的属性值进行重写,当然也可以自定义,如:
android{
...
buildTypes{
release{
...
}
debug{
...
}
my.initWith(buildTypes.debug) //复制debug的所有属性
my{
applicationIdSuffix ".my" //applicationId的变体
versionNameSuffix "-my"
buildConfigFiled "boolean" "LOG_DEBUG" "true"
...
}
}
}
my.initWith(buildTypes.debug) —-表示my类型复制debug所有属性
applicationIdSuffix “.my” —-表示应用id后面接上一个.my,如:
debug类型的applicationId:com.example
my类型的applicationId:com.example.my
应为applicationId不同,所以可以在同一个设备同时安装这2个apk。一般用于区分free版,price版。
- buildConfigFiled—-设置编译配置
buildConfigFiled "boolean" "LOG_DEBUG" "true"
意思是:给这个类型设置设置一个boolean类型的变量LOG_DEBUG,默认为true。
同样还可以这样设置:
buildConfigField "String", "API_URL", "http://staging.example.com/api"
意思是:配置文件从网络请求。
在项目中的使用:
if(BuildConfig.LOG_DEBUG){
log.e("","")
}
封装成一个工具类,可以根据debug版本和release版本的不同进行log的统一开闭管理。
SourceSets
当你创建一个名称为staging的build类型时,你需要使用自定义的source code和resource时,需要手动创建一个名称和build type名称相同的目录。如图:
我们在staging目录下可以创建自己的resource,可以覆盖和main目录中的resource。
如:
你的main中string.xml文件中
<resources>
<string name="app_name">Application</string>
<string name="hello">hello</string>
...
</resources>
你的staging目录中string.xml文件
<resources>
<string name="app_name">Application Staging</string>
</resources>
那么在合并的时候,string.xml是这样的
<resources>
<string name="app_name">Application Staging</string>
<string name="hello">hello</string>
...
</resources>
如果你的staging目录没有,或没有资源时,直接使用的main中的。
Multiflavtor variants(多渠道打包)
比如我们的app需要打包到多个应用市场,如xiaomi,360等。
android{
productFlavors{
xiaomi{
applicationId "com.example.application"
...
}
360{
applicationId "com.example.application"
...
}
}
}
这样打包的时候就可以打出2个应用市场的release-apk。
如果现在需求变更,需要一个free版本,一个price版本,如何打包呢?
我们可以这样打包,如下:
android{
...
flavorDimensions 'price','store'
productFlavors{
xiaomi{
flavorDimension "store"
}
360{
flavorDimension "store"
}
free{
flavorDimension "price"
}
price{
flavorDimension "price"
}
}
}
flavorDimensions—-是一个数组,store和price代表的2个维度,每个flavor分配到指定的维度中。
上面的例子中将 Product Flavor 分为两组(即两个维度),分别为price维度 [free, paid]和store维度[xiaomi,360] ,再加上默认的 BuildType 有 [debug, release] ,这将会组合生成以下的 Build Variant:
- xiaomi-free-debug和xiaomi-free-release
- 360-free-debug和360-free-release
- xiaomi-price-debug和xiaomi-price-release
- 360-price-debug和360-price-release
Variant filters(过滤变体)
这段代码可放在android{…}中,也可以放在android{}外。
android.variantFilter { variant ->
if (!variant.buildType.name.equals('debug')) {
variant.getFlavors().each() {
flavor ->
if (!flavor.name.equals('xiaomi')) {
variant.setIgnore(true);
}
}
}
}
代码用来过滤一些Variant。结果可以查看这里
Signing configurations(签名配置)
默认情况下大概是这样:一般只需要设置一个release的就好。
android{
signingConfigs{
release{
storeFile file("release.keystore")
storePassword "storepassword"
keyAilas "keyAlias"
keyPassword "keyPassword"
}
}
}
在buildTypes{}中使用
android{
buildTypes{
release{
signingConfig signingConfig.release
}
}
}
这样release版本的在打包的时候,就会带上签名文件。
如果所有的都需要带上签名文件,可以在defaultConfigs{}中使用:
defaultConfigs{
signingConfig signingConfig.release
}
如果针对某个store平台加上签名文件。可以:
android{
productFlavors{
xiaomi{//以小米为例
signingConfig signingConfig.release
}
}
}
如果我们需要对每一个平台使用不同的签名打包,我们可以:
android{
signingConfigs{
release{
...//签名配置,参考上面
}
xiaomi{
...
}
baidu{
...
}
}
}
对release版本打包签名处理:
android{
buildTypes{
release{
productFlavors.xiaomi.signingConfig signConfigs.xiaomi //针对小米release版本进行签名处理(使用小米特用的签名文件)
productFlavors.baidu.signingConfig signConfigs.baidu //针对百度elease版本进行签名处理(使用百度特用的签名文件)
}
}
}