minSdkVersion: vad är det, hur man väljer den lägsta Android-versionen

Vad är minSdkVersion i Android?

minSdkVersion — en heltalsparameter i build.gradle som anger den lägsta Android API-nivån för appinstallation. Om enhetens API-nivå är lägre än det angivna värdet blockerar PackageManager installationen och Google Play Store döljer appen från sökresultaten för en sådan enhet. minSdkVersion skrivs till AndroidManifest.xml i byggfasen via taggen <uses-sdk android:minSdkVersion> och kontrolleras vid varje installation.

Värdet på minSdkVersion är en kompromiss mellan publikräckvidd och tillgång till nya API:er. Ju lägre minSdk, desto fler enheter kan installera appen, särskilt i utvecklingsregioner där gamla Android-smartphones är populära. Ju högre minSdk, desto mindre bakåtkompatibilitetskod krävs och desto fler moderna API:er är tillgängliga utan runtime-kontroller. Android Jetpack och AndroidX-bibliotek tillhandahåller backporter av många nya API:er till gamla Android-versioner, vilket gör det möjligt att välja ett lägre minSdk utan funktionsförlust.

minSdkVersion påverkar alla utvecklingsstadier: statisk analys (lint använder minSdk för varningar), beroendekompatibilitet (bibliotek kan kräva egen minSdk), testning (måste testas på enheter med minSdk) och Google Play Console (publikräckvidd beräknas baserat på minSdk). Att ändra minSdkVersion är ett av de mest ansvarsfulla besluten i projektkonfigurationen, eftersom det påverkar kod, tester och användarbas.

Var anges minSdkVersion

Build.gradle.kts (Kotlin DSL) — den moderna standarden i Android-projekt. Parametern minSdk ställs in i defaultConfig-blocket på modulnivå. Värdet kan åsidosättas för olika byggtyper och produktvarianter, vilket möjliggör testning på lägre API:er utan att ändra huvudvärdet.

// build.gradle.kts — grundkonfiguration av 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"
    }

    // Åsidosättande av minSdk för olika flavor
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

I exemplet motsvarar minSdk = 26 Android 8.0 Oreo. Detta är ett populärt värde år 2026: enligt Android Studio Distribution Dashboard eliminerar det endast ~15% av enheterna. compileSdk = 36 ger tillgång till alla API:er i Android 16 och targetSdk = 36 aktiverar beteendeförändringarna i den senaste versionen. För debug-byggen kan minSdk sänkas för testning på gamla emulatorer.

Hur man väljer minSdkVersion: faktorer och strategi

Val av minSdkVersion — ett strategiskt beslut baserat på analys av målpublik, API-krav och bibliotekens ekosystem. Det finns inget enskilt korrekt värde för alla projekt. År 2026 rekommenderar Android Studio minSdk = 26 (Android 8.0) som basnivå för nya projekt, men för B2B-appar eller företagslösningar är lägre eller högre värden acceptabla.

Faktorer för val av minSdkVersion

Den första faktorn — Distribution Dashboard. Android Studio tillhandahåller månadsvis uppdaterad statistik över aktiva enheter per API-nivå baserat på Google Play-data. minSdkVersion bör täcka minst 90-95% av de aktiva enheterna på målmarknaden. För internationella appar med publik i Afrika och Sydostasien bör minSdk sänkas till 21 (Android 5.0) på grund av den höga andelen gamla enheter.

Den andra faktorn — beroendekrav. Varje bibliotek har sin egen minSdkVersion angiven i sitt manifest. Om ett bibliotek kräver minSdk 29 och appen — minSdk 26, misslyckas bygget med ett manifest merger-fel. Moderna Google Play Services-bibliotek har minSdk 21, Firebase — minSdk 21, de flesta Jetpack-bibliotek — minSdk 21 eller 26, Compose BOM — minSdk 21. För Compose är minimitröskeln — API 21.

Den tredje faktorn — nödvändiga API:er. Om appens nyckelfunktionalitet kräver ett API som endast är tillgängligt från en viss nivå (t.ex. PhotoPicker — API 34, Predicted Navigation — API 35), kan detta motivera en höjning av minSdk. Men oftare används en kombination av AndroidX-backporter (Activity Result API, NotificationCompat) och runtime-kontroller för att behålla ett lågt minSdk.

Steg-för-steg-strategi för val

Steg 1: öppna Android Studio, File → New Project och titta på rekommenderad minSdk i guiden. Steg 2: kontrollera Distribution Dashboard i Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Steg 3: analysera projektets beroenden — utför bygget och åtgärda manifest merger-konflikter. Steg 4: utvärdera vilka API:er på nivå X som faktiskt används utan backporter. Steg 5: ställ in minSdk som det lägsta värdet som täcker 90%+ av målpubliken och är kompatibelt med alla beroenden.

Enhetstäckning: fördelning av API-nivåer (2026)

Enhetsfördelning per API-nivå — en dynamisk indikator som förändras varje kvartal. Enligt Android Studio Distribution Dashboard för juni 2026 kör cirka 85% av aktiva Android-enheter på API 26 (Android 8.0) och högre, 72% — på API 29 (Android 10) och högre, 55% — på API 31 (Android 12) och högre. Den kinesiska marknaden har sin egen statistik på grund av avsaknaden av Google Play Services på många Huawei-enheter.

GMS-enheter (Google Mobile Services) uppdateras snabbare: andelen API 31+ på dem når 68% tack vare Google Plays obligatoriska krav på tillverkare. Icke-GMS-enheter (Huawei, Honor, vissa kinesiska märken) har en äldre fördelning: andelen API 31+ på dem är cirka 35%. Om appen är inriktad på den internationella marknaden, lita på global statistik. Om på den kinesiska — ta hänsyn till icke-GMS-segmentet.

Slutsats: för en internationell app täcker minSdk 26 85% av enheterna med minimala kostnader för bakåtkompatibilitet. För appar med publik i utvecklingsregioner är minSdk 21 (97% täckning) motiverat, men kommer att kräva mer kod för att arbeta med föråldrade API:er. För Enterprise-appar med en kontrollerad enhetsflotta kan du ställa in minSdk 31 och helt bli av med fallback-kod.

Bakåtkompatibilitet: AndroidX, lint och @RequiresApi

Bakåtkompatibilitet — den största svårigheten vid låg minSdkVersion. AndroidX (tidigare Support Library) tillhandahåller backporter av moderna API:er till gamla Android-versioner: AppCompatActivity för Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat och dussintals andra komponenter. Att använda AndroidX-ekvivalenter istället för inbyggda API:er — första steget mot kompatibilitet.

lint (statisk analysator i Android Studio) skannar kod efter anrop av API:er över minSdkVersion. Om en metod är markerad med @RequiresApi med en API-nivå högre än minSdk och anropas utan kontroll, markerar lint felet. För att undertrycka varningen, använd annoteringen @SuppressLint("NewApi") på metoden eller @RequiresApi(Build.VERSION_CODES.TIRAMISU) på hela funktionen. Runtime-kontroller via Build.VERSION.SDK_INT — den primära mekanismen för säker anrop av nya API:er på gamla enheter.

// Exempel på bakåtkompatibilitet: PhotoPicker (API 34+) och 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) — fungerar på alla API-nivåer
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker tillgänglig endast från API 34
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // Vi använder PhotoPicker (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Fallback: GetContent (fungerar på alla versioner)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // Denna metod kan inte anropas på API < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

Klassen ImagePickerActivity visar tre nivåer av bakåtkompatibilitet. Activity Result API från AndroidX fungerar på alla API-nivåer, så för grundläggande bildval spelar minSdk ingen roll. PhotoPicker (ACTION_PICK_IMAGES) är endast tillgänglig från API 34 och anropas under SDK_INT-kontroll med fallback till GetContent. Metoden usePhotoPickerOnly är markerad med @RequiresApi — lint tillåter inte att den anropas utan kontroll. AppCompat från AndroidX anpassar automatiskt tema, fragment och animationer till operativsystemets version.

minSdkVersion i bibliotek och moduler

Bibliotek (AAR, JAR) har också minSdkVersion angiven i sitt manifest. Vid anslutning av ett bibliotek kontrollerar Gradle kompatibiliteten: om bibliotekets minSdk är högre än appens minSdk misslyckas bygget med fel. För offentliga bibliotek rekommenderas att ange lägsta möjliga minSdk (21 i de flesta fall) för att inte begränsa konsumenter. Om ett bibliotek kräver API 29+, förlorar det ~28% av potentiella användare.

Multi-modulprojekt kan ha olika minSdkVersion för olika moduler. Till exempel kan modulen :core:network ha minSdk 26 och modulen :feature:camera — minSdk 29 (på grund av CameraX med specifika krav). Google Play kräver att minSdk för huvudmodulen :app är lägre än eller lika med minSdk för alla beroende moduler. I praktiken har alla moduler i en app vanligtvis samma minSdk för att förenkla underhållet.

// build.gradle.kts — biblioteksmodul med låg minSdk
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

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

    defaultConfig {
        minSdk = 21  // Minimum för maximal täckning
        targetSdk = 36
    }
}

dependencies {
    // AndroidX Core — minSdk 21, lägger till backporter
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

En biblioteksmodul med minSdk = 21 är kompatibel med 97% av enheterna och begränsar inte konsumenter. Om biblioteket använder API:er över 21 måste utvecklaren lägga till runtime-kontroller eller ange @RequiresApi på motsvarande metoder. AndroidX Core KTX (minSdk 21) tillhandahåller backporter för Context, Bundle, Locale och andra systemklasser, vilket gör att biblioteket kan behålla en låg minSdk.

Vanliga misstag vid val av minSdkVersion

Misstag vid val av minSdk kan kosta tusentals installationer eller veckor av extra utveckling. Det första vanliga misstaget — att kopiera minSdk från projektmallen utan analys av Distribution Dashboard. Många utvecklare lämnar minSdk = 21 från Android Studio-mallen, trots att för deras publik skulle minSdk 26 vara tillräckligt och minska antalet SDK_INT-kontroller i koden.

Det andra misstaget — för högt minSdk utan hänsyn till marknaden. Om du ställer in minSdk = 31 (Android 12) för en internationell app förlorar du ~45% av enheterna. För en startup eller app med masspublik är detta en katastrof. Kontrollera alltid Distribution Dashboard innan du höjer minSdk och använd A/B-testning i Google Play Console om du är osäker.

Det tredje misstaget — ignorera minSdk för beroenden. När du lägger till ett nytt bibliotek, kontrollera dess minSdk i dokumentationen eller POM-filen. Firebase ML Kit kräver minSdk 21, vissa anpassade kamerabibliotek kräver minSdk 29. Om manifest merger misslyckas i produktion på grund av ett nytt bibliotek kan reparationen ta dagar.

// Exempel: kontroll av API-kompatibilitet vid körning
fun checkFeatureAvailability(): Boolean {
    // Vanligt misstag — API-anrop utan SDK_INT-kontroll
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — vi använder PhotoPicker
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — vi använder MediaStore
            true
        }
        else -> {
            // API < 29 — vi använder ACTION_GET_CONTENT
            true
        }
    }
}

Rätt arkitektur för API-nivå-kontroller — when med intervall som täcker alla möjliga värden från minSdk till compileSdk. Huvudregeln: varje anrop av ett API på nivå X måste skyddas med en VERSION.SDK_INT-kontroll för alla enheter med API-nivå från minSdk till X. lint hjälper till att upptäcka okontrollerade anrop, men kan inte garantera full täckning för dynamisk kod.