Android studio gradle flavor dimensions build vari

问题:

I have two dimensions of an app, call then green and blue. There will only be these two dimensions but an unlimited number of product flavors. This is the way I'm setting it up in gradle

flavorDimensions "green", "blue"

productFlavors {

    one {
        applicationId "com.app.green.one"
        versionCode 1
        versionName "1.0.0.1";
        flavorDimension = "green"
    }
    two {
        applicationId "com.app.blue.two"
        versionCode 6
        versionName "1.0.1";
        flavorDimension = "blue"
    }
}

But then after i sync gradle, in the build variants tab all I see is oneTwoDebug and oneTwoRelease, where I should see greenOneDebug greenOneRelease, blueTwoDebug, blueTwoRelease

In theory I want to extend it to be something like this

one {
    applicationId "com.app.green.one"
    versionCode 1
    versionName "1.0.0.1";
    flavorDimension = "green"
}
two {
    applicationId "com.app.blue.two"
    versionCode 6
    versionName "1.0.1";
    flavorDimension = "blue"
}
three {
    applicationId "com.app.green.three"
    versionCode 1
    versionName "1.0.0.1";
    flavorDimension = "green"
}
four {
    applicationId "com.app.blue.four"
    versionCode 6
    versionName "1.0.1";
    flavorDimension = "blue"
}

In this case dimensions represent the "type" of app, and then the flavors are more for organizations which can be added.

**EDIT I had the wrong set up for gradle as pointed out here is a more accurate depiction of what I have

flavorDimensions "type", "organization"

productFlavors {

    blue {
        applicationId "com.app.blue"
        flavorDimension = "type"
        versionCode 6
        versionName "1.0.1";
    }
    red {
        applicationId "com.app.red"
        flavorDimension = "type"
        versionCode 1
        versionName "1.0.0.1";
    }

    company1 {
        flavorDimension = "organization"
    }
    company2 {
        flavorDimension = "organization"
    }
}

So far this works, So I can create java source directories for toggling types, but what if I want organization specific config files, do I create java source dirs for each organization as well?

回答1:

I think you misunderstood the concept of flavorDimension.

A flavorDimension is something like a flavor category and every combination of a flavor from each dimension will produce a variant.

In your case, you must define one flavorDimension named "type" and another dimension named "organization". It will produce, for each flavor in the dimension "organization" all possible "type" (or the dual formulation : for each "type" it will produce a variant for each organization).

The flavor dimensions define the cartesian product that will be used to produce variants.

---

EDIT : I'll try to illustrate with pseudo-gradle code:

Let's define some "type" : bronze, silver and gold

Let's define some organizations : customerA, customerB, customerC

All those are productFlavors, but they belong to 2 different dimensions:

flavorDimensions("type_line", "organization")
productFlavors {

    gold {
        ...
        dimension = "type_line"
    }
    silver {
        ...
        dimension = "type_line"
    }
    bronze {
         ...
        dimension = "type_line"
    }

     customerA {
        ...
        dimension = "organization"
    }
    customerB {
        ...
        dimension = "organization"
    }
    customerC {
         ...
        dimension = "organization"
    }

}

This config will produce 18 (3*3*2) variants (if you have the 2 standard build types : debug and release) :

gold-customerA-debug ; gold-customerA-release ; gold-customerB-debug ; gold-customerB-release ; gold-customerC-debug ; gold-customerC-release ;

silver-customerA-debug ; silver-customerA-release ; silver-customerB-debug ; silver-customerB-release ; silver-customerC-debug ; silver-customerC-release ;

... (the same for bronze)

Note that the name of the dimension is totally arbitrary and have no impact on variant names.

Flavor dimensions are very powerful, but if you use too much of them : it results in an exponential explosion of the number of variants (a post build clean-up task may be useful to delete useless or non-sense variant)