How to define and use a constant in Gradle build script (Android)?
Only I'm not sure how to define orangeProPackage so that it's visible in the entire build.gradle and doesn't break the script.
You could put it in gradle.properties
in your project root. Like other .properties
files, it's just a key-value store:
ORANGE_PRO_PACKAGE=com.morawski.awesomeapp
You then refer to it as a simple global string variable (ORANGE_PRO_PACKAGE
) in your build.gradle
:
buildConfigField 'String', 'ORANGE_PRO_PACKAGE', '"' + ORANGE_PRO_PACKAGE + '"'
it would be best if I could somehow group all these constants
Anything involving .properties
files won't handle that. There, you may be looking at defining globals in the top-level build.gradle
file just in plain Groovy code or something.
Related videos on Youtube
Konrad Morawski
Software engineer with a few years of professional experience, skilled in C# and Java (I've done some work in PHP as well). Microsoft Certified Technology Specialist in Windows applications. Also active on: http://programmers.stackexchange.com/users/29029/konrad-morawski My profile on LinkedIn: http://pl.linkedin.com/pub/konrad-morawski/a6/129/b07 http://memegenerator.net/Computer-Programmer http://cdn.meme.am/instances/500x/63043797.jpg
Updated on July 09, 2022Comments
-
Konrad Morawski almost 2 years
I'm working on an Android application with Gradle as its build system.
My objective is to use a value (a package name) as an
applicationId
:productFlavors { orange { applicationId "com.fruits.android.orange" // ...
But also to expose it via
BuildConfig
so that Java code has access to it.This access has to be from outside the flavor (namely, free version of the app needs to know the package name of the paid version so that it can prompt user for an upgrade in Play store).
So I'd like to do something like that:
productFlavors { orange { applicationId orangeProPackage // ... buildConfigField 'String', 'ORANGE_PRO_PACKAGE', "$orangeProPackage" // ?
Only I'm not sure how to define
orangeProPackage
so that it's visible in the entire build.gradle and doesn't break the script.Since there's a few different flavors, it would be best if I could somehow group all these constants like that (I guess?):
def proPackages = [ orange: "..." apple: "..." banana: "..." ]
and then refer to them in a clean and descriptive manner like
proPackages.orange
etc.The question is, how to accomplish that?
This is not a duplicate of Is it possible to declare a variable in Gradle usable in Java?
I've seen that question (and a few others). I know how to declare buildConfigFields, I already have plenty. My question is about reusing the same value as a
buildConfigField
andapplicationId
.-
ThomasThiebaud over 8 yearsPossible duplicate of Is it possible to declare a variable in Gradle usable in Java?
-
Konrad Morawski over 8 years@Maloubobola it's not a duplicate. I've seen that question (and a few others). I know how to declare buildConfigFields, I already have plenty. My question is about reusing the same value as a
buildConfigField
andapplicationId
.
-
-
Konrad Morawski over 8 yearsActually it should be
buildConfigField 'String', 'ORANGE_PRO_PACKAGE', '"' + ORANGE_PRO_PACKAGE + '"'
or else the value isn't generated as a string literal in BuildConfig and the build breaks. But other than that - it works, thanks for the tip. -
Shobhit Puri about 7 yearsIs it possible to use a different
.properties
file for each flavour? One advantage will be that this way one can retain the same key (in gradle.properties) across the flavours. Based on the flavour since the file would change, the values of those keys would be different. If using the samegradle.properties
file for a string whose value changes based on flavour, we would need to have different keys in same.properties
file, which are harder to maintain over time. -
CommonsWare about 7 years@ShobhitPuri: "Is it possible to use a different .properties file for each flavour?" -- there's nothing automatic for that AFAIK. But Gradle is Groovy, so you can read whatever files from your development machine that you want in your build scripts.