Chapters
Chapters

Chapters

Hide chapters

Android App Distribution

First Edition · Android 12 · Kotlin 1.5 · Android Studio Bumblebee

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: App Store Quick Start

Section 1: 4 chapters
Show chapters Hide chapters

Section II: Security & Optimization

Section 2: 6 chapters
Show chapters Hide chapters

Section III: Automation: Continuous Integration & Delivery

Section 3: 2 chapters
Show chapters Hide chapters

Section IV: Beyond Publication

Section 4: 3 chapters
Show chapters Hide chapters

10. Publishing in the Real World
Written by Evana Margain Puig

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous chapter, you learned about build types, the first step in creating build variants. You also learned that build flavors are the second group of components you need to create a build variant.

This chapter will teach you all about build flavors. They’ll help you manage different versions of your app without having separate code bases.

We call this chapter “Publishing in the Real World” because most developers build different versions of their apps through build flavors.

What can you do with flavors?

Flavors let you add different resources, assets or items to your app while still using the project’s core functionality. You can have the same app using the same code but with a different look and feel.

In the past, you may have copied all of your code into a separate repo and changed the assets. You don’t need to do that when you have flavors. Flavors give you the advantage of a single code base and let you apply bug fixes in a single app without synchronizing all versions.

In the previous chapter, you saw some use cases for flavors. If you need to refresh your memory, here they are again:

  • Having separate free and paid versions of your app, where the free version makes certain parts available to the user but restricts others.
  • Having a version for each store you upload to. Such stores include Amazon Appstore, Google Play Store and Samsung Galaxy Store. Each store has different requirements for how your assets should look, the app’s size and items you may need to attach on compile time. With different flavors, you can follow each store’s requirements.
  • Using the same app for different products but customizing the assets to change the app’s look and feel. For example, you may have two companies that sell items. You can have a single app that sells products but customize it with each company’s products and brand.
  • ‘White labeling’ is a common practice related to the previous example. With white labeling, you have a base app without any brand labels and can customize it as you want.
  • Distributing apps across different countries. Certain parts of your content may not be approved or apply to customers in certain regions. You can customize what they see or don’t see based on their specific region.

Flavors are a powerful tool. However, they may add more complexity and build time, so you should keep them focused and targeted.

Default Config and flavors

In the last chapter, you learned which properties build types support. Build flavors also support specific properties. The Default Config contains those properties. You’ll find the Default Config in your apps’ build.gradle like this:

defaultConfig {
  applicationId "com.raywenderlich.podplay"
  minSdkVersion 23
  targetSdkVersion 30
  versionCode 1
  versionName "1.0"
  testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}

Creating flavors

You’re probably reading this chapter to learn how to implement flavors. So, dive right in!

Flavor dimensions

The first thing you need to add when creating a flavor is a flavor dimension. Dimensions are a way to group flavors. Look at the examples you saw earlier in this chapter and develop names you’d give each group.

Build flavor example

Now that you know you need a flavor dimension to create flavors in your app, it’s time to put this into practice. You’ll follow the pricing example and create a ‘demo’ flavor and a ‘full’ flavor.

Demo vs full version

Open PodPlay in Android Studio. In the Navigation panel’s Android view, navigate to Gradle Scripts ▸ build.gradle(Module: PodPlay.app).

flavorDimensions "version_type"

productFlavors {
  free {
    dimension "version_type"
    applicationIdSuffix ".free"
    versionNameSuffix "-free"
  }
  full {
    dimension "version_type"
    applicationIdSuffix ".full"
    versionNameSuffix "-full"
  }
}

Switching between versions

In the previous chapter, you learned Android Studio has a Build Variants panel. Usually, you can find it at the bottom left of your screen as a closed tab. If you tap it, the panel displays.

Adding a second flavor dimension

As you add build flavors and build types, Android Studio creates combinations called build variants. You can create a more complex structure by adding multiple flavor dimensions.

flavorDimensions "version_type", "store"

productFlavors {
  google {
    dimension "store"
    applicationIdSuffix ".google"
    versionNameSuffix "-google"
  }
  amazon {
    dimension "store"
    applicationIdSuffix ".amazon"
    versionNameSuffix "-amazon"
  }
}

Variant filters

Now that you have so many variants, you may notice some are part of the resulting combinations you don’t need. Imagine you don’t want to upload the free version of your app to the Amazon store. Variant filters let you use filters to exclude build variants that meet certain conditions.

variantFilter { variant ->
  def names = variant.flavors*.name
  if (names.contains("free") && names.contains("amazon")) {
    setIgnore(true)
  }
}

Common build flavor properties for configuring

Earlier, you created some flavor dimensions and added a basic configuration. You learned about applicationIdSuffix and versionNameSuffix, but there are more properties. In this section, you’ll review the most common ones.

Signing configs

As you learned in earlier chapters, any version you upload to a store, like the Google Play Store, will need signing for security and identifying your app.

signingConfigs {
  amazon_release {
      storeFile file("myreleasekey.keystore")
      storePassword "password"
      keyAlias "MyReleaseKey"
      keyPassword "password"
  }
}

amazon {
  ...
  signingConfig signingConfigs.amazon_release
}

Build config fields

Build variants have another powerful property: buildConfigField. It’s a property that lets you create static constants available at runtime. The values you put there usually flag your app content. Take a look at an example.

buildConfigField "boolean", "IS_PRODUCTION", "false"

Creating source sets for different variants

Build variants let you customize each variant’s assets.

Manually creating folders for specific build variants

To create specific files that are only available for one build variant, you can create another folder at the same level as main. Test it out by creating a new folder named ‘debug’.

Using Android Studio to create folders for specific build variants

Of course, Android Studio wouldn’t leave you hanging without a tool for this process. Right-click Project’s src. Then select New ▸ Folder ▸ Java Folder.

Creating files to target a build variant with Android Studio

You can also create these folders by creating a file that targets one of your build variants and letting Android Studio handle folder creation.

Key points

  • Build variants are the combination of build types and build flavors
  • Use build flavors to customize various versions of the same code where you get separate builds that share code but have key differences.
  • You need to specify an applicationId or applicationIdSuffix for each flavor you create because two apps can’t have the same application id when uploaded to any store.
  • You need to assign each flavor to a flavor dimension.
  • You create build flavors in your Gradle files, similar to how you create build variants. Each has its purpose.
  • Use variant filters to avoid a clutter of build flavors and build types that you won’t use.
  • You can add any assets or classes to a specific build variant by navigating to Android Studio’s Project view, creating a folder with the same name as the targeted variant and placing a Java file inside.
9. Build Variants: Implementing Build Types
11. Automation Tools for Your Local Environment
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.
© 2024 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now