Develop Reference

Where are build types of the app defined?

I know we can edit build types in Android Studio:
I know we can edit each build type setting in gradle:
android {
buildTypes {
release {
minifyEnabled true
}
}
I know we can detect build types in code. How do I detect if I am in release or debug mode?
But where actually are the build types defined? Let say I want to commit it to git. What should I do to keep build types of the project consistent?

Where actually are the build types defined?
Basically, BuildConfig is the auto-generated class that resides under path :
app/build/generated/source/buildConfig/yourBuildType/yourPackageName/BuildConfig.java.
This class holds variables provided by buildTypes {} block from app level build.gradle file. So, on every clean & rebuild of project, Gradle auto generates BuildConfig class that can be used in further Android development environment.
I.e. BuildConfig.DEBUG is the default variable that we can use in our application code to determine it's buildType.
We can provide our own fields through buildType from build.gradle file like following:
android {
. . .
buildTypes {
debug {
buildConfigField "String", "SOME_VARIABLE", '"This string value is from build config class"'
}
}
. . .
}

Android and the Fabric (Crashlytics) plugin always generates a UUID (Gradle Kotlin DSL)

I want Fabric to stop generating a UUID on each build. What used to work with Gradle's Groovy DSL does not work with the newer Kotlin DSL. How can I achieve my goal with the Kotlin DSL?
(Gradle version 4.10.2, Fabric 1.25.4)
According to Fabric's documentation, you can add the following to your app's build script
android {
buildTypes {
debug {
// Only use this flag on builds you don't proguard or upload
// to beta-by-crashlytics
ext.alwaysUpdateBuildId = false
and this works. It prevents Fabric from generating a UUID on each debug build. However, if I convert my build script to Kotlin DSL, the following doesn't work
android {
buildTypes {
getByName("debug") {
// Only use this flag on builds you don't proguard or upload
// to beta-by-crashlytics
ext.set("alwaysUpdateBuildId", false)
Fabric ignores this value, now.
I have tried variations, such as the following:
project.ext.set("alwaysUpdateBuildId", false)
rootProject.ext.set("alwaysUpdateBuildId", false)
val alwaysUpdateBuildId by extra(false)
val alwaysUpdateBuildId by project.extra(false)
val alwaysUpdateBuildId by rootProject.extra(false)
None work.
For further reference, the Gradle task generating this value appears to be named :app:fabricGenerateResourcesDebug, and has type DefaultTask.

As Martin Rajniak mentioned, you can only call extra on ExtensionAware objects, with BuildType not being declared as one.
However, during runtime, build types actually are ExtensionAware, which is why this works in Groovy due to its dynamicity, but not in Kotlin where extra in this scope will reference the Project's extensions.
In order to achieve this without Groovy, we can simply cast the build type to ExtensionAware:
android {
buildTypes {
getByName("debug") {
(this as ExtensionAware).extra["alwaysUpdateBuildId"] = false
}
}
}

I have found a workaround to this problem. Create a file, fabric.gradle (Groovy build script!) and place it in your project structure somewhere. It will have the following contents:
// or "com.android.library"
project.pluginManager.withPlugin("com.android.application") {
android.buildTypes.debug.ext.alwaysUpdateBuildId = false
}
Now, in the build script for your module (let's call it app/build.gradle.kts), apply this script plugin:
apply(from = "path/to/fabric.gradle")
This workaround is based on the advice here, in the Kotlin DSL primer.

Android: How to reset resConfigs for release variant?

To make development faster, I want to do the following:
android {
defaultConfig {
resConfigs "en"
}
}
My app has a lot of languages, and doing this saves significant time while developing. However, I do NOT want to release a version with this set. Unfortunately, resConfigs is not available on product flavors or build types, so I can't set it in debug {}, for example.
How can I automatically exclude resConfigs from release variants? I do not want to have to remember comment out that line of code when I'm building for release.

Wouldn't this work?
Detect the debug build, reset the configurations and add your desired debug configuration.
applicationVariants.all { variant ->
if (variant.buildType.name == "debug") {
variant.mergedFlavor.resourceConfigurations.clear()
variant.mergedFlavor.resourceConfigurations.add("en")
}
}

My solution was inspired by this answer to a related question. Here's how you do it:
in app/build.gradle
// Reset `resConfigs` for release
afterEvaluate {
android.applicationVariants.all { variant ->
if (variant.buildType.name.equals('release')) {
variant.mergedFlavor.#mResourceConfiguration = null
}
}
}
This works because mResourceConfiguration is the backing field for resConfigs. Unfortunately, The Android Gradle DSL does not currently expose a method to reset resConfigs, so we're forced to access the field directly using the groovy #<fieldName> syntax. This works, even though mResourceConfiguration is private.
WARNING: this solution is a little fragile, as the Android Gradle build tools team could change the name of that field at any time, since it is not part of the public API.

How to define and use a constant in Gradle build script (Android)?

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 and applicationId.

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.

you could use extentions like this:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
ext.kotlin_version = '1.6.10'
ext.app_version_code = 1010
ext.app_version_name = '1.0.1.0'
}

Gradle using two property files one for debug and release

I am trying to migrate an android project from maven to gradle.
In maven I have two profiles (dev and prod), dev profile uses a dev.properties file to set up some properties and prod uses prod.properties.
I want to be able to tell gradle to use dev.properties for debug build and prod.properties for release build.
More specifically all I need to do is rename the file to constants.properties
How can I achieve this?

Assuming you already have a way to distinguish between dev vs prod, you can rename the file in Groovy with something like this:
def dev = true // set to true or false
def propFile
if (dev) {
propFile = file("dev.properties")
} else {
propFile = file("prod.properties")
}
propFile.renameTo("constants.properties")