Build variants (debug, release) in Android Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a build variant in Android development?

A build variant is a combination of a build type and a product flavor that defines how the app is built and packaged. It lets you create different versions of your app, like debug and release.

beginner

What is the main difference between debug and release build types?

The debug build is for testing and includes debugging tools and logs. The release build is optimized, signed, and ready for publishing to users.

intermediate

Why do we use signingConfigs in the release build?

Signing configs provide the digital signature needed to verify the app's identity when publishing. Release builds must be signed to be accepted by app stores.

intermediate

How can you customize the app behavior for debug and release builds?

You can use BuildConfig.DEBUG in code to check if the app is running a debug build and change behavior like enabling logs or test features.

beginner

What Gradle file section defines build types like debug and release?

The android { buildTypes { ... } } block in the build.gradle file defines build types and their settings.

Which build variant is typically used for testing with debugging tools enabled?

A debug

B release

C production

D staging

The debug build variant includes debugging tools and is used for testing.

What must a release build have to be accepted by the Google Play Store?

A Debug logs enabled

B Unoptimized code

C Extra test code

D Signed with a release key

Release builds must be signed with a release key to verify the app's identity.

Where do you define build types like debug and release in an Android project?

A build.gradle (Module)

B settings.gradle

C AndroidManifest.xml

D proguard-rules.pro

Build types are defined in the module-level build.gradle file inside the android block.

Which code snippet checks if the app is running a debug build?

A BuildType.RELEASE

B BuildVariant.DEBUG

C BuildConfig.DEBUG

D BuildConfig.RELEASE

BuildConfig.DEBUG is a boolean that is true for debug builds.

What is a common use of the debug build variant?

A Publishing to app stores

B Testing and debugging

C Optimizing performance

D Signing with release keys

Debug builds are used for testing and debugging during development.

Explain the purpose of build variants in Android and how debug and release builds differ.

Think about why you need different versions of your app during development and publishing.

Describe how you can customize app behavior based on the build variant in Kotlin code.

Consider how your app might behave differently when testing versus when users install it.

Practice

1. What is the main purpose of the debug build variant in Android development?

easy

A. To publish the app on the Play Store

B. To test the app with debugging tools enabled

C. To reduce the app size for faster downloads

D. To disable all logging and debugging features

Solution

1. Step 1: Understand build variant roles

   The debug variant is designed for developers to test and debug the app during development.

2. Step 2: Compare with release variant

   The release variant is optimized and signed for publishing, unlike debug.

3. Final Answer:

   To test the app with debugging tools enabled -> Option B

4. Quick Check:

   Debug variant = testing with debugging [OK]

Hint: Debug variant is for testing, release is for publishing [OK]

Common Mistakes:

• Confusing debug with release variant
• Thinking debug is for publishing
• Assuming debug disables logging

2. Which of the following is the correct way to specify a release build variant in the build.gradle file?

easy

A. buildVariants { debug { minifyEnabled false } }

B. buildVariants { release { minifyEnabled true } }

C. buildTypes { release { minifyEnabled false } }

D. buildTypes { debug { minifyEnabled true } }

Solution

1. Step 1: Identify correct block name

   The correct block to define build variants is buildTypes, not buildVariants.

2. Step 2: Check release variant syntax

   Inside buildTypes, release can have minifyEnabled set to true or false. buildTypes { release { minifyEnabled false } } uses correct syntax with minifyEnabled false.

3. Final Answer:

   buildTypes { release { minifyEnabled false } } -> Option C

4. Quick Check:

   Use buildTypes block for release variant [OK]

Hint: Use buildTypes, not buildVariants, to define release [OK]

Common Mistakes:

• Using buildVariants instead of buildTypes
• Mixing debug and release settings
• Incorrect minifyEnabled value placement

3. Given this build.gradle snippet, what will be the application ID for the debug build variant?

android {
  defaultConfig {
    applicationId "com.example.app"
  }
  buildTypes {
    debug {
      applicationIdSuffix ".debug"
    }
    release {
      minifyEnabled true
    }
  }
}

medium

A. com.example.app

B. com.example.debug.app

C. com.example.apprelease

D. com.example.app.debug

Solution

1. Step 1: Identify default application ID

   The default application ID is com.example.app from defaultConfig.

2. Step 2: Check debug variant suffix

   The debug build type adds .debug as a suffix to the application ID.

3. Final Answer:

   com.example.app.debug -> Option D

4. Quick Check:

   Debug variant adds suffix .debug [OK]

Hint: Debug adds suffix; release usually does not [OK]

Common Mistakes:

• Ignoring applicationIdSuffix
• Confusing suffix placement
• Assuming release suffix applies to debug

4. You have this build.gradle snippet:

buildTypes {
  release {
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
  }
  debug {
    minifyEnabled true
  }
}

What is the problem with this configuration?

medium

A. minifyEnabled should be false for debug builds to avoid obfuscation

B. proguardFiles cannot be used in release builds

C. minifyEnabled must be true for debug builds

D. The buildTypes block is missing a closing brace

Solution

1. Step 1: Understand minifyEnabled purpose

   Minify (obfuscation) is usually enabled in release builds to shrink and protect code.

2. Step 2: Check debug build settings

   Enabling minify in debug builds is uncommon and can make debugging harder.

3. Final Answer:

   minifyEnabled should be false for debug builds to avoid obfuscation -> Option A

4. Quick Check:

   Debug builds usually disable minify [OK]

Hint: Disable minify in debug to ease debugging [OK]

Common Mistakes:

• Enabling minify in debug builds
• Thinking proguardFiles are invalid in release
• Missing braces in buildTypes block

5. You want to create a new build variant called staging that behaves like release but with a different application ID and no code shrinking. Which build.gradle snippet correctly achieves this?

hard

A. buildTypes {
staging {
initWith release
applicationIdSuffix ".staging"
minifyEnabled false
}
}

B. buildTypes {
staging {
initWith debug
applicationIdSuffix ".staging"
minifyEnabled true
}
}

C. buildTypes {
staging {
applicationIdSuffix ".staging"
minifyEnabled true
}
}

D. buildTypes {
staging {
initWith release
applicationIdSuffix ".release"
minifyEnabled true
}
}

Solution

1. Step 1: Use initWith to copy release settings

   The initWith release copies all release build settings to staging.

2. Step 2: Override applicationIdSuffix and minifyEnabled

   Set applicationIdSuffix ".staging" to differentiate the app ID and minifyEnabled false to disable code shrinking.

3. Final Answer:

   buildTypes { staging { initWith release applicationIdSuffix ".staging" minifyEnabled false } } -> Option A

4. Quick Check:

   initWith release + override suffix and minify [OK]

Hint: Use initWith release, then override needed settings [OK]

Common Mistakes:

• Using initWith debug instead of release
• Forgetting to disable minify for staging
• Using wrong applicationIdSuffix