Setup an Android Environment— debug , staging and release.

Jayant Kumar🇮🇳
4 min readFeb 5, 2024
Photo by Pratiksha Mohanty on Unsplash

In this article we will see how to setup debug , staging and release environment in android development and will also see where we keep our secret keys (eg — Base Url) of each environment.

DEBUG (development env.)

This environment is used by us (developer) to develop and test the application.

STAGING (testing env.)

After development , we will give staging environment’s build to tester for the testing.

RELEASE (production env.)

This environment’s build will be deployed on the Play Store and available for users.

Before creating these environments we have to understand some technical terms →

Build Types

  • debug , staging and release is your build types in android development.
  • By default there will be two build types in android projects i,e, debug and release .
  • by default debug env. is selected , It means we run the application in debug mode.

Flavours

  • Through this flavours feature , we can create more than one version of any application.
  • Suppose we want some features of any application is free and some paid , we can easily do this thing with flavours . we will learn more about flavours in up-coming articles.

Build Variants

  • Build Variants is the combination of build types and flavours and if we didn’t created any flavours then it will only consider build types.

suppose we have build types debug , staging and release. And flavour is free and paid

then build variants will be -

  • free-debug
  • free-staging
  • free-release
  • paid-debug
  • paid-staging
  • paid-release

It means we can test our free and paid version in all the environments (debug , release , staging).

If flavours is not there then the build variants will be -

  • debug
  • staging
  • release

open build.gradle.kts (:app) file and by default release build type is there.

android {
buildTypes {
release {
isDebuggable = false
isMinifyEnabled = false
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
isDebuggable = true
applicationIdSuffix = ".debug"
}
}
}

you can create debug build type , by calling debug{} .

Here in the release build type we have :

  • isDebuggable = false → It means we cannot debug or use this build as a debug build type.
  • isMinifyEnabled = false → it means that you are disabling the minification process performed by proguard . you cannot reduce the size of the apk by removing the unused code and shorter the name of the classes.

And in the debug build type we have :

  • isDebuggable = true → It means that this build type is for debugging purpose . we can put the break points , logs and test the apk while developing.
  • applicationSuffix = “.debug” → It means , when you share this apk with someone the name will be app-debug.apk , debug name is attached at the suffix (end).

Let’s create one more build type i,e, staging

android {
buildTypes{
create("staging") {
initWith(getByName("debug"))
applicationIdSuffix = ".staging"
}
}
}

As you can see above , with the help of create(".....") function , we can create as much as build types in android project.

  • initWith(getByName(“debug”)) → It means we copy all the properties of debug build type for eg :- isDebuggable etc..
  • applicationSuffix = “.staging” → It means , when you share this apk with someone the name will be app-staging.apk , staging name is attached at the suffix (end).

As I told you above, by default debug build type is selected , which means we run the application in debug mode. Basically we called this Build Variants . Here we didn’t created any flavours . so that means , Build Variant will only consider build types (debug , staging , release).

How we can check which build variant is selected or how we can switch to another build variant?

As you can see above , we go to build variants and by default debug mode is selected . You can switch to any build variant by clicking on them.

Let’s come into the most important part where to keep the Base Url and other sensitive information of each environment.

Step → 1

buildFeatures {
compose = true
buildConfig = true
}

Go to your build.gradle.kts file enable buildConfig = true .

Step → 2

 buildTypes {
release {
buildConfigField("String", "BASE_URL", "\"https://api.prod.com/\"")
isDebuggable = false
isMinifyEnabled = false
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
buildConfigField("String", "BASE_URL", "\"https://api.debug.com/\"")
isDebuggable = true
applicationIdSuffix = ".debug"
}
create("staging") {
initWith(getByName("debug"))
buildConfigField("String", "BASE_URL", "\"http://api.staging.com/\"")
applicationIdSuffix = ".staging"
}
}

As you can see above , with the help of buildConfigField(...) , we can defined as much as secret keys of each environment. Now we have different base url of each environments.

After this just sync the gradle and rebuild the project.

step → 3

override fun onCreate() {
super.onCreate()

BuildConfig.BASE_URL

}

Use the BASE_URL field in your project like above. It will get the base url of the selected environment.

Conclusion

It’s a good practise , Before writing any code , just set up the environment. It will be helpful in the scalable projects.

So That’s all for today’s my friends hope you enjoyed and learnt something new from this article. If you have any queries or suggestion do let me know in the comment section.

--

--

Jayant Kumar🇮🇳

Hello , My name is Jayant, I am a tech youtuber and software Engineer from India 🇮🇳