I have an android app with a number of different product flavors configured in my build.gradle file eg
productFlavors { someFlavor {} anotherFlavor {} }
In my application code, I want to be able to get hold of the name of the currently compiled flavor (or build variant). One solution is this:
productFlavors { someFlavor { buildConfig "public static final String PRODUCT_FLAVOR = \"someFlavor\";" } anotherFlavor { buildConfig "public static final String PRODUCT_FLAVOR = \"anotherFlavor\";" } }
And then in my android app call BuildConfig.PRODUCT_FLAVOR
.
Is there some way I can get gradle to do this automatically? Or is there some other API in android I can use to get the product flavor name?
You can add a config file, say 'Appconfig. java' to your productFlavor specific source folders i.e. src/<productflavor>/java/<packagename>/Appconfig. java ; you can then use Appconfig. PRODUCT_FLAVOR in your app.
Build Type applies different build and packaging settings. An example of build types are “Debug” and “Release”. Product Flavors specify different features and device requirements, such as custom source code, resources, and minimum API levels.
Build variants are the result of Gradle using a specific set of rules to combine settings, code, and resources configured in your build types and product flavors. Although you do not configure build variants directly, you do configure the build types and product flavors that form them.
To change the build variant Android Studio uses, select Build > Select Build Variant in the menu bar. For projects without native/C++ code, the Build Variants panel has two columns: Module and Active Build Variant.
Android product flavors also known as Android build types or Android build variants are the native Android app development way to implement different versions of the same application with minor changes provided by Gradle and Android Studio together. Here is the official Android documentation for configuration of Android product flavors.
You can edit the flavor name, applicationID, and add a new signing config, among others. Click OK when you are done. A gradle sync should occur, and when it’s finished, you have successfully setup a new flavor for your app. Take special note of the applicationID.
Now create sub directories with same hierarchy as in main folder to add new layouts, drawable and values for different flavors. To change the build variant, Android Studio uses: select Build > Select Build Variant in the menu bar (or click Build Variants in the windows bar), and then select a build variant from the drop-down menu.
To build and run (or debug) any of the multiple flavors, Click the Build Variants tab, or select Build – Select Build Variant, and select the desired variant. While building multiple flavors, you might come across a situation where each flavor will require its own specific code file. While, ideally, this should be very rare, it could happen.
Edit: This is now done automatically starting with version 0.7 of the plugin. BuildConfig.java
will contains
public static final String BUILD_TYPE = "debug"; public static final String FLAVOR = "f1Fa"; public static final String FLAVOR_group1 = "f1"; public static final String FLAVOR_group2 = "fa";
FLAVOR
is the combined flavor name with all flavor dimensions/groups applied. Then each dimension is available as FLAVOR_<group name>
.
Finally BUILD_TYPE
contains the name of the used build type.
If you have a single flavor dimension, then you only have the FLAVOR
constant.
This is the only way to do it right now.
One thing you could do is automate it. So you could do something like this:
android { productFlavors.whenObjectAdded { flavor -> flavor.buildConfig "public static final String PRODUCT_FLAVOR = \"${flavor.name}\";" } // your normal config here. }
This way you don't have to manually do it for each flavor.
The accepted solution is awesome. For some cases, an alternate may be useful though.
You can add a config file, say 'Appconfig.java' to your productFlavor specific source folders i.e. src/<productflavor>/java/<packagename>/Appconfig.java
; you can then use Appconfig.PRODUCT_FLAVOR
in your app. The compiler will keep you honest and make sure you add this for all flavors.
Like I said, in this particular case, the accepted solution is probably better since you don't even need to add anything for new productFlavors but this approach might be useful for other cases.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With