CODEWITHSUNDEEP
androidandroid-studiogroovybuild.gradle
LincyTonita
LincyTonita

Reputation: 337

Use of flavour dimensions in build.gradle in android studio

We can build multiple variants of application using product flavours field in build gradle. Why flavour dimension? And it is made compulsory with error message, "All flavours should now belong to flavour dimension"

If it has sensible uses, How and where can we differentiate configuration for different flavour dimensions?

All other blogs and posts I referred didn't give me satisfying answers and most tell me "you won't need it". Please throw some light.

Upvotes: 11

Views: 11222

Answers (2)

Ben Butterworth
Ben Butterworth

Reputation: 29008

In some cases, you may want to combine configurations from multiple product flavors. source

Previously, you could not combine product flavors, e.g. full and minApi27. Flavor dimensions are groupings of product flavors, and you can combine flavors from different dimensions. Examples:

  • api dimension: minApi24 and minApi27 flavors
  • mode dimension: demo, full flavors
  • CodeChimp's example: tier: free, paid flavors

The number of build variants Gradle creates is equal to the product of the number of flavors in each flavor dimension and the number of build types you configure.

Build variant: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release] source

So even though we had 4 product flavors and 2 build types (4 x 2), we did not just get 8 build variants. We got 12. Each flavor from a dimension (minApi24, minApi23, minApi21 each create a build variant with the build type and other flavor dimensions.

Read more at the flavor dimensions documentation.

Upvotes: 0

CodeChimp
CodeChimp

Reputation: 4835

I'd best describe flavour dimensions as a way of grouping flavours.

The one use case I can think of is this.

  • You have a free and paid flavour under a dimension of tier.

  • You have a test and prod flavour which point to different backends under a dimension of environment.

When you assemble all you end up with a version for each tier and environment so you can test a free/test version, free/prod version etc.

You don't need to inspect the dimension, just put whatever variables/ conditional code against the flavour as has always been the case.

An example using multiple dimensions

,,,
flavorDimensions "tier", "env"

productFlavors {
    paid {
        dimension "tier"
        ... add variables here
    }

    free {
        dimension "tier"
        versionName = android.defaultConfig.versionName + " free"
        ... add variables here
    }

    test {
         dimension "env"
         ... add variables here
    }

    prod {
         dimension "env"
         ... add variables here
    }
}
...

Upvotes: 14

Related Questions