模块的build.gradle
/标识本模块用什么gradle插件,常用的有: Android应用的->com.android.application
Android库->com.android.library / apply plugin ‘…’ /关于android
的所有特殊配置都在这里面,后面会结合例子详解/ android {…}
/代码仓库,一般都配在项目的build.gradle下,模块下此项配置一般省略/ repositories{…} /* gradle
的依赖配置,定义了当前模块需要依赖的其他库/ dependencies{…} /自定义的变量和方法*/ def …
详解android代码块
compileSdkVersion
用哪个版本的Android SDK来编译此模块
buildToolsVersion
构建工具的版本,包括如打包工具aapt、dx、aidl这些,位于$SDK dir$/build-tools/目录下,一般我们都下了好多个版本
lintOptions代码静态检查配置项.
一般情况下,我们只用到abortOnError false表示当lint发现错误时,不中断gradle构建
所有配置项,列出如下,一般用不到:
lintOptions {
// true--关闭lint报告的分析进度
quiet true
// true--错误发生后停止gradle构建
abortOnError false
// true--只报告error
ignoreWarnings true
// true--忽略有错误的文件的全/绝对路径(默认是true)
//absolutePaths true
// true--检查所有问题点,包含其他默认关闭项
checkAllWarnings true
// true--所有warning当做error
warningsAsErrors true
// 关闭指定问题检查
disable 'TypographyFractions','TypographyQuotes'
// 打开指定问题检查
enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
// 仅检查指定问题
check 'NewApi', 'InlinedApi'
// true--error输出文件不包含源码行号
noLines true
// true--显示错误的所有发生位置,不截取
showAll true
// 回退lint设置(默认规则)
lintConfig file("default-lint.xml")
// true--生成txt格式报告(默认false)
textReport true
// 重定向输出;可以是文件或'stdout'
textOutput 'stdout'
// true--生成XML格式报告
xmlReport false
// 指定xml报告文档(默认lint-results.xml)
xmlOutput file("lint-report.xml")
// true--生成HTML报告(带问题解释,源码位置,等)
htmlReport true
// html报告可选路径(构建器默认是lint-results.html )
htmlOutput file("lint-report.html")
// true--所有正式版构建执行规则生成崩溃的lint检查,如果有崩溃问题将停止构建
checkReleaseBuilds true
// 在发布版本编译时检查(即使不包含lint目标),指定问题的规则生成崩溃
fatal 'NewApi', 'InlineApi'
// 指定问题的规则生成错误
error 'Wakelock', 'TextViewEdits'
// 指定问题的规则生成警告
warning 'ResourceAsColor'
// 忽略指定问题的规则(同关闭检查)
ignore 'TypographyQuotes'
}
defaultConfig应用默认配置
defaultConfig下的配置项会动态的在build时配置AndroidManifest.xml里的项目,它的配置可以覆盖manifest里的配置(同一个)
applicationId : 应用唯一标识,区别于manifest清单文件下的package包名。Manifest下的package包名,必须配置,必须和java代码的包名和R资源类的包名一样。Gradle中如果不配applicationId也可以,它会默认读取Manifest下的package包名并与之保持一致,如果配了,可以独立任意命名(可以独立任意命名的好处是可以针对同一套代码,打出不同的版本包,如付费版 免费版 精简版 专业版,对于用户的手机来说,这些是不同的应用,一个手机可以装多个)。
minSdkVersion、targetSdkVersion
minSdkVersion : 安装application所需要的系统最低版本,低于该版本的系统都不可以安装该application。同时不能使用该level版本SDK所不具备的API。例如在minSdkVersion为8的application中调用 this.getActionBar() 就会出现Call requires API level 11 (current min is 8): Android.app.Activity#getActionBar的错误。这是因为ActionBar是在android 11才出现的新功能(new API)
targetSdkVersion : 随着 Android 系统的升级,某个系统的API的行为可能会发生改变,但是只要 APK 的 targetSdkVersion 不变,即使这个 APK 安装在新 Android 系统上,其行为还是保持老的系统上的行为,这样就保证了新系统对老应用的向前兼容性(系统会判断APK的targetSdkVersion,决定执行API的新行为还是老行为)。
当我们修改了APK 的targetSdkVersion 后,必须做完整的测试。
一般来说:minSdkVersion <= targetSdkVersion <= compileSdkVersion
用较低的minSdkVersion来最大限度的覆盖用户机型,用较高的compileSdkVersion和targetSdkVersion获得较好的编译和运行效果。
versionCode versionName mutiDexEnabled
versionCode : 比较版本号,Integer类型,用于版本升级比较大小用,用户不可见。
versionName : 展示版本号,String 一般 “主版本.次版本.小版本” 这样三段点分表示,用户可见。
mutiDexEnabled : 是否开启对多Dex的支持,解决单Dex类名、变量名、方法名超过65535而报错,布尔类型,一般配成true
buildConfigField、resValue使用
使用buildConfigField和resValue的好处 :可以利用gradle对项目进行动态配置,构建时会自动读取你定义的一些变量,并放在自动生成的BuildConfig类中,或者构建时自动帮你替换资源
语法如下:buildConfigField(resValue同样)
跟三个非空的参数,第一个:确定值的类型,第二个:指定key的名字,第三个:传值
例如:
buildConfigField "boolean", "AUTO_UPDATE", "false"
常见用途:动态配置服务器地址,日志开关、自动更新开关、APP显示名称、不同的key配置(如TalkingData在代码中初始化,需要分Debug和Release需要用不同的key)等,我们一般把配置在buildTypes下的release和debug下,取不同的值。
例如:
debug {
minifyEnabled false
shrinkResources false
debuggable true
signingConfig signingConfigs.hidePwdDebug
manifestPlaceholders = [
BUILD_TIME_VALUE : buildTime(),
UMENG_APPKEY_VALUE : "******"
]
resValue "string", "app_name", "gradleDemoDebug"
buildConfigField "boolean", "AUTO_UPDATE", "false"
buildConfigField "String", "BASE_URL", "\"http://www.baidu.com.com/\""
buildConfigField "String", "BASE_H5_URL", "\"http://www.baidu.com/\""
buildConfigField "String", "TALKINGDATA_KEY", "\"********\""
}
release {
minifyEnabled true
zipAlignEnabled true
shrinkResources true
debuggable false
jniDebuggable false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.readLocalConfFileDebug
manifestPlaceholders = [
BUILD_TIME_VALUE : buildTime(),
UMENG_APPKEY_VALUE : "********"
]
resValue "string", "app_name", "gradleDemoRelease"
buildConfigField "boolean", "AUTO_UPDATE", "true"
buildConfigField "String", "BASE_URL", "\"http://www.baidu.com.com/\""
buildConfigField "String", "BASE_H5_URL", "\"http://www.baidu.com/\""
buildConfigField "String", "TALKINGDATA_KEY", "\"********\""
}
signingConfigs签名相关配置
签名相关配置项,在signingConfigs代码块下,一般可配debug, release, dev等多种不同类型的签名配置,有两种配置方法:
1.在类型代码块下,直接写入keystore的密码、别名、别名密码和keystore文件的相对路径。
优点:直观简洁 缺点:不是足够安全,keystore的密码和别名密码,赤裸裸的在那
例子:
signingConfigs {
unsafeDebug {
storeFile file("./key/unsafeDebug.keystore")
storePassword "123456"
keyAlias "unsafeDebug"
keyPassword "123456"
}
}
2.在类型代码块下,不直接明文写入密码这些,用变量替代,具体变量存放在自定义配置文件或者gradle.properties或者local.properties。这些文件不需要提交版本库,需要负责打包的人配置在本地就行,别人也看不到,提高了安全性。
例子 (变量存放在gradle.properties):
hidePwdDebug {
storeFile file(HIDE_STORE_FILE)
keyAlias HIDE_KEY_ALIAS
storePassword HIDE_KEY_PASSWORD
keyPassword HIDE_STORE_PASSWORD
}
例子 (自定义签名配置文件signing.properties):
readLocalConfFileDebug {
storeFile file("xxx.keystore")
storePassword "******"
keyAlias "xxx"
keyPassword "******"
}
//读取本地配置文件,替换掉readLocalConfFileDebug代码块下的配置项
//需在buildTypes引用readLocalConfFileDebug这个签名配置之前执行
File propFile = file('../config/signing.properties');
if (propFile.exists()) {
def Properties props = new Properties()
props.load(new FileInputStream(propFile))
if (props.containsKey('STORE_FILE') && props.containsKey('STORE_PASSWORD') &&
props.containsKey('KEY_ALIAS') && props.containsKey('KEY_PASSWORD')) {
android.signingConfigs.readLocalConfFileDebug.storeFile = file(props['STORE_FILE'])
android.signingConfigs.readLocalConfFileDebug.storePassword = props['STORE_PASSWORD']
android.signingConfigs.readLocalConfFileDebug.keyAlias = props['KEY_ALIAS']
android.signingConfigs.readLocalConfFileDebug.keyPassword = props['KEY_PASSWORD']
} else {
android.buildTypes.release.signingConfig = null
}
} else {
android.buildTypes.release.signingConfig = null
}
buildTypes {
debug {
signingConfig signingConfigs.hidePwdDebug
//signingConfig signingConfigs.readLocalConfFileDebug
}
}
buildTypes详解
buildTypes用来配置不同的构建类型(debug, release, dev, 其他自定义类型),每种类型下都可以定制自己个性化的配置项和配置值,当你配好你需要的构建类型后,sync一下gradle,配制出的类型会显示在Android Studio的”Build Variants”和”Gradle Project-Module-Tasks”下:
一个典型的buildTypes配置例子如下:
debug {
minifyEnabled false
shrinkResources false
debuggable true
signingConfig signingConfigs.hidePwdDebug
manifestPlaceholders = [
BUILD_TIME_VALUE : buildTime(),
UMENG_APPKEY_VALUE : "******"
]
resValue "string", "app_name", "gradleDemoDebug"
buildConfigField "boolean", "AUTO_UPDATE", "false"
buildConfigField "String", "BASE_URL", "\"http://www.baidu.com.com/\""
buildConfigField "String", "BASE_H5_URL", "\"http://www.baidu.com/\""
buildConfigField "String", "TALKINGDATA_KEY", "\"********\""
}
显然,有关signingConfig、buildConfigField、resValue这些的意义和使用场景及方法,前两小节已经说过,不再赘述。
其他:
zipAlignEnabled : zip对齐优化
shrinkResources : 移除无用资源
minifyEnabled : 启用混淆
debuggable : 是否支持调试
jniDebuggable : 是否支持JNI调试
manifestPlaceholders : 替换清单文件里的占位变量值(如各种需在清单里配的key和额外有用数据;跟buildConfigField配置的区别是这个是替换清单里的变量,供清单文件使用。那个是在代码里生成,供代码里面的类读取和使用)
谢谢大家。完结撒花
