tools - Aplicación de sabor múltiple basada en la biblioteca de sabores múltiples en Android Gradle
install gradle android studio (8)
Mi aplicación tiene varios sabores para varios mercados en los sistemas de facturación en la aplicación.
Tengo una única biblioteca que comparte el código base para todos mis proyectos. Así que decidí agregar esos sistemas de pago a esta biblioteca como sabores de productos.
La pregunta es ¿puede la biblioteca de Android tener sabores de productos?
Si es así, ¿cómo puedo incluir diferentes sabores en el sabor respectivo de la aplicación?
Busqué mucho y no pude encontrar nada sobre este escenario. Lo único que encontré fue esto en http://tools.android.com/tech-docs/new-build-system/user-guide :
dependencies {
flavor1Compile project(path: '':lib1'', configuration: ''flavor1Release'')
flavor2Compile project(path: '':lib1'', configuration: ''flavor2Release'')
}
Cambié la configuración a diferentes cosas pero no funcionó!
Estoy usando android studio 0.8.2.
Finalmente descubrí cómo hacer esto, lo explicaré aquí para otros que enfrentan el mismo problema:
La parte clave es establecer publishNonDefault en true en la biblioteca build.gradle, luego debe definir las dependencias como lo sugiere la guía del usuario.
Todo el proyecto sería así:
Library build.gradle:
apply plugin: ''com.android.library''
android {
....
publishNonDefault true
productFlavors {
market1 {}
market2 {}
}
}
proyecto build.gradle:
apply plugin: ''com.android.application''
android {
....
productFlavors {
market1 {}
market2 {}
}
}
dependencies {
....
market1Compile project(path: '':lib'', configuration: ''market1Release'')
market2Compile project(path: '':lib'', configuration: ''market2Release'')
}
Ahora puede seleccionar el sabor de la aplicación y el panel Construir variantes y la biblioteca se seleccionará en consecuencia y todas las compilaciones y ejecuciones se realizarán en función del sabor seleccionado.
Si tiene un módulo de aplicaciones múltiples basado en la biblioteca, Android Studio se quejará sobre el conflicto de selección de variantes. Está bien, simplemente ignórelo.
Hay un problema con la respuesta de Ali . Estamos perdiendo una dimensión muy importante en nuestras variantes de compilación. Si queremos tener todas las opciones (en mi ejemplo, debajo de 4 (2 x 2)) solo tenemos que agregar configuraciones personalizadas en el archivo build.gradle del módulo principal para poder usar todo multi-flavor multi-buildType en Build Variants . También debemos establecer publishNonDefault verdadero en el archivo build.gradle del módulo de biblioteca .
Ejemplo de solución:
Lib build.gradle
android {
publishNonDefault true
buildTypes {
release {
}
debug {
}
}
productFlavors {
free {
}
paid {
}
}
}
Aplicación build.gradle
android {
buildTypes {
debug {
}
release {
}
}
productFlavors {
free {
}
paid {
}
}
}
configurations {
freeDebugCompile
paidDebugCompile
freeReleaseCompile
paidReleaseCompile
}
dependencies {
freeDebugCompile project(path: '':lib'', configuration: ''freeDebug'')
paidDebugCompile project(path: '':lib'', configuration: ''paidDebug'')
freeReleaseCompile project(path: '':lib'', configuration: ''freeRelease'')
paidReleaseCompile project(path: '':lib'', configuration: ''paidRelease'')
}
Para que los sabores funcionen en una biblioteca AAR, debe definir defaultPublishConfig en el archivo build.gradle de su módulo de biblioteca Android.
Para obtener más información, ver: http://tools.android.com/tech-docs/new-build-system/user-guide .
Publicación de la biblioteca
Por defecto, una biblioteca solo publica su variante de lanzamiento. Esta variante será utilizada por todos los proyectos que hacen referencia a la biblioteca, sin importar qué variante construyan ellos mismos. Esta es una limitación temporal debido a las limitaciones de Gradle que estamos trabajando para eliminar. Puede controlar qué variante se publica:
android {defaultPublishConfig "debug"}
Tenga en cuenta que este nombre de configuración de publicación hace referencia al nombre completo de la variante. Liberación y depuración solo son aplicables cuando no hay sabores. Si desea cambiar la variante publicada por defecto mientras usa los sabores, debería escribir:
android {defaultPublishConfig "flavor1Debug"}
Por el momento no es posible, aunque si recuerdo correctamente es una característica que quieren agregar. (Editar 2: link , link2 )
Editar: Por el momento estoy usando la opción defaultPublishConfig para declarar qué defaultPublishConfig de biblioteca se ha publicado:
android {
defaultPublishConfig fullRelease
defaultPublishConfig demoRelease
}
Sé que este tema se ha cerrado, pero solo una actualización con gradle 3.0, mira esto: https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#variant_aware y grep matchingFallbacks y missingDimensionStrategy . Ahora es mucho más simple declarar las dependencias entre los sabores de los módulos.
... y en este caso preciso con gradle3.0, como los sabores comparten el mismo nombre, gradle los mapearía mágicamente, no se requiere configuración.
También encontré un problema compilando módulos para varias opciones.
Lo que he encontrado:
Parece que no necesitamos agregar publishNonDefault true en el archivo build.gradle de lib, ya que Gradle 3.0.1 .
Después de decompilar una clase BaseExtension encontró esto:
public void setPublishNonDefault(boolean publishNonDefault) {
this.logger.warn("publishNonDefault is deprecated and has no effect anymore. All variants are now published.");
}
Y en lugar de:
dependencies {
...
Compile project(path: '':lib'', configuration: ''config1Debug'')
}
Deberíamos usar:
dependencies {
...
implementation project('':lib'')
}
Solo lo importante es agregar una parte de configurations {...} a build.gradle .
Entonces, la variante final del archivo build.gradle de la aplicación es:
buildTypes {
debug {
...
}
release {
...
}
}
flavorDimensions "productType", "serverType"
productFlavors {
Free {
dimension "productType"
...
}
Paid {
dimension "productType"
...
}
Test {
dimension "serverType"
...
}
Prod {
dimension "serverType"
...
}
}
configurations {
FreeTestDebug
FreeTestRelease
FreeProdDebug
FreeProdRelease
PaidTestDebug
PaidTestRelease
PaidProdDebug
PaidProdRelease
}
dependencies {
implementation fileTree(dir: ''libs'', include: [''*.jar''])
implementation project('':lib'')
...
}
Además, puede usar variantes de filtro para restringir las variantes de compilación.
No olvides incluir módulos en el archivo settings.gradle , como:
include '':app''
include '':lib''
project('':lib'').projectDir = new File(''app/libs/lib'')
También puede usar esto para tener compilaciones dependientes del sabor:
ext {
flavorType = ""
}
gradle.startParameter.getTaskNames().each { task ->
if(task.contains("flavor1")){
flavorType = "flavor1"
} else if (task.contains("flavor2")){
flavorType = "flavor2"
} else {
flavorType = "flavor3"
}
}
if(flavorType == ''flavor1'' || flavorType == ''flavor2'') {
compile ''com.android.support:support-v4:18.0.+''
}
Actualización para Android Plugin 3.0.0 y superior
De acuerdo con la documentación oficial de Android: migrar configuraciones de dependencia para módulos locales ,
Con la resolución de dependencia compatible con variantes, ya no necesita usar configuraciones específicas de variante, como freeDebugImplementation, para dependencias de módulos locales; el complemento se encarga de esto por usted
En su lugar, debe configurar sus dependencias de la siguiente manera:
dependencies {
// This is the old method and no longer works for local
// library modules:
// debugImplementation project(path: '':library'', configuration: ''debug'')
// releaseImplementation project(path: '':library'', configuration: ''release'')
// Instead, simply use the following to take advantage of
// variant-aware dependency resolution. You can learn more about
// the ''implementation'' configuration in the section about
// new dependency configurations.
implementation project('':library'')
// You can, however, keep using variant-specific configurations when
// targeting external dependencies. The following line adds ''app-magic''
// as a dependency to only the "debug" version of your module.
debugImplementation ''com.example.android:app-magic:12.3''
}
Entonces en la respuesta de Ali, cambiar
dependencies {
....
market1Compile project(path: '':lib'', configuration: ''market1Release'')
market2Compile project(path: '':lib'', configuration: ''market2Release'')
}
a
implementation project('':lib'')
Y el complemento se ocupará de las configuraciones específicas de la variante automáticamente. Espero que ayude a otros a actualizar Android Studio Plugin a 3.0.0 y superior.