Home Android & Kotlin Books Android App Distribution

9
Build Variants: Implementing Build Types Written by Evana Margain Puig

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

In the following two chapters, you’ll learn how to create different versions of your app within the same project. Before you begin, you need to understand three terms: build variants, build types and build flavors. These three terms are often a source of confusion when releasing to the Google Play Store, especially if you haven’t played around with them. Time to dive right into learning what these terms mean:

  1. Build types: In Android apps, build types usually refer to the environment in which you’re testing. By default, when you create an app in Android Studio from any of the templates, you get two build types: debug and release. If you’ve worked in tech companies, you may know there are usually more than those two. You can customize your build types to include other types such as QA, Release Candidate or RC, Pre-Prod or whatever fits your needs.

  2. Build flavors: Apps often vary in ways besides environment-based differences. Flavors support these kinds of variations. For example, you can use flavors to handle:

  • Having a paid version of your app vs. a free version.
  • Having a version for each store you upload to, such as Amazon Appstore, Google Play Store and Samsung Galaxy Store.
  • Using the same app for different products and customizing the assets to change the app’s look and feel.
  1. Build variants: Variants are the combination of build types and build flavors. For example, you can have a “dev paid” version of your app, which is a combination of the “dev” build type and “paid” flavor of your app. If you have both flavors and types, you’ll release variants when uploading to the Google Play Store or any other store.

Now that you have a clear understanding of what each of these terms means, you’ll start by learning how to implement build types throughout this chapter.

Why use build types?

By now, you understand build types at a high level. In short, it’s a build configuration that lets you differentiate versions of your app depending on the environment you’re targeting, such as development, testing or release. But from a high level, this may not sound like something special or different from a flavor. So take a look at precisely what a build type does behind the scenes.

Build types target configurations in your Gradle properties. For example, a build type can:

  • Enable or disable debugging in your app.
  • Sign the app with a production certificate if needed.
  • Shrink or obfuscate your resources. For an in-depth understanding of this topic, take a look at Chapter 7.

Remember, you need at least one build type to build your app. Android Studio templates give you two by default.

Android Studio base build types

Take a look at PodPlay to see where you can find those default build types. Open the PodPlay project in Android Studio. In the Navigation panel’s Android view, navigate to Gradle Scripts ▸ build.gradle(Module: PodPlay.app). Look at the buildTypes group inside the android declaration.

Switching build types in Android Studio

Android Studio has a Build Variants panel. Usually, you’ll find it at the bottom left of your screen as a closed tab. Tap it and you’ll see the panel. If you can’t see the panel there, go to View ▸ Tool Windows ▸ Build Variants as shown below:

Implementing build types in your app

Now it’s time to put what you’ve learned into practice and create a new build type. Open your app module’s build.gradle located in Gradle Scripts ▸ build.gradle(Module: PodPlay.app). Below the release version closing bracket, add a build variant named qa with:

qa {
  initWith debug
  applicationIdSuffix ".qaTesting"
  signingConfig signingConfigs.debug
}

If you get errors (Optional)

If you had no trouble running the previous step, skip this section. Otherwise, keep reading.

Gradle DSL reference

PodPlay’s Gradle files are in a Groovy-based DSL. Groovy is a Java scripting language and DSL stands for Domain-Specific Language. You may find other apps have Kotlin based Gradle files. Either way, the configurations are similar.

Release build type

It’s important to understand release type because it’s the version you’ll upload to the Google Play Store. Choose the release variant in the Build Variants Panel, and wait for the Gradle sync to finish.

Creating a release certificate (Optional)

Before doing this let’s review how to create the certificates for signing a release build as you learned in previous chapters.

Fixing the release build problem

Now try to run the app again with the Run button at the top of Android Studio, with the release version selected. You’ll still see the app version in the top bar has a small red x sign next to it:

Key points

  • Build variants are a compound output of build types and build flavors.
  • Build types take care of your app’s Gradle configurations.
  • You can create as many build types as your app needs.
  • Most Gradle files are in a Groovy Based DSL, but some are written in Kotlin.
  • The release build type requires a signing configuration that includes the release certificates.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.

© 2022 Razeware LLC

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.