targetSdkVersion: кључни појмови, behavioural changes и Google Play

Шта је targetSdkVersion у Android-у?

targetSdkVersion — целобројни параметар у build.gradle који декларише API ниво на којем је апликација тестирана. Систем Android користи овај параметар да одлучи које behavioural changes да примени на апликацију током извршавања. Ако је targetSdkVersion = 33, Android примењује све behavioural changes уведене до API 33 укључујући, али не примењује измене API 34+. Ако је targetSdkVersion = 34 — примењују се измене до API 34, и тако даље.

Кључна разлика између targetSdkVersion и minSdkVersion — механизам деловања. minSdk се проверава једном приликом инсталације и блокира инсталацију ако услов није испуњен. targetSdkVersion утиче на рунтајм понашање система на сваком уређају, без обзира на којој верзији Android-а се апликација покреће. Иста апликација са targetSdk 31 понашаће се другачије на Android 13, 14 и 15, јер су behavioural changes изнад 31 искључени.

Механизам targetSdkVersion је алат за уназадну компатибилност уграђен у Android. Без њега би свако ажурирање оперативног система покварило хиљаде старих апликација. Google је увео овај механизам у Android 2.1 (API Level 7) и од тада га користи као стандардни начин увођења нових правила безбедности, приватности и управљања ресурсима без нарушавања рада постојећих апликација.

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Тестирано под Android 16
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Провера тренутног targetSdk-а у коду
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion садржи targetSdk апликације
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

У примеру targetSdk = 36 укључује све behavioural changes Android 16. Код проверава targetSdkVersion кроз context.applicationInfo.targetSdkVersion — ово омогућава динамичко одређивање који режим компатибилности је укључен. Помоћна функција је корисна за библиотеке које морају да се прилагоде targetSdk-у апликације која их позива.

Behavioural Changes: како targetSdk утиче на апликацију

Behavioural changes — то су модификације понашања система Android које се примењују само на апликације са targetSdkVersion >= одређеног API нивоа. Свако ново мајор издање Android-а уводи behavioural changes, и ако апликација не ажурира targetSdk, ове измене не ступају на снагу. Такав механизам омогућава програмерима да ажурирају апликацију сопственим темпом, а не синхроно са изласком нове верзије оперативног система.

Scoped Storage (API 29) — једна од најзначајнијих behavioural changes. Апликације са targetSdk 29+ не могу да добију директан File приступ заједничким директоријумима Pictures, Downloads, Music, Documents. Уместо тога користи се MediaStore за мултимедију, SAF (Storage Access Framework) за произвољне датотеке и getExternalFilesDir() за сопствено складиште. Старе апликације са targetSdk 28 и нижим настављају да раде са старим Full Storage Access-ом, али то ствара безбедносну претњу.

POST_NOTIFICATIONS (API 33) — рунтајм дозвола за слање обавештења. Апликације са targetSdk 33+ морају да затраже дозволу Manifest.permission.POST_NOTIFICATIONS од корисника кроз стандардни дијалог. Ако дозвола није дата, NotificationManager.silent() не приказује обавештења кориснику. На Android 13+ без ове дозволе пусх обавештења и локалне нотификације се једноставно не приказују, што може значајно смањити ангажовање корисника.

Како проверити тренутни targetSdk

Вредност targetSdkVersion апликације може се добити путем ADB-а: команда adb shell dumpsys package com.example.myapp | grep targetSdk приказује targetSdk=34. У коду, context.getApplicationInfo().targetSdkVersion враћа цео број. За аналитику је корисно логирати targetSdk заједно са android.os.Build.VERSION.SDK_INT да би се разумело који behavioural changes су заправо активни у свакој сесији.

Захтеви Google Play-а за targetSdkVersion (2026)

Google Play поставља обавезне захтеве за targetSdkVersion за све објављене апликације. Од августа 2024. минимални targetSdk = 33 (Android 13). Од августа 2025. — targetSdk = 34. Очекује се да ће од августа 2026. Google захтевати targetSdk = 35 (Android 15). Нове апликације и ажурирања постојећих морају да испуне ове захтеве, иначе конзола блокира објављивање. Ово је политика Google Play-а, а не ограничење Android Runtime-а: апликација са targetSdk 34 може да ради на Android 16, али не може да буде објављена у Play Store-у.

Android App Bundle (AAB) — обавезни формат објављивања од августа 2021. APK се више не прихвата у Google Play-у (изузетак — апликације величине > 150 MB и неки legacy пројекти). AAB формат омогућава Google-у да генерише оптимизоване APK-ове за сваки API ниво и густину екрана, што смањује величину преузимања за 15-30%. За проверу targetSdk-а, Google Play анализира AAB манифест и у случају неусаглашености приказује грешку са навођењем минималне потребне вредности.

Google Play Console проверава targetSdkVersion не само при отпремању новог AAB-а, већ и при ажурирању постојеће апликације. Ако ваша апликација има targetSdk 33, а Google подигне минимални праг на 34 — нећете моћи да објавите ниједно ажурирање док не подигнете targetSdk. За апликације које се дуго нису ажурирале, Google Play може аутоматски да их уклони из објављивања (unpublish).

Како ажурирати targetSdkVersion без грешака

Ажурирање targetSdkVersion — није само промена броја у build.gradle. Свака behavioural change може да поквари постојећу функционалност ако се код не припреми унапред. Препоручује се започињање припреме 3-6 месеци пре рока Google Play-а, посебно ако је апликација велика и користи многе системске API-је.

Процес корак по корак: Корак 1 — проучите behavioural changes за нови API ниво у документацији Android Developers (страница "Behavioural Changes by API Level"). Корак 2 — направите грану targetSdk-update и промените targetSdk на нову вредност. Корак 3 — покрените апликацију на емулатору или уређају са новим API нивоом и проверите сваку функционалност повезану са изменама. Корак 4 — исправите грешке: додајте дозволе, промените рад са датотекама, ажурирајте манифест.

Корак 5 — тестирајте на старим уређајима. Подизање targetSdk-а не утиче на уређаје са API нивоом нижим од новог targetSdk-а, али behavioural changes се примењују на свим уређајима са API Level >= targetSdk. Ако сте подигли targetSdk са 33 на 34, на уређајима са API 34+ ће се укључити behavioural changes API 34. На уређајима са API 33 ништа се неће променити.

// Припрема за 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 ограничава Advertising ID од API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — идентификатор недоступан, користимо MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Провера: које behavioural changes су активне
    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")
        }
    }
}

Класа AdsManager показује припрему за Privacy Sandbox (API 35). Advertising ID престаје да буде доступан од API 35 при targetSdk 35+. Функција getActiveChanges демонстрира прави образац провере behavioural changes: потребно је истовремено проверити SDK_INT уређаја и targetSdk апликације. Само када су оба услова испуњена, промена је заправо активна.

Android 15 (API 35): кључни behavioural changes

Android 15 (API 35, Vanilla Ice Cream) уводи неколико критичних behavioural changes које програмери морају узети у обзир при ажурирању targetSdk на 35. Прва — Privacy Sandbox for Android. Ово је иницијатива Google-а да замени Advertising ID приватнијим API-јима: Topics API (интересовања корисника), Protected Audience (ремаркетинг) и Attribution Reporting (конверзије). Од API 35 Advertising ID престаје да буде стабилан идентификатор и може враћати нулту вредност.

Друга промена — Foreground Service Types (API 34, настављено у API 35). Почев од API 34, свака апликација са targetSdk 34+ мора да наведе тип форграунд сервиса у манифесту: dataSync, systemExempted, shortService, location, mediaPlayback и друге. Без тога систем генерише ForegroundServiceTypeNotAllowedException. У API 35 додат је нови тип health и пооштрена је провера постојећих типова. Сви форграунд сервиси морају бити прегледани.

Трећа промена — ограничење SCHEDULE_EXACT_ALARM. Почев од API 35, апликације са targetSdk 35+ не могу користити SCHEDULE_EXACT_ALARM без изричите дозволе корисника. Систем приказује дијалог и корисник мора одобрити прецизно планирање. За будилнике и тајмере ово значи додатни корак у UX-у. Алтернатива — коришћење непрецизних аларма са резервом од 10 минута.

// Android 15 (API 35): провера 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+: потребна дозвола корисника
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Испод API 35 — прецизни аларми доступни без дозволе
        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 и ограничење аларма — два најкритичнија behavioural changes API 35. За рекламне SDK-ове биће потребна миграција на Topics API и Attribution Reporting. За апликације са будилницима и подсетницима — адаптација UX-а под дијалог дозволе. Игнорисање ових промена довешће до рушења апликације у рунтајму на Android 15 или до нерадне рекламне монетизације.

Разлика између targetSdk и compileSdk

Разлика између targetSdkVersion и compileSdkVersion — једна од најчешћих тема забуне међу Android програмерима. compileSdkVersion — то је верзија SDK-а против које се компајлира код. Она одређује који API-ји су доступни током компајлирања, али не утиче на рунтајм понашање. targetSdkVersion — то је верзија под којом је апликација тестирана, она одређује који behavioural changes се примењују у рунтајму. compileSdk може и треба да буде виши или једнак targetSdk-у.

Правило је једноставно: compileSdk >= targetSdk >= minSdk. compileSdk је обично једнак последњем стабилном API нивоу (2026. године — 36). targetSdk треба да буде што виши међу верзијама под којима сте извршили тестирање. minSdk треба да буде што нижи за максималну покривеност. Подизање compileSdk-а не захтева тестирање behavioural changes — оно само отвара приступ новим API-јима за компајлер. Подизање targetSdk-а захтева потпуни циклус тестирања свих behavioural changes.

У пракси: ако желите да користите нови API из Android 16 (API 36), али behavioural changes API 36 још нисте тестирали, поставите compileSdk = 36, targetSdk = 35. Код ће се компајлирати са новим API-јима, али behavioural changes API 36 неће бити примењени. Чим тестирате све промене — подигните targetSdk на 36.