targetSdkVersion: klíčové pojmy, behavioural changes a Google Play

Co je targetSdkVersion v Android?

targetSdkVersion — celočíselný parametr v build.gradle, který deklaruje úroveň API, na které byla aplikace testována. Systém Android používá tento parametr k rozhodnutí, které behavioural changes aplikovat na aplikaci během provádění. Pokud targetSdkVersion = 33, Android aplikuje všechny behavioural changes zavedené do API 33 včetně, ale neaplikuje změny API 34+. Pokud targetSdkVersion = 34 — aplikují se změny do API 34, a tak dále.

Klíčový rozdíl mezi targetSdkVersion a minSdkVersion — mechanismus působení. minSdk se kontroluje jednou při instalaci a blokuje instalaci, pokud není splněna podmínka. targetSdkVersion ovlivňuje runtime chování systému na každém zařízení, bez ohledu na to, na které verzi Android je aplikace spuštěna. Stejná aplikace s targetSdk 31 se bude chovat jinak na Android 13, 14 a 15, protože behavioural changes nad 31 jsou vypnuty.

Mechanismus targetSdkVersion — je nástroj zpětné kompatibility zabudovaný do Android. Bez něj by každá aktualizace OS zlomila tisíce starých aplikací. Google zavedl tento mechanismus v Android 2.1 (API Level 7) a od té doby jej používá jako standardní způsob zavádění nových pravidel zabezpečení, soukromí a správy zdrojů bez narušení fungování stávajících aplikací.

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

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

// Kontrola aktuálního targetSdk v kódu
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion obsahuje targetSdk aplikace
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

V příkladu targetSdk = 36 aktivuje všechny behavioural changes Android 16. Kód kontroluje targetSdkVersion přes context.applicationInfo.targetSdkVersion — to umožňuje dynamicky určit, který režim kompatibility je zapnutý. Pomocná funkce je užitečná pro knihovny, které se musí přizpůsobit targetSdk volající aplikace.

Behavioural Changes: jak targetSdk ovlivňuje aplikaci

Behavioural changes — jsou modifikace chování systému Android, které se aplikují pouze na aplikace s targetSdkVersion >= určité úrovně API. Každá nová major verze Android zavádí behavioural changes, a pokud aplikace neaktualizuje targetSdk, tyto změny nenabývají účinnosti. Takový mechanismus umožňuje vývojářům aktualizovat aplikaci vlastním tempem, ne synchronně s vydáním nové verze OS.

Scoped Storage (API 29) — jedna z nejvýznamnějších behavioural changes. Aplikace s targetSdk 29+ nemohou získat přímý File přístup ke sdíleným adresářům Pictures, Downloads, Music, Documents. Místo toho se používá MediaStore pro multimédia, SAF (Storage Access Framework) pro libovolné soubory a getExternalFilesDir() pro vlastní úložiště. Staré aplikace s targetSdk 28 a nižším nadále pracují se starým Full Storage Access, ale to vytváří bezpečnostní hrozbu.

POST_NOTIFICATIONS (API 33) — runtime oprávnění pro odesílání oznámení. Aplikace s targetSdk 33+ musí žádat o oprávnění Manifest.permission.POST_NOTIFICATIONS od uživatele prostřednictvím standardního dialogu. Pokud oprávnění není uděleno, NotificationManager.silent() nezobrazuje oznámení uživateli. Na Android 13+ bez tohoto oprávnění se push oznámení a lokální notifikace prostě nezobrazují, což může výrazně snížit zapojení uživatelů.

Jak zkontrolovat aktuální targetSdk

Hodnotu targetSdkVersion aplikace lze získat přes ADB: příkaz adb shell dumpsys package com.example.myapp | grep targetSdk zobrazí targetSdk=34. V kódu vrací context.getApplicationInfo().targetSdkVersion celé číslo. Pro analytiku je užitečné logovat targetSdk spolu s android.os.Build.VERSION.SDK_INT, abyste pochopili, které behavioural changes jsou v každé relaci skutečně aktivní.

Požadavky Google Play na targetSdkVersion (2026)

Google Play stanovuje povinné požadavky na targetSdkVersion pro všechny publikované aplikace. Od srpna 2024 je minimální targetSdk = 33 (Android 13). Od srpna 2025 — targetSdk = 34. Očekává se, že od srpna 2026 bude Google vyžadovat targetSdk = 35 (Android 15). Nové aplikace a aktualizace stávajících aplikací musí tyto požadavky splňovat, jinak konzole blokuje publikování. Toto je politika Google Play, nikoli omezení Android Runtime: aplikace s targetSdk 34 může běžet na Android 16, ale nemůže být publikována v Play Store.

Android App Bundle (AAB) — povinný formát publikování od srpna 2021. APK již není v Google Play přijímán (výjimka — aplikace s velikostí > 150 MB a některé legacy projekty). Formát AAB umožňuje Google generovat optimalizované APK pro každou úroveň API a hustotu obrazovky, což snižuje velikost stahování o 15-30%. Pro kontrolu targetSdk Google Play analyzuje manifest AAB a v případě nesouladu zobrazí chybu s uvedením minimální požadované hodnoty.

Google Play Console kontroluje targetSdkVersion nejen při nahrávání nového AAB, ale také při aktualizaci stávající aplikace. Pokud má vaše aplikace targetSdk 33 a Google zvýší minimální práh na 34 — nebudete moci vydat žádnou aktualizaci, dokud nezvýšíte targetSdk. Pro aplikace, které byly dlouhou dobu neaktualizovány, může Google Play automaticky odstranit z publikování (unpublish).

Jak aktualizovat targetSdkVersion bez chyb

Aktualizace targetSdkVersion — není jen změna čísla v build.gradle. Každá behavioural change může zlomit stávající funkčnost, pokud není kód předem připraven. Doporučuje se začít s přípravou 3-6 měsíců před termínem Google Play, zejména pokud je aplikace velká a používá mnoho systémových API.

Postup krok za krokem: Krok 1 — prostudujte behavioural changes pro novou úroveň API v dokumentaci Android Developers (stránka "Behavioural Changes by API Level"). Krok 2 — vytvořte větev targetSdk-update a změňte targetSdk na novou hodnotu. Krok 3 — spusťte aplikaci na emulátoru nebo zařízení s novou úrovní API a zkontrolujte každou funkci související se změnami. Krok 4 — opravte chyby: přidejte oprávnění, změňte práci se soubory, aktualizujte manifest.

Krok 5 — otestujte na starých zařízeních. Zvýšení targetSdk neovlivňuje zařízení s úrovní API nižší než nový targetSdk, ale behavioural changes se aplikují na všechna zařízení s API Level >= targetSdk. Pokud jste zvýšili targetSdk z 33 na 34, na zařízeních s API 34+ se aktivují behavioural changes API 34. Na zařízeních s API 33 se nic nezmění.

// Příprava na 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 omezuje Advertising ID od API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — identifikátor není dostupný, používáme MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Kontrola: která behavioural changes jsou aktivní
    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")
        }
    }
}

Třída AdsManager ukazuje přípravu na Privacy Sandbox (API 35). Advertising ID přestává být dostupný od API 35 při targetSdk 35+. Funkce getActiveChanges demonstruje správný vzor kontroly behavioural changes: je třeba současně kontrolovat SDK_INT zařízení a targetSdk aplikace. Pouze při splnění obou podmínek je změna skutečně aktivní.

Android 15 (API 35): klíčové behavioural changes

Android 15 (API 35, Vanilla Ice Cream) zavádí několik kritických behavioural changes, které musí vývojáři zohlednit při aktualizaci targetSdk na 35. První — Privacy Sandbox for Android. Toto je iniciativa Google nahradit Advertising ID soukromějšími API: Topics API (zájmy uživatele), Protected Audience (remarketing) a Attribution Reporting (konverze). Od API 35 přestává být Advertising ID stabilním identifikátorem a může vracet nulovou hodnotu.

Druhá změna — Foreground Service Types (API 34, pokračuje v API 35). Od API 34 musí každá aplikace s targetSdk 34+ určit typ foreground služby v manifestu: dataSync, systemExempted, shortService, location, mediaPlayback a další. Bez toho systém generuje ForegroundServiceTypeNotAllowedException. V API 35 byl přidán nový typ health a zpřísněna kontrola existujících typů. Všechny foreground služby musí být přezkoumány.

Třetí změna — omezení SCHEDULE_EXACT_ALARM. Od API 35 aplikace s targetSdk 35+ nemohou používat SCHEDULE_EXACT_ALARM bez výslovného souhlasu uživatele. Systém zobrazí dialog a uživatel musí schválit přesné plánování. Pro budíky a časovače to znamená další krok v UX. Alternativa — použití inexact alarmů s rezervou 10 minut.

// Android 15 (API 35): kontrola 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+: vyžaduje oprávnění uživatele
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Pod API 35 — přesné alarmy dostupné bez oprávnění
        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 a omezení alarmů — dvě nejkritičtější behavioural changes API 35. Pro reklamní SDK bude vyžadována migrace na Topics API a Attribution Reporting. Pro aplikace s budíky a připomínkami — adaptace UX na dialog oprávnění. Ignorování těchto změn povede k pádu aplikace v runtime na Android 15 nebo k nefunkční reklamní monetizaci.

Rozdíl mezi targetSdk a compileSdk

Rozdíl mezi targetSdkVersion a compileSdkVersion — jedno z nejčastějších témat zmatků mezi Android vývojáři. compileSdkVersion — je verze SDK, proti které je kód kompilován. Určuje, která API jsou během kompilace k dispozici, ale neovlivňuje runtime chování. targetSdkVersion — je verze, pod kterou byla aplikace testována, určuje, která behavioural changes se aplikují v runtime. compileSdk může a měl by být vyšší nebo roven targetSdk.

Pravidlo je jednoduché: compileSdk >= targetSdk >= minSdk. compileSdk se obvykle rovná poslední stabilní úrovni API (v roce 2026 — 36). targetSdk by měl být co nejvyšší z verzí, pod kterými jste testovali. minSdk by měl být co nejnižší pro maximální pokrytí. Zvýšení compileSdk nevyžaduje testování behavioural changes — pouze otevírá přístup k novým API pro kompilátor. Zvýšení targetSdk vyžaduje úplný testovací cyklus všech behavioural changes.

V praxi: pokud chcete použít nové API z Android 16 (API 36), ale behavioural changes API 36 jste ještě netestovali, nastavte compileSdk = 36, targetSdk = 35. Kód se zkompiluje s novými API, ale behavioural changes API 36 se neaplikují. Jakmile otestujete všechny změny — zvyšte targetSdk na 36.