minSdkVersion: wat is het, hoe kies je de minimale Android-versie

Wat is minSdkVersion in Android?

minSdkVersion — een integer parameter in build.gradle die het minimale Android API-niveau voor app-installatie instelt. Als het API-niveau van het apparaat lager is dan de opgegeven waarde, blokkeert PackageManager de installatie en verbergt Google Play Store de app in zoekresultaten voor een dergelijk apparaat. minSdkVersion wordt in de buildfase naar AndroidManifest.xml geschreven via de tag <uses-sdk android:minSdkVersion> en wordt bij elke installatie gecontroleerd.

De waarde van minSdkVersion is een compromis tussen het bereik van het publiek en toegang tot nieuwe API's. Hoe lager minSdk, hoe meer apparaten de app kunnen installeren, vooral in ontwikkelingsregio's waar oude Android-smartphones populair zijn. Hoe hoger minSdk, hoe minder achterwaartse compatibiliteitscode nodig is en hoe meer moderne API's beschikbaar zijn zonder runtime-controles. Android Jetpack en AndroidX-bibliotheken bieden backports van veel nieuwe API's naar oude Android-versies, waardoor je een lagere minSdk kunt kiezen zonder functionaliteit te verliezen.

minSdkVersion beïnvloedt alle ontwikkelingsfasen: statische analyse (lint gebruikt minSdk voor waarschuwingen), compatibiliteit van afhankelijkheden (bibliotheken kunnen hun eigen minSdk vereisen), testen (moet worden getest op apparaten met minSdk) en Google Play Console (publieksbereik wordt berekend op basis van minSdk). Het wijzigen van minSdkVersion is een van de meest verantwoordelijke beslissingen bij het configureren van een project, omdat het van invloed is op code, tests en gebruikersbasis.

Waar wordt minSdkVersion opgegeven

Build.gradle.kts (Kotlin DSL) — de moderne standaard in Android-projecten. De parameter minSdk wordt ingesteld in het blok defaultConfig op moduleniveau. De waarde kan worden overschreven voor verschillende buildtypes en productflavors, waardoor je op lagere API's kunt testen zonder de hoofdwaarde te wijzigen.

// build.gradle.kts — basisconfiguratie van minSdk
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"
    }

    // Overschrijven van minSdk voor verschillende flavors
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

In het voorbeeld komt minSdk = 26 overeen met Android 8.0 Oreo. Dit is een populaire waarde in 2026: volgens Android Studio Distribution Dashboard worden slechts ~15% van de apparaten uitgesloten. compileSdk = 36 geeft toegang tot alle API's van Android 16 en targetSdk = 36 activeert de gedragsveranderingen van de nieuwste versie. Voor debug-builds kan minSdk worden verlaagd om op oude emulators te testen.

Hoe kies je minSdkVersion: factoren en strategie

Het kiezen van minSdkVersion — een strategische beslissing op basis van analyse van de doelgroep, API-vereisten en het ecosysteem van bibliotheken. Er is geen enkele juiste waarde voor alle projecten. In 2026 beveelt Android Studio minSdk = 26 (Android 8.0) aan als basisniveau voor nieuwe projecten, maar voor B2B-apps of bedrijfsoplossingen zijn lagere of hogere waarden acceptabel.

Factoren voor het kiezen van minSdkVersion

De eerste factor — Distribution Dashboard. Android Studio biedt maandelijks bijgewerkte statistieken van actieve apparaten per API-niveau op basis van Google Play-gegevens. minSdkVersion moet ten minste 90-95% van de actieve apparaten op de doelmarkt dekken. Voor internationale apps met publiek in Afrika en Zuidoost-Azië moet minSdk worden verlaagd naar 21 (Android 5.0) vanwege het hoge aandeel oude apparaten.

De tweede factor — afhankelijkheidsvereisten. Elke bibliotheek heeft zijn eigen minSdkVersion vermeld in zijn manifest. Als een bibliotheek minSdk 29 vereist en de app — minSdk 26, mislukt de build met een manifest merger-fout. Moderne Google Play Services-bibliotheken hebben minSdk 21, Firebase — minSdk 21, de meeste Jetpack-bibliotheken — minSdk 21 of 26, Compose BOM — minSdk 21. Voor Compose is de minimale drempel — API 21.

De derde factor — vereiste API's. Als de kernfunctionaliteit van de app een API vereist die alleen beschikbaar is vanaf een bepaald niveau (bijv. PhotoPicker — API 34, Predicted Navigation — API 35), kan dit het verhogen van minSdk rechtvaardigen. Vaker wordt echter een combinatie van AndroidX-backports (Activity Result API, NotificationCompat) en runtime-controles gebruikt om een lage minSdk te behouden.

Stapsgewijze keuzestrategie

Stap 1: open Android Studio, File → New Project en bekijk de aanbevolen minSdk in de wizard. Stap 2: controleer het Distribution Dashboard in Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Stap 3: analyseer de afhankelijkheden van het project — voer de build uit en los manifest merger-conflicten op. Stap 4: beoordeel welke API's van niveau X daadwerkelijk zonder backports worden gebruikt. Stap 5: stel minSdk in als de minimale waarde die 90%+ van de doelgroep dekt en compatibel is met alle afhankelijkheden.

Apparaatdekking: verdeling van API-niveaus (2026)

Apparaatverdeling per API-niveau — een dynamische indicator die elk kwartaal verandert. Volgens Android Studio Distribution Dashboard voor juni 2026 draait ongeveer 85% van de actieve Android-apparaten op API 26 (Android 8.0) en hoger, 72% — op API 29 (Android 10) en hoger, 55% — op API 31 (Android 12) en hoger. De Chinese markt heeft zijn eigen statistiek vanwege het ontbreken van Google Play Services op veel Huawei-apparaten.

GMS-apparaten (Google Mobile Services) worden sneller bijgewerkt: het aandeel API 31+ bereikt daar 68% dankzij de verplichte Google Play-vereisten voor fabrikanten. Non-GMS-apparaten (Huawei, Honor, sommige Chinese merken) hebben een oudere verdeling: het aandeel API 31+ is daar ongeveer 35%. Als de app gericht is op de internationale markt, baseer je dan op wereldwijde statistieken. Als op de Chinese markt — houd dan rekening met het non-GMS-segment.

Conclusie: voor een internationale app dekt minSdk 26 85% van de apparaten met minimale kosten voor achterwaartse compatibiliteit. Voor apps met publiek in ontwikkelingsregio's is minSdk 21 (97% dekking) gerechtvaardigd, maar vereist meer code om met verouderde API's te werken. Voor Enterprise-apps met een gecontroleerd apparaatpark kun je minSdk 31 instellen en volledig van fallback-code afkomen.

Achterwaartse compatibiliteit: AndroidX, lint en @RequiresApi

Achterwaartse compatibiliteit — de belangrijkste moeilijkheid bij een lage minSdkVersion. AndroidX (voorheen Support Library) biedt backports van moderne API's naar oude Android-versies: AppCompatActivity voor Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat en tientallen andere componenten. Het gebruik van AndroidX-equivalenten in plaats van native API's — de eerste stap naar compatibiliteit.

lint (statische analyser van Android Studio) scant code op aanroepen van API's boven minSdkVersion. Als een methode is gemarkeerd met @RequiresApi met een API-niveau hoger dan minSdk en wordt aangeroepen zonder controle, markeert lint de fout. Om de waarschuwing te onderdrukken, gebruik je de annotatie @SuppressLint("NewApi") op de methode of @RequiresApi(Build.VERSION_CODES.TIRAMISU) op de hele functie. Runtime-controles via Build.VERSION.SDK_INT — het primaire mechanisme voor veilige aanroep van nieuwe API's op oude apparaten.

// Voorbeeld van achterwaartse compatibiliteit: PhotoPicker (API 34+) en 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) — werkt op elk API-niveau
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker alleen beschikbaar vanaf API 34
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // We gebruiken PhotoPicker (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Fallback: GetContent (werkt op alle versies)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // Deze methode kan niet worden aangeroepen op API < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

De klasse ImagePickerActivity toont drie niveaus van achterwaartse compatibiliteit. Activity Result API van AndroidX werkt op alle API-niveaus, dus voor basisbeeldselectie maakt minSdk niet uit. PhotoPicker (ACTION_PICK_IMAGES) is alleen beschikbaar vanaf API 34 en wordt aangeroepen onder SDK_INT-controle met fallback naar GetContent. De methode usePhotoPickerOnly is gemarkeerd met @RequiresApi — lint staat niet toe deze zonder controle aan te roepen. AppCompat van AndroidX past automatisch het thema, fragmenten en animaties aan de OS-versie aan.

minSdkVersion in bibliotheken en modules

Bibliotheken (AAR, JAR) hebben ook minSdkVersion vermeld in hun manifest. Bij het aansluiten van een bibliotheek controleert Gradle de compatibiliteit: als de minSdk van de bibliotheek hoger is dan de minSdk van de app, mislukt de build met een fout. Voor openbare bibliotheken wordt aanbevolen de laagst mogelijke minSdk (21 in de meeste gevallen) op te geven om consumenten niet te beperken. Als een bibliotheek API 29+ vereist, verliest deze ~28% van de potentiële gebruikers.

Multi-module projecten kunnen verschillende minSdkVersion hebben voor verschillende modules. Bijvoorbeeld, de module :core:network kan minSdk 26 hebben en de module :feature:camera — minSdk 29 (vanwege CameraX met specifieke vereisten). Google Play vereist dat de minSdk van de hoofdmodule :app lager of gelijk is aan de minSdk van alle afhankelijke modules. In de praktijk hebben alle modules van één app meestal dezelfde minSdk voor eenvoudiger onderhoud.

// build.gradle.kts — bibliotheekmodule met lage minSdk
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

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

    defaultConfig {
        minSdk = 21  // Minimaal voor maximaal bereik
        targetSdk = 36
    }
}

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

Een bibliotheekmodule met minSdk = 21 is compatibel met 97% van de apparaten en beperkt consumenten niet. Als de bibliotheek API's boven 21 gebruikt, moet de ontwikkelaar runtime-controles toevoegen of @RequiresApi op de betreffende methoden specificeren. AndroidX Core KTX (minSdk 21) biedt backports voor Context, Bundle, Locale en andere systeemklassen, waardoor de bibliotheek een lage minSdk kan behouden.

Veelgemaakte fouten bij het kiezen van minSdkVersion

Fouten bij het kiezen van minSdk kunnen duizenden installaties of weken aan extra ontwikkeling kosten. De eerste veelgemaakte fout — het kopiëren van minSdk uit het projectsjabloon zonder analyse van Distribution Dashboard. Veel ontwikkelaars laten minSdk = 21 uit het Android Studio-sjabloon staan, terwijl voor hun publiek minSdk 26 voldoende zou zijn en het aantal SDK_INT-controles in de code zou verminderen.

De tweede fout — te hoge minSdk zonder rekening te houden met de markt. Als je minSdk = 31 (Android 12) instelt voor een internationale app, verlies je ~45% van de apparaten. Voor een startup of app met een massapubliek is dit een ramp. Controleer altijd het Distribution Dashboard voordat je minSdk verhoogt en gebruik A/B-testen in Google Play Console als je niet zeker bent.

De derde fout — negeren van de minSdk van afhankelijkheden. Bij het toevoegen van een nieuwe bibliotheek, controleer de minSdk in de documentatie of het POM-bestand. Firebase ML Kit vereist minSdk 21, sommige aangepaste camerabibliotheken vereisen minSdk 29. Als manifest merger in productie faalt vanwege een nieuwe bibliotheek, kan de reparatie dagen duren.

// Voorbeeld: controle van API-compatibiliteit tijdens runtime
fun checkFeatureAvailability(): Boolean {
    // Veelgemaakte fout — API-aanroep zonder SDK_INT-controle
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — we gebruiken PhotoPicker
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — we gebruiken MediaStore
            true
        }
        else -> {
            // API < 29 — gebruiken we ACTION_GET_CONTENT
            true
        }
    }
}

De juiste architectuur van API-niveau controles — when met bereiken die alle mogelijke waarden van minSdk tot compileSdk dekken. De hoofdregel: elke aanroep van een API van niveau X moet worden beschermd door een VERSION.SDK_INT-controle voor alle apparaten met een API-niveau van minSdk tot X. lint helpt bij het detecteren van ongecontroleerde aanroepen, maar kan volledige dekking voor dynamische code niet garanderen.