tool - Gradle firma sabores con diferentes teclas en Android
tag manager developers (6)
Tengo muchos sabores de mi aplicación de Android, y quiero que todos menos uno usen la misma clave . Hay uno que necesita usar una clave diferente.
¿Cómo signingConfig
el signingConfig
por solo 1 sabor de la aplicación (pero dentro del mismo tipo de compilación, por ejemplo, "versión")?
- Me gustaría que todas las compilaciones de forma predeterminada usen la configuración de lanzamiento principal.
- Solo quiero anular 1 sabor
- Quiero poder ejecutar todas las compilaciones de lanzamiento con un solo comando
gradlew assembleRelease
Este último punto es importante ya que actualmente tengo más de 120 sabores diferentes y estoy creciendo. Para personalizar cada sabor por separado es mucho trabajo extra.
Publicaciones relacionadas que he intentado:
Producir compilaciones múltiples firmadas con diferentes claves del tipo de compilación única
- esto requiere configuración para cada sabor
- parece que no usa mi
signingConfig
personalizado de todos modos
Firmar sabores del producto con gradle
- la solución aceptada no funciona (para mí)
- Según un comentario, esto es posible al poner
buildTypes
dentro debuildTypes
pero no entiendo cómo hacerlo.
Configuración de firma de depuración en sabores de productos Gradle
- como se explica en la publicación del blog: Creación de varias ediciones de una aplicación de Android con Gradle
-
no funcionarealmente funciona a la perfección - pero no escala bien para 119 sabores
En general, cada solución parece seguir utilizando la configuración de lanzamiento predeterminada, en lugar de mi configuración personalizada.
Las partes importantes de mi build.gradle
ven así:
signingConfigs {
releaseConfig {
storeFile file(''key'')
storePassword "pass"
keyAlias "alias"
keyPassword "pass"
}
custom {
storeFile file(''custom_key'')
storePassword "pass"
keyAlias "alias"
keyPassword "pass"
}
}
productFlavors {
apple {
applicationId "demo.apple"
}
banana {
applicationId "demo.banana"
}
// def customConfig = signingConfigs.custom
custom {
applicationId "custom.signed.app"
// signingConfig customConfig
}
}
buildTypes {
debug {
applicationIdSuffix ".debug"
}
release {
signingConfig signingConfigs.releaseConfig
// productFlavors.custom.signingConfig signingConfigs.custom
}
}
Debería definir los firmconfigs en sus buildTypes. Agregue configuración de firma personalizada a su tipo de compilación de depuración o cree un tipo de compilación personalizado
buildTypes {
debug {
applicationIdSuffix ".debug"
signingConfig signingConfigs.custom
}
custom {
applicationIdSuffix ".custom"
signingConfig signingConfigs.custom
}
release {
signingConfig signingConfigs.releaseConfig
}
}
Gradle crearía sabor para cada tipo de compilación y, dependiendo del buildType, el sabor usaría el signinconfig respectivo. Con la configuración anterior de tipo de compilación, consideremos el sabor de "manzana". Gradle crearía las siguientes variantes de compilación solo para apple
- appledebug -> configuración de firma personalizada
- applecustom -> configuración de firma personalizada
Apple Release -> liberación de la configuración de firma
Puede seleccionar la variante de compilación respectiva y ejecutar su aplicación
Agregar la configuración de firma al sabor
productFlavors {
def customSigningConfig = signingConfigs.custom
custom {
...
signingConfig customSigningConfig
...
}
Debes declarar tus signingConfigs antes de declarar tus sabores.
El siguiente código usará la versión 1 como predeterminado signingConfig si signingConfig no está especificado en el sabor del producto.
app / build.gradle
signingConfigs {
debug {
storeFile file("/home/.../debugkeystore.jks")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
release1 {
storeFile file("/home/.../testkeystore1.jks")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
release2 {
storeFile file("/home/.../testkeystore2.jks")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
release3 {
storeFile file("/home/.../testkeystore3.jks")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
}
defaultConfig {
applicationId "com.example.signingproductflavors"
minSdkVersion 15
targetSdkVersion 24
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
signingConfig signingConfigs.release1
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile(''proguard-android.txt''), ''proguard-rules.pro''
}
debug {
signingConfig signingConfigs.debug
}
}
productFlavors {
blocks {
applicationId "com.example.blocks"
resValue ''string'', ''APP_NAME'', "Blocks"
}
cloud {
applicationId "com.example.cloud"
resValue ''string'', ''APP_NAME'', "Cloud"
signingConfig signingConfigs.release2
}
deck {
applicationId "com.example.deck"
resValue ''string'', ''APP_NAME'', "Deck"
signingConfig signingConfigs.release3
}
}
La Guía del usuario de Gradle Plugin dice que puedes:
SigningConfig
que cada paquete de lanzamiento use su propioSigningConfig
configurando cada objetoandroid.productFlavors.*.signingConfig
separado.
Esto se demuestra en esta respuesta ( Debug Signing Config en Gradle Product Flavors ) y en esta publicación de blog ( Creación de varias ediciones de una aplicación de Android con Gradle ).
Sin embargo, especificar una línea de signingConfig
por separado para cada sabor no se escala bien, y estaba fuera del alcance de la pregunta. Lamentablemente, ninguna de las respuestas proporcionadas mostró cómo anular correctamente un signingConfig
correctamente.
El truco provino de esta respuesta ( ¿Cómo obtener la variante de compilación elegida actualmente en gradle? ) Que muestra cómo recorrer las variantes de compilación (y, por extensión, los sabores).
Mi solución utiliza un bucle para configurar la signingConfig
en cada sabor en lugar de tener una línea separada para eso. Esto se escala perfectamente bien. La "anulación" se realiza con una sola línea que especifica la configuración personalizada después del ciclo.
Coloque el siguiente código dentro del bloque de buildTypes.release
.
// loop over all flavors to set default signing config
productFlavors.all { flavor ->
flavor.signingConfig signingConfigs.releaseConfig
}
// override default for single custom flavor
productFlavors.custom.signingConfig signingConfigs.custom
No estoy 100% seguro de que esto funcionará, pero no creo que quieras crear un nuevo tipo de compilación. Eso crearía una nueva variante de compilación para cada sabor. Cuando realmente solo quieres un sabor para anular una "configuración predeterminada" :)
Este código no está probado, pero debería poder hacer algo similar a esto:
signingConfigs {
normal {
storeFile file(''key'')
storePassword "pass"
keyAlias "alias"
keyPassword "pass"
}
custom {
storeFile file(''custom_key'')
storePassword "pass"
keyAlias "alias"
keyPassword "pass"
}
}
/**
* defaultConfig is of type ''ProductFlavor''.
*
* If we need to use a different signing key than the default,
* override it in the specific product flavor.
*/
defaultConfig {
versionCode 123
versionName ''1.2.3''
minSdkVersion 15
def standardSigningConfig = signingConfigs.normal
buildTypes{
release {
signingConfig standardSigningConfig
zipAlign true
// ...
}
debug {
//not sure you need this node
}
}
}
productFlavors {
def customConfig = signingConfigs.custom
def standardSigningConfig = signingConfigs.normal
apple {
applicationId "demo.apple"
}
banana {
applicationId "demo.banana"
}
custom {
applicationId "custom.signed.app"
signingConfig customConfig
}
}
Referencia:
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration
Una idea podría ser usar las propiedades del proyecto para determinar si debería o no usar su signinconfig personalizado.
if (project.hasProperty(''custom'')) {
android.signingConfigs.release = customSigningConfig
} else {
//should use the default
}
Luego, para crear tu sabor personalizado, ejecutas:
gradle assembleCustomRelease -Pcustom=true
tl; dr pasa por "gradle.startParameter.taskNames" para buscar el sabor y modificar la variable.
Hago esto para las variantes de prueba para la aplicación Vine y funciona muy bien. También puede usar esto para hacer diferentes compilaciones compilar sin agregar más dimensiones de sabor.
Se vería algo así en tu caso.
//root of buil.gradle OR probably inside buildTypes.release
def signType = signingConfigs.normal;
//You can put this inside builTypes.release or any task that executes becore
def taskNames = gradle.startParameter.taskNames;
taskNames.each { String name ->
if (name.contains("customFlavor")) {
signType = signingConfigs.custom
}
}
buildTypes{
release {
signingConfig signType
}
}