Android SDK and API levels in Android Kotlin - Deep Dive

Overview - Android SDK and API levels

What is it?

The Android SDK (Software Development Kit) is a set of tools and libraries that developers use to build Android apps. API levels are numbers assigned to different versions of Android that help apps know which features and behaviors are available. Each API level corresponds to a specific Android version, so apps can work well on many devices by targeting the right API level.

Why it matters

Without understanding SDK and API levels, apps might crash or behave badly on some devices because they use features not supported there. This system helps developers make apps that work smoothly across many Android versions, reaching more users and avoiding bugs. It also allows Android to grow and improve while keeping older apps working.

Where it fits

Before learning this, you should know basic Android app structure and Kotlin programming. After this, you can learn about app compatibility, feature detection, and how to use new Android features safely in your apps.

Mental Model

Core Idea

Android SDK and API levels are like a language and dictionary version that apps use to speak correctly with different Android devices.

Think of it like...

Imagine you are writing letters to friends who speak different versions of a language. The SDK is your writing toolkit, and the API level is the version of the dictionary you use to make sure your words are understood by each friend.

┌───────────────┐
│ Android SDK   │
│ (Tools + APIs)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ API Levels    │
│ (Android OS   │
│ Versions)     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ App Targets   │
│ (Choose API   │
│ Level to Use) │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

What is Android SDK?

Concept: Introduce the Android SDK as the main toolkit for building Android apps.

The Android SDK is a collection of tools, libraries, and documentation that helps developers create Android apps. It includes things like the Android platform APIs, emulator, debugger, and build tools. Think of it as the toolbox you need to build your app.

Result

You understand that the SDK is essential for app development and contains everything needed to write, test, and package Android apps.

Knowing what the SDK is helps you see how Android apps are built and why you need specific tools to create them.

2

Foundation

Understanding API Levels

Concept: Explain what API levels are and how they relate to Android versions.

API levels are numbers assigned to each Android version. For example, Android 12 is API level 31. These levels tell your app which Android features are available. When you write an app, you pick a minimum API level your app supports and a target API level you optimize for.

Result

You can identify Android versions by their API levels and understand why apps need to know this.

API levels are the language version your app uses to communicate with the Android system, ensuring compatibility.

3

Intermediate

Minimum and Target API Levels

🤔Before reading on: Do you think setting a higher minimum API level means your app runs on fewer devices or more devices? Commit to your answer.

Concept: Learn about the minimum and target API levels and their impact on app compatibility.

The minimum API level is the oldest Android version your app supports. Devices with lower API levels cannot install your app. The target API level is the version your app is tested and optimized for. Setting these helps balance new features and device reach.

Result

You know how to choose API levels to support many devices while using new Android features safely.

Understanding these levels helps you avoid crashes on old devices and take advantage of new Android improvements.

4

Intermediate

Using SDK Tools with API Levels

🤔Before reading on: Do you think the SDK tools change depending on the API level you target? Commit to your answer.

Concept: Explore how SDK tools adapt to different API levels during app development.

When you build an app, the SDK tools check your code against the API level you target. If you use features not available in the minimum API level, the tools warn you. This helps prevent runtime errors on older devices.

Result

You can write code that works across Android versions and fix compatibility issues early.

Knowing how SDK tools enforce API level rules saves time and prevents bugs before your app runs.

5

Advanced

Handling API Level Differences in Code

🤔Before reading on: Do you think you can call new Android features directly on all devices? Commit to your answer.

Concept: Learn how to write code that safely uses features from newer API levels without breaking on older devices.

You can check the device's API level at runtime using code like "if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.XYZ)" before calling new features. This way, your app only uses new features when available, avoiding crashes.

Result

Your app runs smoothly on many devices, using new features when possible and falling back gracefully otherwise.

Understanding runtime API checks is key to building robust apps that work well everywhere.

6

Expert

Impact of API Level on App Behavior

🤔Before reading on: Do you think changing the target API level can change how your app behaves even without code changes? Commit to your answer.

Concept: Discover how the target API level affects app behavior and system interactions beyond just available features.

Android may change system behaviors based on your app's target API level to improve security, privacy, or performance. For example, permission handling or background limits can differ. This means updating your target API level can require code changes to adapt.

Result

You realize that API levels influence app behavior deeply, not just feature availability.

Knowing this helps you prepare for Android updates and maintain app quality over time.

Under the Hood

The Android SDK provides a set of Java/Kotlin libraries compiled against specific API levels. Each API level corresponds to a versioned set of system APIs. When an app runs, the Android system checks the app's declared minimum and target API levels to decide which features and behaviors to enable or restrict. The build tools use this information to compile and package the app accordingly.

Why designed this way?

Android supports many devices with different OS versions. Using API levels allows developers to write apps that work across this diversity by declaring compatibility. This design balances innovation with backward compatibility, letting Android evolve without breaking existing apps.

┌───────────────┐
│ Android System│
│ (Multiple OS  │
│ Versions)     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ App Manifest  │
│ (minSdkVersion│
│ targetSdkVersion)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Runtime Checks│
│ (Enable/Disable│
│ Features)     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ App Behavior  │
│ (Feature Use, │
│ Permissions)  │
└───────────────┘

Myth Busters - 3 Common Misconceptions

Quick: Does setting a high target API level guarantee your app uses all new Android features automatically? Commit yes or no.

Common Belief: If I set a high target API level, my app will automatically use all new Android features.

Reality: Setting a high target API level only allows your app to access new features; you must still write code to use them.

Why it matters: Assuming automatic use leads to missing out on improvements or unexpected app behavior.

Quick: Can an app with a low minimum API level crash on a new Android version because of API level issues? Commit yes or no.

Common Belief: If my app supports old Android versions, it will always work fine on new versions without changes.

Reality: New Android versions may change behaviors based on target API level, so apps might need updates to work well.

Why it matters: Ignoring this can cause crashes or poor user experience on new devices.

Quick: Is the Android SDK a single tool that never changes? Commit yes or no.

Common Belief: The Android SDK is a fixed set of tools that stays the same for all Android versions.

Reality: The SDK updates regularly to include new APIs and tools for each Android version.

Why it matters: Using an outdated SDK can prevent access to new features and cause compatibility problems.

Expert Zone

1

Some system behavior changes triggered by target API level are subtle and affect security or privacy without obvious errors.

2

Backward compatibility libraries (AndroidX) help bridge API level gaps but can add complexity and overhead.

3

Choosing the right minimum API level balances device reach and development effort; too low increases testing complexity.

When NOT to use

Avoid targeting very old API levels if your app needs modern features or security updates. Instead, use AndroidX libraries or consider dropping support for outdated versions to simplify development.

Production Patterns

In production, developers often set minimum API level to cover 90%+ of devices, update target API level regularly to comply with Play Store policies, and use runtime checks to handle feature differences gracefully.

Connections

Semantic Versioning

Both use version numbers to manage compatibility and feature sets.

Understanding how API levels work is similar to how software versions signal compatibility and changes, helping manage expectations and dependencies.

Backward Compatibility in Web Browsers

Both deal with supporting older environments while enabling new features.

Learning about API levels helps grasp how web developers use feature detection and polyfills to support different browsers.

Language Dialects in Linguistics

API levels are like dialects that share core language but differ in features and rules.

Recognizing this connection helps appreciate the complexity of supporting diverse Android versions like understanding language variations.

Common Pitfalls

#1 Setting minimum API level too high without need.

Wrong approach:

minSdkVersion 30

Correct approach:

minSdkVersion 21

Root cause:

Choosing a high minimum API level unnecessarily limits the number of devices that can install the app.

#2 Calling new API features without runtime checks.

Wrong approach:

val manager = getSystemService(NotificationManager::class.java)
manager.createNotificationChannel(channel)

Correct approach:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
val manager = getSystemService(NotificationManager::class.java)
manager.createNotificationChannel(channel)
}

Root cause:

Not checking API level causes crashes on devices that do not support the new feature.

#3 Not updating target API level regularly.

Wrong approach:

targetSdkVersion 28 (years old)

Correct approach:

targetSdkVersion 33 (latest stable)

Root cause:

Old target API levels can cause compatibility issues and prevent app updates on the Play Store.

Key Takeaways

Android SDK is the essential toolkit for building Android apps, containing tools and libraries.

API levels represent Android versions and help apps know which features they can safely use.

Choosing minimum and target API levels balances device compatibility and access to new features.

Runtime API level checks prevent crashes by ensuring new features are only used on supported devices.

Target API level affects app behavior beyond features, so keeping it updated is crucial for app quality.

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