minSdkVersion: what it is and how to choose the minimum Android version

What is minSdkVersion in Android?

minSdkVersion is an integer parameter in build.gradle that specifies the minimum Android API Level for app installation. If the device's API Level is below the specified value, the PackageManager blocks installation, and Google Play Store hides the app from search results for that device. minSdkVersion is written into AndroidManifest.xml at build time via the <uses-sdk android:minSdkVersion> tag and is checked on every installation.

The minSdkVersion value is a trade-off between audience reach and access to new APIs. The lower the minSdk, the more devices can install the app, especially in developing regions where older Android smartphones are popular. The higher the minSdk, the less backward compatibility code is required and the more modern APIs are available without runtime checks. Android Jetpack and AndroidX libraries provide backports of many new APIs to older Android versions, allowing you to choose a lower minSdk without losing functionality.

minSdkVersion affects all development stages: static analysis (lint uses minSdk for warnings), dependency compatibility (libraries may require their own minSdk), testing (you need to test on devices with minSdk), and Google Play Console (audience reach is calculated based on minSdk). Changing minSdkVersion is one of the most important decisions in project setup, as it affects code, tests, and the user base.

Where minSdkVersion is specified

Build.gradle.kts (Kotlin DSL) is the modern standard in Android projects. The minSdk parameter is set in the defaultConfig block at the module level. The value can be overridden for different build types and product flavors, allowing testing on lower APIs without changing the main value.

// build.gradle.kts — basic minSdk configuration
android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26      // Android 8.0 Oreo
        targetSdk = 36
        versionCode = 1
        versionName = "1.0.0"
    }

    // Overriding minSdk for different flavors
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

In the example, minSdk = 26 corresponds to Android 8.0 Oreo. This is a popular value in 2026: it cuts off only ~15% of devices according to the Android Studio Distribution Dashboard. compileSdk = 36 provides access to all Android 16 APIs, and targetSdk = 36 includes the behavioral changes of the latest version. For debug builds, minSdk can be lowered for testing on older emulators.

How to Choose minSdkVersion: Factors and Strategy

Choosing minSdkVersion is a strategic decision based on analyzing the target audience, API requirements, and library ecosystem. There is no single correct value for all projects. In 2026, Android Studio recommends minSdk = 26 (Android 8.0) as the baseline for new projects, but for B2B applications or enterprise solutions, lower or higher values may be acceptable.

Factors for choosing minSdkVersion

The first factor is the Distribution Dashboard. Android Studio provides active device statistics by API Level based on Google Play data, updated monthly. minSdkVersion should cover at least 90-95% of active devices on the target market. For international apps with audiences in Africa and Southeast Asia, minSdk should be lowered to 21 (Android 5.0) due to the high share of older devices.

The second factor is dependency requirements. Each library has its own minSdkVersion specified in its manifest. If a library requires minSdk 29 and the app requires minSdk 26, the build will fail with a manifest merger error. Modern Google Play Services libraries have minSdk 21, Firebase has minSdk 21, most Jetpack libraries have minSdk 21 or 26, and Compose BOM has minSdk 21. For Compose, the minimum threshold is API 21.

The third factor is required APIs. If key app functionality requires an API only available from a certain level (e.g., PhotoPicker — API 34, Predicted Navigation — API 35), this may justify raising minSdk. However, a combination of AndroidX backports (Activity Result API, NotificationCompat) and runtime checks is more often used to keep a low minSdk.

Step-by-step selection strategy

Step 1: open Android Studio, File → New Project, and check the recommended minSdk in the wizard. Step 2: check the Distribution Dashboard in Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Step 3: analyze project dependencies — run the build and fix manifest merger conflicts. Step 4: evaluate which API level X features are actually used without backports. Step 5: set minSdk to the minimum value covering 90%+ of the target audience and compatible with all dependencies.

Device Coverage: API Level Distribution (2026)

Device distribution by API Level is a dynamic metric that changes every quarter. According to the Android Studio Distribution Dashboard as of June 2026, about 85% of active Android devices run on API 26 (Android 8.0) and above, 72% on API 29 (Android 10) and above, and 55% on API 31 (Android 12) and above. The Chinese market has its own statistics due to the absence of Google Play Services on many Huawei devices.

GMS devices (Google Mobile Services) update faster: the share of API 31+ on them reaches 68% thanks to Google Play's mandatory requirements for manufacturers. Non-GMS devices (Huawei, Honor, some Chinese brands) have an older distribution: the share of API 31+ on them is about 35%. If your app targets the international market, rely on global statistics. If it targets China, consider the non-GMS segment.

Conclusion: for an international app, minSdk 26 covers 85% of devices with minimal backward compatibility costs. For apps with audiences in developing regions, minSdk 21 (97% coverage) is justified but will require more code for working with legacy APIs. For Enterprise apps with a controlled device fleet, you can set minSdk 31 and completely eliminate fallback code.

Backward Compatibility: AndroidX, lint and @RequiresApi

Backward compatibility is the main challenge with a low minSdkVersion. AndroidX (formerly Support Library) provides backports of modern APIs to older Android versions: AppCompatActivity for Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat, and dozens of other components. Using AndroidX equivalents instead of native APIs is the first step toward compatibility.

lint (Android Studio's static analyzer) scans code for API calls above minSdkVersion. If a method is annotated with @RequiresApi at an API Level higher than minSdk and is called without a check, lint highlights an error. To suppress the warning, use the @SuppressLint("NewApi") annotation on the method or @RequiresApi(Build.VERSION_CODES.TIRAMISU) on the entire function. Runtime checks via Build.VERSION.SDK_INT are the main mechanism for safely calling new APIs on older devices.

// Backward compatibility example: PhotoPicker (API 34+) and fallback
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import androidx.activity.result.contract.ActivityResultContracts
import androidx.appcompat.app.AppCompatActivity

class ImagePickerActivity : AppCompatActivity() {

    // Activity Result API (AndroidX) — works on any API Level
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker is only available from API 34
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // Using PhotoPicker (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Fallback: GetContent (works on all versions)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // This method cannot be called on API < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

The ImagePickerActivity class demonstrates three levels of backward compatibility. Activity Result API from AndroidX works at all API levels, so the base image selection does not depend on minSdk. PhotoPicker (ACTION_PICK_IMAGES) is only available from API 34 and is called under an SDK_INT check with a fallback to GetContent. The usePhotoPickerOnly method is marked with @RequiresApi — lint will not allow calling it without a check. AppCompat from AndroidX automatically adapts the theme, fragments, and animations to the OS version.

minSdkVersion in Libraries and Modules

Libraries (AAR, JAR) also have a minSdkVersion specified in their manifest. When connecting a library, Gradle checks compatibility: if the library's minSdk is higher than the app's minSdk, the build fails with an error. For public libraries, it is recommended to specify the lowest possible minSdk (21 for most cases) so as not to limit consumers. If a library requires API 29+, it loses ~28% of potential users.

Multi-module projects can have different minSdkVersion values for different modules. For example, the :core:network module may have minSdk 26, while the :feature:camera module may have minSdk 29 (due to CameraX with specific requirements). Google Play requires that the minSdk of the main :app module be lower than or equal to the minSdk of all dependent modules. In practice, all modules of a single app usually have the same minSdk for easier maintenance.

// build.gradle.kts — library module with low minSdk
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.mylibrary"
    compileSdk = 36

    defaultConfig {
        minSdk = 21  // Minimum for maximum coverage
        targetSdk = 36
    }
}

dependencies {
    // AndroidX Core — minSdk 21, adds backports
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

A library module with minSdk = 21 is compatible with 97% of devices and does not limit consumers. If the library uses APIs above 21, the developer must add runtime checks or specify @RequiresApi on the relevant methods. AndroidX Core KTX (minSdk 21) provides backports for Context, Bundle, Locale, and other system classes, allowing the library to keep a low minSdk.

Common Mistakes When Choosing minSdkVersion

Mistakes when choosing minSdk can cost thousands of installations or weeks of additional development. The first common mistake is copying minSdk from a project template without analyzing the Distribution Dashboard. Many developers leave minSdk = 21 from the Android Studio Template, even though minSdk 26 would be sufficient for their audience and would reduce the number of SDK_INT checks in the code.

The second mistake is too high a minSdk without considering the market. If you set minSdk = 31 (Android 12) for an international app, you lose ~45% of devices. For a startup or a mass-audience app, this is a disaster. Always check the Distribution Dashboard before raising minSdk and use A/B testing in Google Play Console if you are unsure.

The third mistake is ignoring dependency minSdk. When adding a new library, check its minSdk in the documentation or POM file. Firebase ML Kit requires minSdk 21, some custom camera libraries require minSdk 29. If manifest merger fails in production due to a new library, fixing it can take days.

// Example: runtime API compatibility check
fun checkFeatureAvailability(): Boolean {
    // Typical mistake — calling an API without checking SDK_INT
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — use PhotoPicker
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — use MediaStore
            true
        }
        else -> {
            // API < 29 — use ACTION_GET_CONTENT
            true
        }
    }
}

The correct architecture for API Level checks is a when expression with ranges covering all possible values from minSdk to compileSdk. The key rule: any call to an API of level X must be protected by a VERSION.SDK_INT check for all devices with API Level from minSdk to X. lint helps detect unchecked calls, but cannot guarantee full coverage for dynamic code.