targetSdkVersion: nyckelbegrepp, behavioural changes och Google Play

Vad är targetSdkVersion i Android?

targetSdkVersion — en heltalsparameter i build.gradle som deklarerar den API-nivå som appen testades på. Android-systemet använder denna parameter för att besluta vilka behavioural changes som ska tillämpas på appen under körning. Om targetSdkVersion = 33 tillämpar Android alla behavioural changes som införts upp till och med API 33, men tillämpar inte ändringar i API 34+. Om targetSdkVersion = 34 — tillämpas ändringar upp till API 34, och så vidare.

Den viktigaste skillnaden mellan targetSdkVersion och minSdkVersion — verkningsmekanismen. minSdk kontrolleras en gång vid installation och blockerar installation om villkoret inte uppfylls. targetSdkVersion påverkar systemets runtime-beteende på varje enhet, oavsett vilken Android-version appen körs på. Samma app med targetSdk 31 kommer att bete sig olika på Android 13, 14 och 15, eftersom behavioural changes över 31 är inaktiverade.

targetSdkVersion-mekanismen — är ett bakåtkompatibilitetsverktyg inbyggt i Android. Utan det skulle varje OS-uppdatering förstöra tusentals gamla appar. Google introducerade denna mekanism i Android 2.1 (API Level 7) och har sedan dess använt den som standardsättet att införa nya säkerhets-, integritets- och resurshanteringsregler utan att störa befintliga appars funktion.

// build.gradle.kts — targetSdkVersion i defaultConfig
android {
    namespace = "com.example.myapp"
    compileSdk = 36

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

// Kontroll av nuvarande targetSdk i koden
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion innehåller appens targetSdk
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

I exemplet aktiverar targetSdk = 36 alla behavioural changes i Android 16. Koden kontrollerar targetSdkVersion via context.applicationInfo.targetSdkVersion — detta gör det möjligt att dynamiskt avgöra vilket kompatibilitetsläge som är aktiverat. Hjälpfunktionen är användbar för bibliotek som måste anpassa sig till den anropande appens targetSdk.

Behavioural Changes: hur targetSdk påverkar appen

Behavioural changes — är modifieringar av Android-systemets beteende som endast tillämpas på appar med targetSdkVersion >= en viss API-nivå. Varje ny större Android-version introducerar behavioural changes, och om appen inte uppdaterar targetSdk träder dessa ändringar inte i kraft. En sådan mekanism gör det möjligt för utvecklare att uppdatera appen i sin egen takt, inte synkroniserat med lanseringen av en ny OS-version.

Scoped Storage (API 29) — en av de mest betydande behavioural changes. Appar med targetSdk 29+ kan inte få direkt File-åtkomst till de delade katalogerna Pictures, Downloads, Music, Documents. Istället används MediaStore för multimedia, SAF (Storage Access Framework) för godtyckliga filer och getExternalFilesDir() för egen lagring. Gamla appar med targetSdk 28 och lägre fortsätter att fungera med gamla Full Storage Access, men detta skapar en säkerhetsrisk.

POST_NOTIFICATIONS (API 33) — runtime-behörighet för att skicka meddelanden. Appar med targetSdk 33+ måste begära behörigheten Manifest.permission.POST_NOTIFICATIONS från användaren via en standarddialog. Om behörigheten inte beviljas visar NotificationManager.silent() inga meddelanden för användaren. På Android 13+ utan denna behörighet visas push-meddelanden och lokala notifikationer helt enkelt inte, vilket kan minska användarengagemanget avsevärt.

Hur du kontrollerar nuvarande targetSdk

Appens targetSdkVersion-värde kan erhållas via ADB: kommandot adb shell dumpsys package com.example.myapp | grep targetSdk visar targetSdk=34. I kod returnerar context.getApplicationInfo().targetSdkVersion ett heltal. För analys är det användbart att logga targetSdk tillsammans med android.os.Build.VERSION.SDK_INT för att förstå vilka behavioural changes som faktiskt är aktiva i varje session.

Google Plays krav på targetSdkVersion (2026)

Google Play ställer obligatoriska krav på targetSdkVersion för alla publicerade appar. Från augusti 2024 är lägsta targetSdk = 33 (Android 13). Från augusti 2025 — targetSdk = 34. Det förväntas att från augusti 2026 kommer Google att kräva targetSdk = 35 (Android 15). Nya appar och uppdateringar av befintliga appar måste uppfylla dessa krav, annars blockerar konsolen publicering. Detta är Google Plays policy, inte en Android Runtime-begränsning: en app med targetSdk 34 kan köras på Android 16, men kan inte publiceras i Play Store.

Android App Bundle (AAB) — det obligatoriska publiceringsformatet sedan augusti 2021. APK accepteras inte längre i Google Play (undantag — appar med storlek > 150 MB och vissa legacy-projekt). AAB-formatet gör det möjligt för Google att generera optimerade APK:er för varje API-nivå och skärmdensitet, vilket minskar nedladdningsstorleken med 15-30%. För att kontrollera targetSdk analyserar Google Play AAB-manifestet och vid bristande överensstämmelse visar ett fel med det lägsta erforderliga värdet.

Google Play Console kontrollerar targetSdkVersion inte bara vid uppladdning av en ny AAB, utan även vid uppdatering av en befintlig app. Om din app har targetSdk 33 och Google höjer den lägsta tröskeln till 34 — kan du inte släppa någon uppdatering förrän du höjer targetSdk. För appar som inte har uppdaterats på länge kan Google Play automatiskt avpublicera dem (unpublish).

Hur du uppdaterar targetSdkVersion utan fel

Uppdatering av targetSdkVersion — är inte bara att ändra en siffra i build.gradle. Varje behavioural change kan bryta befintlig funktionalitet om koden inte förbereds i förväg. Det rekommenderas att påbörja förberedelserna 3-6 månader före Google Plays deadline, särskilt om appen är stor och använder många system-API:er.

Steg-för-steg-process: Steg 1 — studera behavioural changes för den nya API-nivån i Android Developers dokumentation (sidan "Behavioural Changes by API Level"). Steg 2 — skapa en gren targetSdk-update och ändra targetSdk till det nya värdet. Steg 3 — kör appen på en emulator eller enhet med den nya API-nivån och kontrollera varje funktionalitet relaterad till ändringarna. Steg 4 — åtgärda fel: lägg till behörigheter, ändra filhantering, uppdatera manifestet.

Steg 5 — testa på gamla enheter. Höjning av targetSdk påverkar inte enheter med API-nivå lägre än den nya targetSdk, men behavioural changes tillämpas på alla enheter med API Level >= targetSdk. Om du har höjt targetSdk från 33 till 34 kommer behavioural changes för API 34 att aktiveras på enheter med API 34+. På enheter med API 33 kommer ingenting att förändras.

// Förberedelser för targetSdk 35: Privacy Sandbox
import android.os.Build
import android.os.Build.VERSION_CODES
import com.google.android.gms.ads.identifier.AdvertisingIdClient

class AdsManager {

    fun getAdvertisingId(context: android.content.Context): String? {
        // Privacy Sandbox begränsar Advertising ID från API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — identifierare inte tillgänglig, använder MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Kontroll: vilka behavioural changes är aktiva
    fun getActiveChanges(context: android.content.Context): List<String> {
        val sdkInt = Build.VERSION.SDK_INT
        val targetSdk = context.applicationInfo.targetSdkVersion
        return buildList {
            if (sdkInt >= VERSION_CODES.Q && targetSdk >= VERSION_CODES.Q)
                add("ScopedStorage")
            if (sdkInt >= VERSION_CODES.TIRAMISU && targetSdk >= VERSION_CODES.TIRAMISU)
                add("PostNotifications")
            if (sdkInt >= VERSION_CODES.UPSIDE_DOWN_CAKE && targetSdk >= VERSION_CODES.UPSIDE_DOWN_CAKE)
                add("FgsTypes")
        }
    }
}

Klassen AdsManager visar förberedelser för Privacy Sandbox (API 35). Advertising ID är inte längre tillgängligt från och med API 35 med targetSdk 35+. Funktionen getActiveChanges demonstrerar rätt mönster för att kontrollera behavioural changes: både enhetens SDK_INT och appens targetSdk måste kontrolleras samtidigt. Endast när båda villkoren är uppfyllda är ändringen faktiskt aktiv.

Android 15 (API 35): viktiga behavioural changes

Android 15 (API 35, Vanilla Ice Cream) introducerar flera kritiska behavioural changes som utvecklare måste ta hänsyn till när de uppdaterar targetSdk till 35. Den första — Privacy Sandbox for Android. Detta är Googles initiativ för att ersätta Advertising ID med mer privata API:er: Topics API (användarintressen), Protected Audience (remarketing) och Attribution Reporting (konverteringar). Från API 35 upphör Advertising ID att vara en stabil identifierare och kan returnera ett nollvärde.

Den andra ändringen — Foreground Service Types (API 34, fortsatt i API 35). Från och med API 34 måste varje app med targetSdk 34+ ange typen av foreground-tjänst i manifestet: dataSync, systemExempted, shortService, location, mediaPlayback och andra. Utan detta genererar systemet ForegroundServiceTypeNotAllowedException. I API 35 har den nya typen health lagts till och kontrollen av befintliga typer har skärpts. Alla foreground-tjänster måste granskas.

Den tredje ändringen — begränsning av SCHEDULE_EXACT_ALARM. Från och med API 35 kan appar med targetSdk 35+ inte använda SCHEDULE_EXACT_ALARM utan uttryckligt tillstånd från användaren. Systemet visar en dialogruta och användaren måste godkänna exakt schemaläggning. För väckarklockor och timers innebär detta ett extra steg i UX. Alternativ — använd inexact-alarm med 10 minuters marginal.

// Android 15 (API 35): kontroll av SCHEDULE_EXACT_ALARM
import android.app.AlarmManager
import android.os.Build
import android.provider.Settings

class AlarmScheduler {

    fun canScheduleExactAlarms(context: android.content.Context): Boolean {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+: kräver användarens tillstånd
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Under API 35 — exakta alarm tillgängliga utan tillstånd
        return true
    }

    fun requestExactAlarmPermission(activity: android.app.Activity) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            val intent = android.content.Intent(
                Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
            ).apply {
                data = android.net.Uri.fromParts(
                    "package", activity.packageName, null
                )
            }
            activity.startActivity(intent)
        }
    }
}

Privacy Sandbox och alarmbegränsningen — två av de mest kritiska behavioural changes i API 35. För reklam-SDK:er kommer migration till Topics API och Attribution Reporting att krävas. För appar med väckarklockor och påminnelser — UX-anpassning till behörighetsdialogrutan. Att ignorera dessa ändringar kommer att leda till att appen kraschar i runtime på Android 15 eller till icke-fungerande reklamintäktsgenerering.

Skillnad mellan targetSdk och compileSdk

Skillnaden mellan targetSdkVersion och compileSdkVersion — ett av de vanligaste förvirringsämnena bland Android-utvecklare. compileSdkVersion — är den SDK-version som koden kompileras mot. Den bestämmer vilka API:er som är tillgängliga under kompilering, men påverkar inte runtime-beteendet. targetSdkVersion — är den version som appen testades under, den bestämmer vilka behavioural changes som tillämpas i runtime. compileSdk kan och bör vara högre än eller lika med targetSdk.

Regeln är enkel: compileSdk >= targetSdk >= minSdk. compileSdk är vanligtvis lika med den senaste stabila API-nivån (år 2026 — 36). targetSdk bör vara så hög som möjligt bland de versioner du har testat under. minSdk bör vara så låg som möjligt för maximal täckning. Att höja compileSdk kräver inte testning av behavioural changes — det öppnar bara tillgång till nya API:er för kompilatorn. Att höja targetSdk kräver en fullständig testcykel av alla behavioural changes.

I praktiken: om du vill använda ett nytt API från Android 16 (API 36), men inte har testat behavioural changes för API 36 än, ställ in compileSdk = 36, targetSdk = 35. Koden kommer att kompileras med de nya API:erna, men behavioural changes för API 36 kommer inte att tillämpas. När du har testat alla ändringar — höj targetSdk till 36.