CODEWITHSUNDEEP
androidandroid-studiogradleandroid-gradle-pluginandroid-productflavors
sound-man
sound-man

Reputation: 31

How to have multiple configurations for a single Android build Product Flavour when assembling with Gradle?

I have a project in Android Studio with two Product Flavours. They're effectively identical except for a few hard-coded values in them, e.g. URLs, ids and whether to activate some additional functionality.

I'd like to be able to just have one flavour and move these hard-coded values out to some kind of config/properties file which the now generic code could read or pre-load on startup as needed. I'd then like to have some kind of gradle command that creates the different APKs using the different config/properties file.

That way, if I wish to create another configuration for the app (a combination of the properties I mentioned above), I don't have to go copying (and maintaining) another Product Flavour to do this.

It'd be great if this could all be done in Android Studio and not the command line also. Can someone tell me of a way to do this please?

A command-line solution may also be acceptable, but it would ideally have to be Operating System independent as some of our developers work on MACs while others work on PCs.

I and other Android developers around me looked into this ourselves. But we couldn't find anything within the gradle framework that allowed the kind of flexibility I've outlined.

Outside of pre-configured android parameters that can be set in build.gradle, we couldn't find anything where we could configure properties of our own that would affect the build.

The only solution we could see it to have duplicate Product Flavours with the hard-coded values changed to the new configuration we want. We'd like to avoid this at all costs.

Upvotes: 1

Views: 1556

Answers (1)

sound-man
sound-man

Reputation: 31

Looks like I asked too soon :D .

Someone else in our company managed to solve the problem using build types.

For example, say we wanted a boolean variable saying whether the app should operate in "Test-mode". We can define a "TEST_MODE_ENABLED" variable using the buildConfigField parameter. You could define a "testing" build type in the gradle file as follows (see the last build type):

buildTypes {
    debug {
        debuggable true
        buildConfigField "boolean", "TEST_MODE_ENABLED", "false"
    }

    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        buildConfigField "boolean", "TEST_MODE_ENABLED", "false"
    }

    testing {
        debuggable true
        buildConfigField "boolean", "TEST_MODE_ENABLED", "true"
    }
}

This parameter and others can then be accessed in the java code by referencing:

BuildConfig.TEST_MODE_ENABLED

With this concept, we can create as many configurations we like and then define additional Build Variants using these additional build types.

We can also use this with gradlew, e.g.:

gradlew assemble[ProductFlavour][BuildType]

Hope I explained that properly and that it might help someone else.

Upvotes: 2

Related Questions