API Level: vad det är, API-versioner och targetSdk

Vad är API Level Android?

API Level Android är en heltalsidentifierare som tilldelas varje offentlig version av Android Framework API. Den första versionen Android 1.0 hade API Level 1, Android 1.5 — API Level 3, Android 2.2 — API Level 8, Android 4.0 — API Level 14, Android 8.0 — API Level 26, Android 12 — API Level 31, Android 14 — API Level 34, Android 15 — API Level 35, Android 16 (2025) — API Level 36. Varje ny API Level kan lägga till nya klasser, metoder, konstanter, behörigheter och ändra beteendet hos befintliga.

API Level ökar inte strikt med 1 för varje version. Till exempel har Android 4.4W (Wear) API 20, medan Android 5.0 — API 21. Luckor beror på interna iterationer och Wear OS-enheter. För utvecklaren är det viktigt att inte känna till versionsnamnet (KitKat, Lollipop, Tiramisu), utan dess API Level — det är vad som används i koden för kompatibilitetskontroller.

Huvudsyftet med API Level är bakåtkompatibilitet. En app kompilerad mot API 34 kan köras på enheter med API 34 och lägre (om den inte använder nya API:er utan kontroll). Android Runtime (ART) kontrollerar API-anrop på systemnivå och tillämpar beteendeförändringar beroende på appens targetSdkVersion.

Hur Android hanterar API Level

Vid installation av en app kontrollerar PackageManager att enhetens API Level >= minSdkVersion från AndroidManifest.xml. Om villkoret inte uppfylls — blockeras installationen med meddelandet "App not installed". Under körning övervakar Android Runtime API-anrop som kräver en högre API Level och genererar NoSuchMethodError eller UnsatisfiedLinkError om metoden inte finns i den aktuella versionen.

minSdk, targetSdk, compileSdk: skillnader och varje parameters roll

I filen build.gradle (Module: app) specificerar utvecklaren tre API Level-parametrar: minSdkVersion, targetSdkVersion och compileSdkVersion. Att blanda ihop dem är ett av de vanligaste misstagen bland nybörjare inom Android-utveckling. Varje parameter ansvarar för en annan aspekt av kompatibilitet och deras värden måste vara konsekventa.

minSdkVersion

minSdkVersion är den lägsta API Level på vilken appen kan installeras och köras. Enheter med API Level under minSdk ser inte appen i Google Play och kan inte installera den. Värdet väljs baserat på målgruppen: minSdk 21 (Android 5.0) täcker 97% av enheterna, minSdk 26 (Android 8.0) — cirka 85%, minSdk 31 (Android 12) — cirka 55% (data från Android Studio Distribution Dashboard, 2026). Ju lägre minSdk, desto större täckning, men desto mer bakåtkompatibilitetskod behövs.

targetSdkVersion

targetSdkVersion är den API Level som appen testades mot. Android använder targetSdk för att tillämpa beteendeförändringar: om appen anger targetSdk 33 aktiverar systemet alla beteendeförändringar som infördes i API 33. Om targetSdk är 31 tillämpar systemet inte API 32-33-ändringarna och bevarar kompatibiliteten med gammalt beteende. Detta är den viktigaste parametern för säkerhet: Google Play kräver att targetSdk inte är äldre än 1 år från aktuellt API Level.

compileSdkVersion

compileSdkVersion är den Android SDK-version som koden kompileras mot. Den bestämmer vilka API:er som är tillgängliga vid kompilering. compileSdk måste vara >= targetSdk och helst lika med den senaste stabila API Level. Att höja compileSdk påverkar inte körningstidsbeteendet — bara tillgängligheten av nya API:er för kompilatorn. Efter att ha höjt compileSdk måste du kontrollera koden för föråldrade API:er och nya behörighetskrav.

// build.gradle.kts — exempel på API Level-konfiguration
plugins {
    id("com.android.application") version "8.7.0"
    id("org.jetbrains.kotlin.android") version "2.1.0"
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36  // Android 16

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

    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }

    kotlinOptions {
        jvmTarget = "17"
    }
}

dependencies {
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
    implementation("androidx.activity:activity-ktx:1.9.3")
}

I exemplet build.gradle.kts är compileSdk = 36 (senaste vid skrivtillfället), targetSdk = 36, minSdk = 26 (Android 8.0). compileSdk 36 ger tillgång till alla Android 16 API:er. targetSdk 36 aktiverar alla Android 16 beteendeförändringar. minSdk 26 täcker ~85% av enheterna. AndroidX Activity KTX och AppCompat ger bakåtkompatibilitet för fragment och teman.

AndroidManifest.xml

Parametrarna minSdk och targetSdk kan också anges i AndroidManifest.xml, men moderna projekt använder build.gradle — värden från Gradle åsidosätter manifestet. I manifestet kan det vara användbart att ange för bibliotek och moduler som inte använder Gradle build-konfiguration.

Beteendeförändringar: hur targetSdk påverkar appens beteende

Beteendeförändringar är ändringar i hur Android-systemet fungerar som endast tillämpas på appar med targetSdk >= en viss API Level. Varje ny Android-version introducerar beteendeförändringar som kan bryta befintliga appar om de inte uppdateras. Detta är en viktig säkerhetsmekanism i Android: gamla appar fortsätter att fungera som tidigare, nya följer aktuella regler.

Viktigaste beteendeförändringarna per version

Android 10 (API 29) — Scoped Storage: appar med targetSdk 29+ har inte direkt åtkomst till det delade filsystemet, endast via MediaStore, SAF eller egen lagring. Android 11 (API 30) — Package Visibility: paketfilter, appar ser bara installerade paket som de interagerar med. Android 12 (API 31) — Foreground Service Notification: alla förgrundstjänster måste visa en notis inom 10 sekunder efter start. Android 13 (API 33) — POST_NOTIFICATIONS: körningsbehörighet för pushnotiser. Android 14 (API 34) — Foreground Service Types: obligatorisk deklaration av förgrundstjänsttyp i manifestet.

// Hantering av Android 13 (API 33) beteendeförändringar: POST_NOTIFICATIONS
import android.Manifest
import android.content.pm.PackageManager
import android.os.Build
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class NotificationHelper {

    fun requestNotificationPermission(activity: MainActivity) {
        // POST_NOTIFICATIONS-behörighet fungerar endast med API 33+
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) {
            return  // Under API 33 krävs ingen behörighet
        }

        when {
            ContextCompat.checkSelfPermission(
                activity,
                Manifest.permission.POST_NOTIFICATIONS
            ) == PackageManager.PERMISSION_GRANTED -> {
                // Behörigheten redan beviljad, notiser kan skickas
                showNotification(activity)
            }

            activity.shouldShowRequestPermissionRationale(
                Manifest.permission.POST_NOTIFICATIONS
            ) -> {
                // Visa förklaring av varför behörigheten behövs
                activity.showRationale()
            }

            else -> {
                // Begär behörighet
                activity.requestPermissionLauncher.launch(
                    Manifest.permission.POST_NOTIFICATIONS
                )
            }
        }
    }

    private fun showNotification(context: Context) {
        // Skapa och visa notis
        val notification = android.app.Notification.Builder(context, "default_channel")
            .setSmallIcon(android.R.drawable.ic_dialog_info)
            .setContentTitle("Notis")
            .setContentText("Nytt meddelande")
            .build()
        val manager = context.getSystemService(Context.NOTIFICATION_SERVICE)
            as android.app.NotificationManager
        manager.notify(1, notification)
    }
}

// Registrera requestPermissionLauncher i Activity
class MainActivity : ComponentActivity() {
    val requestPermissionLauncher = registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Behörighet beviljad
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

Exempel på hantering av POST_NOTIFICATIONS i Kotlin: kontrollera Build.VERSION.SDK_INT >= TIRAMISU, begär körningsbehörighet via ActivityResultContracts.RequestPermission, hantera resultatet i en callback. Utan denna behörighet kan en app med targetSdk 33+ inte visa pushnotiser. Under API 33 krävs ingen behörighet — kontrollkoden förhindrar anrop av otillgängliga API:er.

Scoped Storage (Android 10+)

Scoped Storage är en av de mest betydande beteendeförändringarna. Från och med API 29 (targetSdk 29+) kan appen inte få direkt filåtkomst till katalogerna Pictures, Downloads, Music och Documents. Istället används MediaStore för media, SAF (Storage Access Framework) för godtyckliga filer och getExternalFilesDir() för egen lagring. Undantaget är appar med behörigheten MANAGE_EXTERNAL_STORAGE, som kräver godkännande från Google Play.

Google Plays krav på API Level och targetSdk

Google Play ställer obligatoriska targetSdkVersion-krav för publicering av appar. Sedan augusti 2024 kräver Google Play targetSdkVersion >= API 33 (Android 13). Varje år höjs tröskeln: nya appar och uppdateringar måste ange targetSdk inte äldre än 1 år från aktuellt huvud-API Level. Brott mot kravet leder till blockering av publicering och borttagning av appen från butiken.

Varför Google Play skärper kraven

Huvudorsaken är säkerhet. Varje ny Android API Level introducerar beteendeförändringar som stänger attackvektorer: Scoped Storage (API 29) förhindrar filstöld, POST_NOTIFICATIONS (API 33) skyddar mot spamnotiser, Foreground Service Types (API 34) begränsar dolda bakgrundstjänster. Appar med lågt targetSdk får inte dessa skydd och blir ett hot mot användare. Google Play kan inte tillåta föråldrade appar på moderna enheter.

Kontroll av efterlevnad av krav

Google Play Console kontrollerar targetSdkVersion vid uppladdning av APK/AAB. Om targetSdk är under kravet — blockerar konsolen publiceringen med meddelandet: "Your app currently targets API level X and must target at least API level Y". Utvecklaren måste uppdatera build.gradle, kompilera om appen, testa beteendeförändringarna och ladda upp igen. AAB-format rekommenderas för alla nya publiceringar (obligatoriskt sedan augusti 2021).

Kontrollera API Level i kod: Build.VERSION.SDK_INT

Build.VERSION.SDK_INT är en statisk heltalskonstant som innehåller API Level för enheten som appen körs på. Det är det primära verktyget för körningskontroller av Android-version. Build.VERSION_CODES innehåller namngivna konstanter för varje API Level: VERSION_CODES.TIRAMISU (33), VERSION_CODES.UPSIDE_DOWN_CAKE (34), VERSION_CODES.VANILLA_ICE_CREAM (35). Jämförelse via if (SDK_INT >= VERSION_CODES.TIRAMISU) är standardmönstret.

// Exempel på API Level-kontroll i Android-kod
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.graphics.drawable.AdaptiveIconDrawable

class ApiLevelHelper {

    // 1. Grundläggande API Level-kontroll
    fun isAtLeastTiramisu(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU  // 33
    }

    // 2. Adaptivt API-anrop med kontroll
    fun getAdaptiveIcon(drawable: android.graphics.drawable.Drawable):
            android.graphics.drawable.Drawable? {
        // AdaptiveIconDrawable är endast tillgängligt med API 26 (Android 8)
        if (VERSION.SDK_INT >= VERSION_CODES.O) {
            return AdaptiveIconDrawable(drawable, null)
        }
        return drawable  // fallback för gamla enheter
    }

    // 3. Kontroll av POST_NOTIFICATIONS-behörighet (endast API 33+)
    fun canRequestNotificationPermission(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU
    }

    // 4. Val av bildleverantör efter API Level
    fun getImagePickerProvider(): String {
        return when {
            VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
                // API 34+ använder PhotoPicker
                "photo_picker"
            }
            VERSION.SDK_INT >= VERSION_CODES.KITKAT -> {
                // API 19+ använder Intent ACTION_OPEN_DOCUMENT
                "open_document"
            }
            else -> {
                // Legacy: ACTION_GET_CONTENT (alla versioner)
                "get_content"
            }
        }
    }

    // 5. Java-stil kontroll via @TargetApi (för bakåtkompatibilitet)
    @Suppress("DEPRECATION")
    fun checkLegacyStorage(): Boolean {
        // Scoped Storage-beteende beror på targetSdk, inte SDK_INT
        return VERSION.SDK_INT < VERSION_CODES.Q  // Android 10
    }

    // 6. Bygginformation för analys
    fun getDeviceApiInfo(): Map<String, Any> {
        return mapOf(
            "sdk_int" to VERSION.SDK_INT,
            "release" to VERSION.RELEASE,
            "codename" to VERSION.CODENAME,
            "incremental" to VERSION.INCREMENTAL,
            "preview_sdk" to VERSION.PREVIEW_SDK_INT
        )
    }
}

// Testning
fun main() {
    val helper = ApiLevelHelper()
    println("API Level: ${VERSION.SDK_INT}")
    println("Is Tiramisu+: ${helper.isAtLeastTiramisu()}")
}

Klassen ApiLevelHelper demonstrerar alla huvudsakliga API Level-kontrollmönster: isAtLeastTiramisu med SDK_INT >= VERSION_CODES, getAdaptiveIcon med fallback för gamla versioner, getImagePickerProvider med when-flergrenning, getDeviceApiInfo för analyser. Huvudregeln är att inte anropa nya API:er utan att kontrollera SDK_INT, annars kraschar appen med NoSuchMethodError på gamla enheter.

ANT (Android New API) och lint

Android Studio innehåller den statiska analysatorn lint, som varnar för användning av API:er över minSdkVersion. Om en metod anropas utan SDK_INT-kontroll markerar lint det som ett fel: "Call requires API level 34 (current min is 26)". Lösningar: lägg till @RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE) till metoden eller en if-kontroll av SDK_INT. @TargetApi är en föråldrad annotering, @RequiresApi rekommenderas.

Tabell över API Level och Android-versioner

API Level-tabellen är ett referensverktyg för utvecklaren. Genom att känna till enhetens API Level kan du bestämma Android-versionen och tillgängliga funktioner. Tabellen listar alla större Android-versioner från API Level 1 (2008) till API Level 36 (2025). Kodnamnen (Cupcake, Donut, Tiramisu, VanillaIceCream) används internt på Google och i VERSION_CODES.

Tabell: tröskel-API Level för beteendeförändringar

Följande tabell visar viktiga API Level som introducerar beteendeförändringar som bryter bakåtkompatibilitet vid höjning av targetSdk: