How to create two applications for each flavor with different assets folders in Gradle?

Multi tool use
Multi tool use
The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP


How to create two applications for each flavor with different assets folders in Gradle?



Currently I'm working on an application that has 5 flavors and this is the part of my build.gradle files that matters:


buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.14.0'
}
}

apply plugin: 'com.android.application'

repositories {
mavenCentral()
}

android {
compileSdkVersion 20
buildToolsVersion '20.0.0'

signingConfigs {
release {
storeFile file("")
storePassword "password"
keyAlias "alias"
keyPassword "password"
}
}

lintOptions {
abortOnError false
}

defaultConfig {
minSdkVersion 14
targetSdkVersion 20

applicationId 'application.package'
signingConfig signingConfigs.release
}

buildTypes {
release {
signingConfig signingConfigs.release
}
}

productFlavors {
flavor1{
applicationId 'com.flavor1.package'
}
flavor2{
applicationId 'com.flavor2.package'
}
flavor3{
applicationId 'com.flavor3.package'
}
flavor4{
applicationId 'com.flavor4.package'
}
flavor5{
applicationId 'com.flavor5.package'
}
}
}

dependencies {
compile project(':SDK')
}



I had to make some changes in the file, but basically this is it.



The question: I have a requirement to provide for each one of those flavors a different set of assets files in the assets folder that will create a different apk file but will have the same package name. Those apk files will be uploaded to the Google play as the same application but for different regions.



So the package name have to stay the same. So basically I need to create a mechanism that instead of 5 flavors will created 10 flavor when every two of them have the same package name but a different assets folder. How can this be done using gradle?



I have tried implementing this using BuildTypes like so:


buildTypes {
release {
signingConfig signingConfigs.release
sourceSets.main.assets.srcDirs = ['assets']
}
releaseAlt {
signingConfig signingConfigs.release
sourceSets.main.assets.srcDirs = ['assetsalt']
}
}



But for some reason the releaseAlt also takes the files located in the assets directory and not the assetsalt directory.




1 Answer
1



You can use buildTypes for that.


buildTypes {
release {
// ... the usual stuff here
}
releaseAlt {
// .. the usual stuff here too like signing config etc...
}
}



Now the file hierarchy :



You should have


project/
- app/
- src/
- main/
- assets/
- logo.png // Generic assets go here
- java/
- res/
- ...

- flavor1/
- assets/
- logo.png // Specific assets for all the flavor1 Variants

- releaseAlt/
- asset/
- logo.png // Specific assets for all the releaseAlt Variants.

- flavor1ReleaseAlt/
- assets/
- logo.png // very specific assets for the flavor1ReleaseAlt Variant
- SDK/



With this file hierarchy, when you build the flavor1Release variant, you will have the logo.png file from flavor1/assets/, but when you will build the flavor1ReleaseAlt variant, this png will be replaced by the on from flavor1ReleaseAlt/assets/ folder.


flavor1Release


flavor1/assets/


flavor1ReleaseAlt


flavor1ReleaseAlt/assets/



Explanation :



Gradle is using conventions over configurations (by default). Especially when it comes to project structure. When the flavor1ReleaseAlt Variant is being built, Gradle (the Android-plugin actually ;) ) is looking for a folder called flavor1ReleaseAlt/ with some assets, resources, java etc... inside. Theses are the most specific app resources that Gradle could find for this Variant. Then Gradle will look for a folder simply called flavor1/ for some less specifics app resources. Then to an even lesser specific folder called releaseAlt/ and finally to the generic folder (main/).



The different folders have to have very strict names in order to match the Variant lookup :



Hope this helps.





Thanks for your help, but I was hoping for a solution in which I would not have to create a whole flavor again for an application with the same package, but to provide the same flavor with a different assets directory to create two apks that the only difference between them is this assets folder. Do you think this can be done without createing the flavor1ReleaseAlt flavor?
– Emil Adz
Nov 12 '14 at 13:51







You don't have to create a new flavor. In Android Gradle, the concept of flavor is tied to the concept of Variant. A Variant is BuildType + Flavor. For example, if you have a buildType Debug and a Flavor flavor1, the full variant is flavor1Debug. With my solution, you are using a custom buildType to have more Variants on the same Flavors. You just have to define a new BuildType and all your already defined Flavors will have a new Variant.
– pdegand59
Nov 12 '14 at 14:18







With Gradle, the folder hierarchy is Variant-based. If you know that every Flavor are sharing the same assets for the ReleaseAlt BuildType, you can simply add a new folder releaseAlt/assets/ and put all of your alternatives assets inside. Editing the answer
– pdegand59
Nov 12 '14 at 14:20




releaseAlt/assets/





The problem is that not all alternative flavors will share the same alternative assets folder. I need to provide different assets folders for different flavors. That the reason that I wrote what I wrote in the second peace of code. Another problem is that I need that the alternative flavor will contain all the files from the flavor1 directory but to take the assets from the flavor1alt directory. I don't really understand from your explanation how this can be done. Could you elaborate more?
– Emil Adz
Nov 12 '14 at 14:31







If you have a specific alternative asset that goes for flavor1 alternative build, put it in flavor1ReleaseAlt/assets/ folder. If you have a specific alternative assets that goes for flavor 2 alt build, put it in flavor2ReleaseAlt/assets/ folder.
– pdegand59
Nov 12 '14 at 14:35


flavor1ReleaseAlt/assets/


flavor2ReleaseAlt/assets/






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

L3zEJw42MmSNGIR
A5pFAzIto L,nRZ1 igw qL,tDnDw U2emVuw4E9pKPsNn,v,STqpJR,g30jQH K xW,yZFvOV8SjYXREShyU

Popular posts from this blog

Makefile test if variable is not empty

Will Oldham

Visual Studio Code: How to configure includePath for better IntelliSense results