Android using Gradle Build flavors in the code lik

问题:

I'm trying to work with build flavors. In my build.gradle I've defined 2 flavors, a normal flavor and an admin flavor.

Basicly the admin flavor has an extra button on the main activity.

I understand that I can define different packages/classes for different flavours. But is there a way to make a sort of if case to add/remove a piece of code depending on the flavor?

Basicly I would need two versions of an Activity. But I don't want two entire different versions of the activity and maintain them.

So in my activity I would like to do

=> gradle check if flavour is 'admin' => if yes add this code of the button

is this possible? Or would you need two different physical activities and thus maintain both of them when you add functionality afterwards.

回答1:

BuildConfig.FLAVOR gives you combined product flavor. So if you have only one flavor dimension:

productFlavors {
    normal {
    }

    admin {
    }
}

Then you can just check it:

if (BuildConfig.FLAVOR.equals("admin")) {
    ...
}

But if you have multiple flavor dimensions:

flavorDimensions "access", "color"

productFlavors {
    normal {
        dimension "access"
    }

    admin {
        dimension "access"
    }

    red {
        dimension "color"
    }

    blue {
        dimension "color"
    }
}

there are also BuildConfig.FLAVOR_access and BuildConfig.FLAVOR_color fields so you should check it like this:

if (BuildConfig.FLAVOR_access.equals("admin")) {
    ...
}

And BuildConfig.FLAVOR contains full flavor name. For example, adminBlue.

回答2:

To avoid plain string in the condition, you can define a boolean property:

productFlavors {
    normal {
        flavorDimension "access"
        buildConfigField 'boolean', 'IS_ADMIN', 'false'
    }

    admin {
        flavorDimension "access"
        buildConfigField 'boolean', 'IS_ADMIN', 'true'
    }
}

Then you can use it like this:

if (BuildConfig.IS_ADMIN) {
    ...
}

回答3:

You can define either different build configuration fields or different resource values (like string values) per flavor, e.g. (as per Google's gradle tips and recipes), e.g.,

android {
  ...
  buildTypes {
    release {
      // These values are defined only for the release build, which
      // is typically used for full builds and continuous builds.
      buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"")
      resValue("string", "build_time", "${minutesSinceEpoch}")
      ...
    }
    debug {
      // Use static values for incremental builds to ensure that
      // resource files and BuildConfig aren't rebuilt with each run.
      // If they were dynamic, they would prevent certain benefits of
      // Instant Run as well as Gradle UP-TO-DATE checks.
      buildConfigField("String", "BUILD_TIME", "\"0\"")
      resValue("string", "build_time", "0")
    }
  }
}

So in this case, something like

productFlavors {
    normal {
        dimension "access"
        buildConfigField("boolean", "IS_ADMIN", "false")
    }

    admin {
        dimension "access"
        buildConfigField("boolean", "IS_ADMIN", "true")
    }
}

and then use it like

if (BuildConfig.IS_ADMIN) {
    ...
} else {
    ...
}

or if it is just to have different string values for different flavors, it can be done with different resValues and then you don't even need the if/then