【问题标题】:Multiple signingConfigs for multiple variants多个变体的多个签名配置
【发布时间】:2015-09-23 14:21:40
【问题描述】:

如何为不同的变体设置不同的签名配置?

例如,我们目前有 Debug/Beta/Release 两种构建类型,免费和付费,产生 6 个变体。为了让它更容易一点,让我们忘记 Debug 变体,只关注 freeBeta/paidBeta/freeRelease/paidRelease。

我想要的是,每个变体使用单独的不同签名配置。

到目前为止,我能找到的唯一解决方案是将signingConfigs 放在buildTypes 中,这样所有Beta 变体都将具有相同的signingConfigs:

buildTypes {
    beta {
        signingConfigs.beta
    }
    release {
        signingConfigs.release
    }
}

或者,使用风味,在这种情况下,所有免费变体都将具有相同的签名配置:

productFlavors {
    free {
        signingConfig signingConfigs.free
        applicationId 'com.example.free'
    }
    paid {
        signingConfig signingConfigs.paid
        applicationId 'com.example.paid'
    }
}

在当前的 productFlavor 闭包中有没有办法做到这一点?是否只能通过覆盖android.applicationVariants.all { variant -> 并根据某些命名方案或其他丑陋的hack 为每个应用程序变体手动应用signingConfig 来解决此问题?

我还找到了this answer,但它似乎不适用于最新的构建工具;编译时出现以下错误:

FAILURE:构建失败并出现异常。

  • 其中:构建文件 '/home/dev/projects/app/build.gradle' 行:61

  • 出了什么问题:评估项目 ':app' 时出现问题。

    在 ProductFlavor 容器上找不到“免费”属性。

【问题讨论】:

  • 您是否有特殊原因要为每种发布类型使用不同的签名配置?您可以使用同一个密钥签署多个 APK。
  • @Tanis.7x 因为测试版是通过另一个系统分发的,然后是 Google Play。而且还需要签名。
  • 看起来你已经设置好了 - 你有代码 sn-p 将为发布和 beta 构建类型分配不同的签名配置。我的问题是为什么每个变体都需要不同的签名密钥。例如,freeReleasepaidRelease 应该可以使用相同的密钥。
  • @Tanis.7x 这并没有解决问题。该应用程序在转换为 gradle 项目之前已经分发过,因此更改密钥库不是解决方案。
  • BTW 付费和免费只是为了让这个概念更容易实现更复杂的应用程序结构白标。

标签: android gradle android-gradle-plugin android-keystore


【解决方案1】:

https://stackoverflow.com/a/32810290/3961802 答案无效。

    beta {
        productFlavors.free.signingConfig signingConfigs.freeBeta
        productFlavors.paid.signingConfig signingConfigs.paidBeta
    }
    release {
        productFlavors.free.signingConfig signingConfigs.freeRelease
        productFlavors.paid.signingConfig signingConfigs.paidRelease                
    }

在这种情况下,发布构建类型将覆盖所有风格。所以freeBeta 的签名配置将是freeRelease

目前,我知道的唯一解决方案是在单独的任务中签署所有构建变体。

signingConfigs {

    bananaDebug {}
    bananaBeta {}
    bananaRelease {}

    orangeDebug {}
    orangeBeta {}
    orangeRelease {}

    lemonDebug {}
    lemonBeta {}
    lemonRelease {}
}

productFlavors {

    banana {}

    orange {}

    lemon {}
}

buildTypes {

    debug {}

    beta {}

    release {}
}

applicationVariants.all {
    def flavorName = it.getFlavorName()
    def buildTypeName = it.buildType.name
    def buildVariantName = flavorName + buildTypeName.capitalize()
    def currentSigningConfig = signingConfigs.getByName(buildVariantName)

    it.mergedFlavor.signingConfig = currentSigningConfig
    // If you want to sign debug build
    buildTypes.debug.signingConfig currentSigningConfig
}

【讨论】:

  • 感谢注意到许多其他关于堆栈溢出的答案提到的缺陷,但是,这也不能解决问题。在mergedFlavor 上设置signingConfig 并不会真正签署组装的应用程序。
  • 就我而言,一切正常,我注册 Google Market 应用程序没有任何问题。
  • 这对我来说似乎也很好。我有两种风格的同一个应用程序(appOne 和 appTwo)和三种构建类型(debug、prod、staging),其中两种需要签名。我能够将 appOneRelease、appOneStaging、appTwoRelease 和 appTwoStaging 提交到各自的 Play 商店频道,每个频道都有自己的签名配置。
  • 对我也不起作用。如前所述,运行 assemble 会生成一个名为 unsigned 的 apk 并运行 apksigner 来验证返回“DOES NOT VERIFY”。
  • @Simas 那么实际上签署了哪些应用程序?
【解决方案2】:

链接的答案实际上工作正常。我让它像这样编译(使用 buildTools 1.3.1 和 gradle-wrapper 2.7)。您遇到的错误(在 ProductFlavor 容器上找不到“免费”属性)肯定是因为您的构建类型是在 build.gradle 中的 productFlavors 之前定义的。

这行不通

signingConfigs {
    freeBeta {}
    freeRelease {}
    paidBeta {}
    paidRelease {}
}    
buildTypes {
    debug {}
    beta {}
    release {}
}
productFlavors {
    free {}
    paid {}
}

这会起作用 (只需交换 productFlavors 和 buildType 的定义顺序)

signingConfigs {
    freeBeta {}
    freeRelease {}
    paidBeta {}
    paidRelease {}
}    
productFlavors {
    free {}
    paid {}
}    
buildTypes {
    debug {}
    beta {}
    release {}
}

这是一个完整的工作示例:

signingConfigs {
        freeBeta {
            keyAlias 'freeBeta'
            keyPassword 'test'
            storeFile file('C:/keystore.jks')
            storePassword 'test'
        }
        freeRelease {
            keyAlias 'freeRelease'
            keyPassword 'test'
            storeFile file('C:/keystore.jks')
            storePassword 'test'
        }
        paidBeta {
            keyAlias 'paidBeta'
            keyPassword 'test'
            storeFile file('C:/keystore.jks')
            storePassword 'test'
        }
        paidRelease {
            keyAlias 'paidRelease'
            keyPassword 'test'
            storeFile file('C:/keystore.jks')
            storePassword 'test'
        }
    }

    productFlavors {
        free {

        }
        paid {

        }
    }

    buildTypes {
        debug {

        }
        beta {
            productFlavors.free.signingConfig signingConfigs.freeBeta
            productFlavors.paid.signingConfig signingConfigs.paidBeta
        }
        release {
            productFlavors.free.signingConfig signingConfigs.freeRelease
            productFlavors.paid.signingConfig signingConfigs.paidRelease                
        }
    }

【讨论】:

  • 不,代码行在这里按顺序执行,最后一个 release{} 块将覆盖 beta{} 块。所以所有产品风格都将在这里使用发布签名密钥
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-09-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-11-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多