¿Es posible tener archivos de origen personalizados por variante de compilación en Android Gradle?

Nuestra aplicación tiene una versión gratuita y una de pago. También fabricamos versiones de marca, lo que significa que la aplicación varía en dos dimensiones.

Cuatro versiones podrían ser:

La aplicación, Nike ed. gratis
La APP, Nike ed. pagado
La aplicación, Adidas ed. pagado
La aplicación, Adidas ed. gratis

Mi solución ahora es tener dos tipos de compilación, pagados y gratuitos:

buildTypes { paid { packageNameSuffix ".paid" } free { packageNameSuffix ".free" } }

Y dos sabores de la estructura:

 productFlavors{ nike{ packageName "com.example.theapp.nike" } adidas{ packageName "com.example.theapp.adidas" } }

Cada versión gratuita de la aplicación nos hace de un proveedor de contenido, un proveedor de contenido que es específico por combinación de tipo de sabor y construcción. El problema es que no entiendo dónde colocar un archivo de origen basado en la variante de construcción. Los archivos fuente puestos en / src / nike o / src / free serán recogidos dependiendo del tipo de construcción o sabor. Pero ¿qué hay de los archivos de origen que dependen de la variante de construcción (la combinación de tipo y sabor)?

Puede crear una nueva carpeta bajo src para cada build o sabor que tenga. Es decir, «libre», «pagado», «nike», «adidas».

Los archivos que pones en cualquiera de estas carpetas se obtiene al construir dependiendo del tipo y construir ambos.

De acuerdo con Gradle Plugin Guía del usuario en las herramientas de Android Sitio del proyecto:

Al igual que los tipos de construcción, los sabores de productos también aportan código y recursos a través de sus propios conjuntos de fuentes.

Las siguientes reglas se utilizan cuando se trata de todos los conjuntos de fuentes utilizados para crear un único APK:

Todos los códigos fuente (src / * / java) se utilizan juntos como carpetas múltiples que generan una sola salida.

Los manifiestos se combinan en un solo manifiesto. Esto permite que Product Flavors tenga diferentes componentes y / o permisos, de manera similar a Build Types.

Todos los recursos (Android res y activos) se usan con prioridad de superposición donde el Tipo de compilación reemplaza al Sabor del producto, que reemplaza al origen principal .

Cada Variante de generación genera su propia clase R (u otro código fuente generado) de los recursos. Nada se comparte entre las variantes.

Lo que significa que sus archivos java para el buildType "libre" sobrescribirán los de sus sabores "nike" si tienen el mismo nombre.

Pero si agregas algo a un manifiesto, según el segundo punto de la lista anterior, el manifiesto final será una fusión de todos los manifiestos.

Si necesita más personalización puede colocar sus archivos en la carpeta de la variante de construcción "src / freeNike /".

Tuve un problema similar con los tipos de construcción que sobrepasaban los sabores debido a las reglas de superposición.

Acabé redireccionando los conjuntos de fuentes de tipo de compilación en carpetas diferentes dependiendo del sabor que se construyó.

 android.applicationVariants.all { variant -> switch (variant.name) { case "FreeNike": variant.mergeResources.doFirst { android.sourceSets.free.setRoot("src/freeNike") } break; case "FreeAdidas": variant.mergeResources.doFirst { android.sourceSets.free.setRoot("src/freeAdidas") } break; case "PaidNike": variant.mergeResources.doFirst { android.sourceSets.paid.setRoot("src/paidNike") } break; case "PaidAdidas": variant.mergeResources.doFirst { android.sourceSets.paid.setRoot("src/paidAdidas") } break; } }

Por supuesto, puedes usar una estructura de carpetas diferente. Vea el ejemplo aquí: Convenciones de nomenclatura de carpetas para variantes de generación de grados

¿Ha intentado poner el srcDir en el conjunto de fuentes? Al igual que:

  sourceSets { main { java { srcDirs 'src/java' } } }

Eso debería producir un javaResources con dos códigos fuente, nike y adidas.

Echa un vistazo a la más reciente Gradle plugin ahora permite tener variante de recursos específicos http://tools.android.com/tech-docs/new-build-system

Y aquí tienes ejemplo de uso https://android.googlesource.com/platform/tools/build/+/master/tests/overlay3/