Why Android SDK and API levels in Android Kotlin? - Purpose & Use Cases

The Big Idea

What if your app could magically work on every Android phone without extra effort?

The Scenario

Imagine you want to build an Android app that works on many phones, but each phone has a different Android version. You try to write separate code for each version manually.

The Problem

Writing and managing different code for every Android version is slow and confusing. It's easy to make mistakes, and your app might crash on some phones because you forgot a version check.

The Solution

Android SDK and API levels help you handle different Android versions smoothly. They let you write code that works on many devices by checking the version and using the right features automatically.

Before vs After

✗ Before

if (androidVersion == 21) { useFeatureA() } else if (androidVersion == 22) { useFeatureB() }

✓ After

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { useFeatureA() }

What It Enables

You can build apps that run well on many Android devices without writing messy, error-prone code for each version.

Real Life Example

When you install a popular app, it works on your old phone and your friend's new phone because the app uses SDK and API levels to adapt automatically.

Key Takeaways

Android SDK and API levels manage differences between Android versions.

They prevent crashes by letting your app check the device's Android version.

This makes your app reliable and easier to maintain.

Practice

1. What does the minSdk version specify in an Android app?

easy

A. The latest Android version available

B. The Android version you compile your app against

C. The Android version your app is optimized for

D. The oldest Android version your app can run on

Solution

1. Step 1: Understand minSdk meaning

   minSdk defines the minimum Android version that can run the app.

2. Step 2: Differentiate from other SDK versions

   compileSdk is for building, targetSdk is optimization, but minSdk is the oldest supported version.

3. Final Answer:

   The oldest Android version your app can run on -> Option D

4. Quick Check:

   minSdk = oldest supported version [OK]

Hint: minSdk means minimum Android version supported [OK]

Common Mistakes:

• Confusing minSdk with compileSdk
• Thinking minSdk is the target optimization version
• Assuming minSdk is the latest Android version

2. Which of the following is the correct way to set the compileSdk version to 33 in a Kotlin DSL Gradle file?

easy

A. compileSdkVersion 33

B. compileSdkVersion = 33

C. compileSdk = 33

D. compileSdk(33)

Solution

1. Step 1: Identify Kotlin DSL syntax for compileSdk

   In Kotlin DSL, compileSdk is assigned directly with =.

2. Step 2: Compare options

   compileSdkVersion 33 is Groovy syntax without assignment, compileSdkVersion = 33 uses the wrong property name, and compileSdk(33) is invalid function call syntax. Only compileSdk = 33 is correct.

3. Final Answer:

   compileSdk = 33 -> Option C

4. Quick Check:

   Kotlin DSL uses compileSdk = 33 [OK]

Hint: Kotlin DSL uses equals sign for assignments [OK]

Common Mistakes:

• Using Groovy syntax in Kotlin DSL
• Omitting equals sign
• Using method call syntax incorrectly

3. Given this Gradle configuration snippet:

android {
  compileSdk = 31
  minSdk = 21
  targetSdk = 30
}

What is the highest Android version your app is optimized for?

medium

A. 30

B. 21

C. 31

D. Cannot determine from this

Solution

1. Step 1: Identify meaning of targetSdk

   targetSdk is the Android version the app is optimized for and tested against.

2. Step 2: Check given values

   Here, targetSdk is 30, so the app is optimized for Android 30.

3. Final Answer:

   30 -> Option A

4. Quick Check:

   targetSdk = 30 means optimized for Android 30 [OK]

Hint: targetSdk shows optimization version, not compileSdk [OK]

Common Mistakes:

• Confusing compileSdk with targetSdk
• Thinking minSdk is optimization version
• Choosing compileSdk as optimization version

4. You set minSdk = 30 but want your app to run on Android 21 devices. What is the problem in this Gradle config?

android {
  compileSdk = 33
  minSdk = 30
  targetSdk = 33
}

medium

A. compileSdk must be lower than minSdk

B. minSdk is too high, app won't run on Android 21

C. targetSdk must be equal to minSdk

D. No problem, app runs on all versions

Solution

1. Step 1: Understand minSdk role

   minSdk sets the lowest Android version the app supports.

2. Step 2: Check compatibility with Android 21

   Since minSdk is 30, devices with Android 21 cannot run the app.

3. Final Answer:

   minSdk is too high, app won't run on Android 21 -> Option B

4. Quick Check:

   minSdk = 30 excludes Android 21 devices [OK]

Hint: minSdk must be ≤ lowest Android version supported [OK]

Common Mistakes:

• Thinking compileSdk affects device compatibility
• Assuming targetSdk limits device support
• Believing app runs on all versions regardless of minSdk

5. You want to use a new Android feature introduced in API level 31 but still support devices running API level 21. How should you configure your Gradle file to safely use this feature?

hard

A. Set minSdk = 21, targetSdk = 31, and use runtime checks for API 31 features

B. Set minSdk = 21 and targetSdk = 21

C. Set minSdk = 31 and targetSdk = 31

D. Set compileSdk = 21 and minSdk = 31

Solution

1. Step 1: Understand minSdk and targetSdk roles

   minSdk is the oldest supported version; targetSdk is the optimized version.

2. Step 2: Use runtime checks for new features

   To support API 21 devices but use API 31 features, keep minSdk = 21, set targetSdk = 31, and check API level at runtime before using new features.

3. Step 3: Evaluate options

   Set minSdk = 21, targetSdk = 31, and use runtime checks for API 31 features correctly sets minSdk and targetSdk and mentions runtime checks. Others either restrict support or use wrong compileSdk.

4. Final Answer:

   Set minSdk = 21, targetSdk = 31, and use runtime checks for API 31 features -> Option A

5. Quick Check:

   minSdk low + targetSdk high + runtime checks = safe feature use [OK]

Hint: Use runtime API checks to support older devices safely [OK]

Common Mistakes:

• Raising minSdk and losing older device support
• Not using runtime checks for new APIs
• Setting compileSdk lower than targetSdk