生成签名
只有签名后的apk才能安装到手机上
- 1.直接通过as安装到手机上时,其实as使用了默认的keystore(debug.keystore文件)对程序进行了签名(默认的buildType为debug模式–系统有debug和release两个buildtype)
- 2.手动生成签名apk
(1).通过as提供的可视化界面进行生成(Build –> Generate Signed APK),注意最后完成之前选择的Build Type类型
(2).通过Gradle生成,上代码(build.gradle的配置)
buildTypes {
release {
signingConfig signingConfigs.hexin
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
signingConfigs {
hexin {
storeFile file("hexin.keystore")
storePassword "Hex1nT0n9Hua3hun"
keyAlias "hexin.keystore"
keyPassword "Hex1nT0n9Hua3hun"
}
}
我们在buildType为release(发布版)时,配置了生成签名的配置,我们将配置信息放在了signingConfigs.hexin中。
storeFile file :为防止key的文件路径
storePassword : keyStore的密码
keyAlias : 签名的key的名字
keyPassword : key的密码
上述的方法将签名的信息直接暴露出来了,相对不安全
我们可以将签名的信息放到as提供的gradle.properties(project目录下)文件中
配置:
KEY_PATH = C:/
KEY_PASS = 123456
ALIAS_NAME = LMJ
ALIAS_PASS = 123456
引用(直接引用)
signingConfigs {
hexin {
storeFile file(KEY_PATH )
storePassword KEY_PASS
keyAlias ALIAS_NAME
keyPassword ALIAS_PASS
}
}
最后通过as右侧的gradle窗口下的build目录下生产对应的apk,生产apk之前先进行clean,生成选项有assembleDebug(测试版)、assembleRelease(正式版)、assemble(测试版和正式版)
多渠道生成apk
productFlavors {
qs {
applicationId "qs"
}
baidu{
applicationId "baidu"
}
}
在配置了多个渠道时(上图的qs和baidu),这可以跟buildType里的子函数(debug和release和自己自定义的)进行排列组合进行打包生成apk(这里可以生成四种:qsDebug,qsRelease,baiduDebug,baiduRelease)
更进一步如果我们想基于多个标准构建多个版本,可以用flavorDimensions,看下面的例子:
flavorDimensions "brand", "environment"
productFlavors {
branchOne {
flavorDimension "brand"
applicationId "com.example.branchOne"
buildConfigField "String", "CONFIG_ENDPOINT", "http://branchOne.com/android"
}
branchTwo {
flavorDimension "brand"
applicationId "com.example.branchTwo"
buildConfigField "String", "CONFIG_ENDPOINT", "http://branchTwo.org"
}
stubs {
flavorDimension "environment"
}
preprod {
flavorDimension "environment"
}
distrib {
flavorDimension "environment"
}
}
生成的variants(2个buildType2个brand维度3个environment维度=12):
上述的闭包里可以覆盖defaultConfig里面的任意属性,
差别在于改变buildType不会改变应用程序的代码,它们只是处理的东西不同,你可以通过buildType来获取更多的技术细节(例如:build optimization,log level等等),但是app的内容不会改变,相反的,使用productFlavor配置可以改变app的内容(ps:内容可以设想成package理解,buildType没法改applicationId)。
上defaultConfig代码:
defaultConfig {
applicationId "com.example.administrator.framewrok"
minSdkVersion 14
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
如上图的applicationId(applicationId的不同是区分不同apk的标志,可以说只要applicationId不同,相同的apk可以多次安装),如果不同渠道的apk功能有差异,可以在app/src目录下(跟main文件同级别)新建baidu(这个目录的名字跟productFlavors里的渠道名字一致)目录,在该目录下新建java和res目录分别存放代码和资源文件,如要覆盖原有的AndroidManifest文件中的内容,可以自己在baidu目录下新建自己的AndroidManifest.xml文件,这里介绍sourceSet
sourceSets {
main {
manifest.srcFile 'AndroidManifest_Gradle.xml'
java.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
// resources.srcDirs = ['src']
aidl.srcDirs = ['src']
jniLibs.srcDirs = ['libs']
}
qs {
manifest.srcFile qsDir + 'AndroidManifest_Gradle.xml'
java.srcDirs = [qsDir + 'src']
res.srcDirs = [qsDir + 'res']
assets.srcDirs = [qsDir + 'assets']
// resources.srcDirs = [qsDir + 'src']
aidl.srcDirs = [qsDir + 'src']
jniLibs.srcDirs = [qsDir + 'libs']
}
}
每个flavor都可以(但不必须)对应一个Sourceset, 默认使用main,当配置了对应的sourceSet时,优先选择当前编译的那个sourceSet,没有再去main中找(和main进行合并),sourceSet对目录进行了重整理
这里解释下sourceset语法:java.srcDirs = [qsDir + ‘src’]表示as中的java文件用当前model(文件夹要放在对应的model下)下的src文件夹代替,
应用名的复写:
应用名之前都是定义在main/res/values/string.xml中,如果要不同渠道的apk的名字不一样,可以在对应的渠道文件夹下建立相同的目录结构,如baidu/res/values/string.xml,在文件中定义对应的名字