Bird
Raised Fist0
Android Kotlinmobile~10 mins

Build variants (debug, release) in Android Kotlin - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a debug build variant in the Gradle build script.

Android Kotlin
android {
    buildTypes {
        debug {
            isMinifyEnabled = [1]
        }
    }
}
Drag options to blanks, or click blank then click option'
A0
Btrue
Cnull
Dfalse
Attempts:
3 left
💡 Hint
Common Mistakes
Setting isMinifyEnabled to true in debug causes harder debugging.
Using null or 0 instead of a boolean value.
2fill in blank
medium

Complete the code to define a release build variant with code shrinking enabled.

Android Kotlin
android {
    buildTypes {
        release {
            isMinifyEnabled = [1]
        }
    }
}
Drag options to blanks, or click blank then click option'
Afalse
Btrue
Cnull
D0
Attempts:
3 left
💡 Hint
Common Mistakes
Setting isMinifyEnabled to false in release reduces optimization.
Using null or 0 instead of a boolean value.
3fill in blank
hard

Fix the error in the release build variant to enable ProGuard rules.

Android Kotlin
android {
    buildTypes {
        release {
            proguardFiles(getDefaultProguardFile([1]), "proguard-rules.pro")
        }
    }
}
Drag options to blanks, or click blank then click option'
A"proguard-android-optimize.txt"
B"proguard-android.txt"
C"proguard-android-debug.txt"
D"proguard-android-release.txt"
Attempts:
3 left
💡 Hint
Common Mistakes
Using debug or non-optimized ProGuard files in release builds.
Missing quotes around the file name.
4fill in blank
hard

Fill both blanks to define a build variant with signing config and minification.

Android Kotlin
android {
    buildTypes {
        release {
            signingConfig = [1]
            isMinifyEnabled = [2]
        }
    }
}
Drag options to blanks, or click blank then click option'
AsigningConfigs.release
BsigningConfigs.debug
Ctrue
Dfalse
Attempts:
3 left
💡 Hint
Common Mistakes
Using debug signing config for release builds.
Disabling minification in release builds.
5fill in blank
hard

Fill all three blanks to define a debug build variant with applicationIdSuffix and debuggable flag.

Android Kotlin
android {
    buildTypes {
        debug {
            applicationIdSuffix = [1]
            isDebuggable = [2]
            versionNameSuffix = [3]
        }
    }
}
Drag options to blanks, or click blank then click option'
A".debug"
Btrue
C"-DEBUG"
Dfalse
Attempts:
3 left
💡 Hint
Common Mistakes
Using false for isDebuggable in debug builds.
Omitting suffixes for debug builds.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard