美文网首页Gradle
gradle配置总结一:打包签名

gradle配置总结一:打包签名

作者: 瞬息之李 | 来源:发表于2017-03-29 23:46 被阅读0次

    生成签名

    只有签名后的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,在文件中定义对应的名字

    相关文章

      网友评论

        本文标题:gradle配置总结一:打包签名

        本文链接:https://www.haomeiwen.com/subject/genyottx.html