Introduction

If you need the Android API level of the device currently running your app, the standard answer is Build.VERSION.SDK_INT. That integer tells you which Android API level is available at runtime, so you can gate newer functionality safely.

This matters because Android version names are not enough for code decisions. Runtime compatibility checks should be based on API levels or feature detection.

Use Build.VERSION.SDK_INT

In Kotlin, the usual runtime check looks like this:

1import android.os.Build
2
3val apiLevel = Build.VERSION.SDK_INT
4println("API level: $apiLevel")

In Java, the equivalent is:

1import android.os.Build;
2
3int apiLevel = Build.VERSION.SDK_INT;
4System.out.println("API level: " + apiLevel);

This is the value you compare against Build.VERSION_CODES constants.

Compare Against Named Version Constants

Hard-coding raw numbers works, but named constants are clearer and safer.

1if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
2    println("Android 13 or newer API behavior is available")
3} else {
4    println("Use compatibility path")
5}

This makes the intent obvious when you revisit the code later.

API Level Checks Versus Feature Checks

API level checks are useful when the platform method or behavior truly appeared in a known Android release. But if the question is whether hardware or a service is present, feature detection is often better.

For example, checking camera support or biometric capability should usually rely on the relevant package manager or library API, not only on SDK_INT. The platform version and the actual device capability are related, but they are not identical.

Use API Checks to Guard Code Paths

A common use case is choosing different code paths for newer and older Android versions. That should happen at the point where behavior diverges.

1if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
2    // Use newer notification-channel behavior.
3} else {
4    // Use compatibility behavior for older devices.
5}

Keeping the check close to the version-sensitive code makes maintenance easier than computing the API level once and passing it everywhere.

Runtime API Level Is Not the Same as minSdk or targetSdk

Another source of confusion is mixing runtime API level with build configuration values. minSdk describes the oldest version your app claims to support, and targetSdk describes the platform level you are targeting during development. Neither of those tells you what device version the current user is actually running. For runtime decisions, Build.VERSION.SDK_INT is the value that matters.

That distinction becomes important when debugging device-specific bugs. Two builds with the same targetSdk can still behave differently because they are running on devices with different runtime API levels.

If you log version information in crash reports or analytics, include SDK_INT rather than only the Android marketing version name. The integer is what the code paths actually use.

That makes production debugging easier when behavior differs between devices that look similar to end users.

Common Pitfalls

• Using Android version marketing names instead of SDK_INT in code decisions.
• Hard-coding raw numbers when Build.VERSION_CODES is clearer.
• Using API-level checks where feature detection would be more correct.
• Forgetting that compile-time availability and runtime availability are different issues.
• Reading old examples that use deprecated version fields instead of SDK_INT.

Summary

• Use Build.VERSION.SDK_INT to get the current device API level.
• Compare it against Build.VERSION_CODES when gating version-specific behavior.
• Keep checks close to the code path they protect.
• Prefer feature detection when the real question is device capability rather than platform version.
• Avoid older deprecated version fields in new Android code.