targetSdkVersion: əsas anlayışlar, behavioural changes və Google Play

Android-də targetSdkVersion nədir?

targetSdkVersion — build.gradle faylında tətbiqin sınaqdan keçirildiyi API Level-i bəyan edən tam ədəd parametridir. Android sistemi bu parametrdən hansı behavioural changes-lərin tətbiqə icra zamanı tətbiq ediləcəyinə qərar vermək üçün istifadə edir. Əgər targetSdkVersion = 33 olarsa, Android API 33 daxil olmaqla bütün behavioural changes-ləri tətbiq edir, lakin API 34+ dəyişikliklərini tətbiq etmir. targetSdkVersion = 34 olarsa — API 34-ə qədər dəyişikliklər tətbiq edilir və s.

targetSdkVersion ilə minSdkVersion arasındakı əsas fərq — təsir mexanizmidir. minSdk quraşdırma zamanı bir dəfə yoxlanılır və şərt yerinə yetirilmədikdə quraşdırmanı bloklayır. targetSdkVersion tətbiqin hansı Android versiyasında işləməsindən asılı olmayaraq, hər bir cihazda sistemin runtime davranışına təsir edir. Eyni tətbiq targetSdk 31 ilə Android 13, 14 və 15-də fərqli işləyəcək, çünki 31-dən yuxarı behavioural changes söndürülüb.

targetSdkVersion mexanizmi Android-ə daxil edilmiş geriyə uyğunluq alətidir. O olmasaydı, hər bir ƏS yeniləməsi minlərlə köhnə tətbiqi sındırardı. Google bu mexanizmi Android 2.1-də (API Level 7) təqdim etdi və o vaxtdan onu mövcud tətbiqlərin işini pozmadan yeni təhlükəsizlik, məxfilik və resurs idarəetmə qaydalarını tətbiq etmək üçün standart üsul kimi istifadə edir.

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Android 16-da sınaqdan keçirilib
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Cari targetSdk-in kodda yoxlanılması
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion tətbiqin targetSdk-ini ehtiva edir
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Nümunədə targetSdk = 36 Android 16-nın bütün behavioural changes-lərini aktivləşdirir. Kod context.applicationInfo.targetSdkVersion vasitəsilə targetSdkVersion-u yoxlayır — bu, hansı uyğunluq rejiminin aktiv olduğunu dinamik olaraq təyin etməyə imkan verir. Köməkçi funksiya zəng edən tətbiqin targetSdk-ə uyğunlaşmalı olan kitabxanalar üçün faydalıdır.

Behavioural Changes: targetSdk tətbiqə necə təsir edir

Behavioural changes — yalnız targetSdkVersion >= müəyyən API Level olan tətbiqlərə tətbiq edilən Android sistem davranışı modifikasiyalarıdır. Hər yeni major Android buraxılışı behavioural changes təqdim edir və əgər tətbiq targetSdk-i yeniləmirsə, bu dəyişikliklər qüvvəyə girmir. Belə bir mexanizm tərtibatçılara tətbiqi öz tempində yeniləməyə imkan verir, ƏS-in yeni versiyasının buraxılışı ilə sinxron olaraq deyil.

Scoped Storage (API 29) — ən əhəmiyyətli behavioural changes-lərdən biridir. targetSdk 29+ olan tətbiqlər Pictures, Downloads, Music, Documents ümumi qovluqlarına birbaşa File girişi əldə edə bilməz. Bunun əvəzinə multimedia üçün MediaStore, ixtiyari fayllar üçün SAF (Storage Access Framework) və öz yaddaşı üçün getExternalFilesDir() istifadə olunur. targetSdk 28 və aşağı olan köhnə tətbiqlər köhnə Full Storage Access ilə işləməyə davam edir, lakin bu təhlükəsizlik təhlükəsi yaradır.

POST_NOTIFICATIONS (API 33) — bildiriş göndərmək üçün runtime icazəsi. targetSdk 33+ olan tətbiqlər standart dialoq vasitəsilə istifadəçidən Manifest.permission.POST_NOTIFICATIONS icazəsini tələb etməlidir. İcazə verilmədikdə, NotificationManager.silent() istifadəçiyə bildiriş göstərmir. Android 13+ bu icazə olmadan push-bildirişlər və lokal notifikasiyalar sadəcə göstərilmir, bu da istifadəçi cəlbini əhəmiyyətli dərəcədə azalda bilər.

Cari targetSdk-i necə yoxlamaq olar

Tətbiqin targetSdkVersion dəyərini ADB vasitəsilə əldə etmək olar: adb shell dumpsys package com.example.myapp | grep targetSdk əmri targetSdk=34 çıxarır. Kodda context.getApplicationInfo().targetSdkVersion tam ədəd qaytarır. Analitika üçün targetSdk-i android.os.Build.VERSION.SDK_INT ilə birlikdə loglamaq faydalıdır ki, hər sessiyada hansı behavioural changes-lərin aktiv olduğunu anlaya biləsiniz.

Google Play-in targetSdkVersion tələbləri (2026)

Google Play bütün nəşr olunan tətbiqlər üçün targetSdkVersion-a məcburi tələblər müəyyən edir. Avqust 2024-dən minimum targetSdk = 33 (Android 13). Avqust 2025-dən — targetSdk = 34. Gözlənilir ki, Avqust 2026-dan Google targetSdk = 35 (Android 15) tələb edəcək. Yeni tətbiqlər və mövcud tətbiqlərin yeniləmələri bu tələblərə cavab verməlidir, əks halda konsol nəşri bloklayır. Bu Google Play siyasətidir, Android Runtime məhdudiyyəti deyil: targetSdk 34 olan tətbiq Android 16-da işləyə bilər, lakin Play Store-da nəşr edilə bilməz.

Android App Bundle (AAB) — Avqust 2021-dən məcburi nəşr formatıdır. APK artıq Google Play-də qəbul edilmir (istisna — ölçüsü > 150 MB olan tətbiqlər və bəzi legacy-layihələr). AAB formatı Google-a hər API Level və ekran sıxlığı üçün optimallaşdırılmış APK-lər yaratmağa imkan verir ki, bu da yükləmə ölçüsünü 15-30% azaldır. targetSdk-i yoxlamaq üçün Google Play AAB manifestini analiz edir və uyğunsuzluq halında minimum tələb olunan dəyəri göstərən xəta verir.

Google Play Console targetSdkVersion-u təkcə yeni AAB yüklənərkən deyil, həm də mövcud tətbiq yenilənərkən yoxlayır. Əgər tətbiqinizin targetSdk 33-dürsə və Google minimum həddi 34-ə qaldırarsa — targetSdk-i yüksəltməyincə heç bir yeniləmə buraxa bilməyəcəksiniz. Uzun müddət yenilənməyən tətbiqlər üçün Google Play avtomatik olaraq onları nəşrdən silə bilər (unpublish).

targetSdkVersion-u səhvsiz necə yeniləmək olar

targetSdkVersion yeniləməsi — sadəcə build.gradle-də rəqəmi dəyişmək deyil. Hər bir behavioural change əvvəlcədən kod hazırlanmadıqda mövcud funksionallığı sındıra bilər. Google Play müddətindən 3-6 ay əvvəl hazırlığa başlamaq tövsiyə olunur, xüsusən də tətbiq böyükdürsə və çoxlu sistem API-lərindən istifadə edirsə.

Addım-addım proses: Addım 1 — Android Developers sənədlərində yeni API Level üçün behavioural changes-ləri öyrənin (səhifə: "Behavioural Changes by API Level"). Addım 2 — targetSdk-update budağı yaradın və targetSdk-i yeni dəyərə dəyişin. Addım 3 — tətbiqi yeni API Level ilə emulyator və ya cihazda işə salın və dəyişikliklərlə əlaqəli hər funksionallığı yoxlayın. Addım 4 — səhvləri düzəldin: icazələr əlavə edin, fayllarla işi dəyişin, manifesti yeniləyin.

Addım 5 — köhnə cihazlarda sınaqdan keçirin. targetSdk-in yüksəldilməsi API Level-i yeni targetSdk-dən aşağı olan cihazlara təsir etmir, lakin behavioural changes API Level >= targetSdk olan bütün cihazlarda tətbiq edilir. targetSdk-i 33-dən 34-ə qaldırmısınızsa, API 34+ olan cihazlarda behavioural changes API 34 aktivləşəcək. API 33 olan cihazlarda heç nə dəyişməyəcək.

// targetSdk 35-ə hazırlıq: 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-ni API 35-dən məhdudlaşdırır
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — identifikator əlçatan deyil, MeasurementManager istifadə edirik
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Yoxlama: hansı behavioural changes aktivdir
    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 sinfi Privacy Sandbox-a (API 35) hazırlığı göstərir. Advertising ID targetSdk 35+ ilə API 35-dən etibarən əlçatan olmur. getActiveChanges funksiyası behavioural changes yoxlanılması üçün düzgün nümunəni nümayiş etdirir: həm cihazın SDK_INT, həm də tətbiqin targetSdk-i eyni vaxtda yoxlanılmalıdır. Yalnız hər iki şərt yerinə yetirildikdə dəyişiklik həqiqətən aktivdir.

Android 15 (API 35): əsas behavioural changes

Android 15 (API 35, Vanilla Ice Cream) tərtibatçıların targetSdk-i 35-ə yeniləyərkən nəzərə almalı olduğu bir neçə kritik behavioural changes təqdim edir. Birinci — Privacy Sandbox for Android. Bu, Google-ın Advertising ID-ni daha məxfi API-lərlə əvəz etmək təşəbbüsüdür: Topics API (istifadəçi maraqları), Protected Audience (remarketinq) və Attribution Reporting (konversiyalar). API 35-dən etibarən Advertising ID sabit identifikator olmaqdan çıxır və sıfır dəyəri qaytara bilər.

İkinci dəyişiklik — Foreground Service Types (API 34, API 35-də davam etdirilir). API 34-dən başlayaraq targetSdk 34+ olan hər tətbiq manifestdə foreground-xidmət növünü təyin etməlidir: dataSync, systemExempted, shortService, location, mediaPlayback və s. Bu olmadan sistem ForegroundServiceTypeNotAllowedException yaradır. API 35-də yeni health növü əlavə edildi və mövcud növlərin yoxlanılması sərtləşdirildi. Bütün foreground-xidmətlər nəzərdən keçirilməlidir.

Üçüncü dəyişiklik — SCHEDULE_EXACT_ALARM məhdudiyyəti. API 35-dən başlayaraq targetSdk 35+ olan tətbiqlər istifadəçinin açıq icazəsi olmadan SCHEDULE_EXACT_ALARM istifadə edə bilməz. Sistem dialoq göstərir və istifadəçi dəqiq planlaşdırmanı təsdiqləməlidir. Zəngli saatlar və taymerlər üçün bu, UX-də əlavə addım deməkdir. Alternativ — 10 dəqiqə ehtiyatı olan inexact-alarmlardan istifadə etmək.

// Android 15 (API 35): SCHEDULE_EXACT_ALARM yoxlanılması
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+: istifadəçi icazəsi tələb olunur
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // API 35-dən aşağı — dəqiq alarmlar icazəsiz əlçatandır
        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 və alarm məhdudiyyəti — API 35-in ən kritik behavioural changes-lərindən ikisidir. Reklam SDK-ları üçün Topics API və Attribution Reporting-ə miqrasiya tələb olunacaq. Zəngli saatlar və xatırlatmaları olan tətbiqlər üçün — icazə dialoqu altında UX adaptasiyası. Bu dəyişikliklərə məhəl qoymamaq Android 15-də runtime zamanı tətbiqin çökməsinə və ya reklam monetizasiyasının işləməməsinə gətirib çıxaracaq.

targetSdk və compileSdk arasındakı fərq

targetSdkVersion və compileSdkVersion arasındakı fərq — Android tərtibatçıları arasında ən çox qarışıqlıq yaradan mövzulardan biridir. compileSdkVersion — kodun kompilasiya edildiyi SDK versiyasıdır. O, kompilasiya zamanı hansı API-lərin əlçatan olduğunu müəyyən edir, lakin runtime davranışına təsir etmir. targetSdkVersion — tətbiqin sınaqdan keçirildiyi versiyadır, runtime-da hansı behavioural changes-lərin tətbiq ediləcəyini müəyyən edir. compileSdk targetSdk-dən yüksək və ya bərabər ola bilər və olmalıdır.

Qayda sadədir: compileSdk >= targetSdk >= minSdk. compileSdk adətən son stabil API Level-ə bərabərdir (2026-cı ildə — 36). targetSdk sınaqdan keçirdiyiniz versiyalar arasında mümkün qədər yüksək olmalıdır. minSdk maksimum əhatə üçün mümkün qədər aşağı olmalıdır. compileSdk-in yüksəldilməsi behavioural changes testi tələb etmir — o, sadəcə kompilator üçün yeni API-lərə giriş açır. targetSdk-in yüksəldilməsi bütün behavioural changes-lərin tam test dövrünü tələb edir.

Praktikada: Android 16-dan (API 36) yeni API istifadə etmək istəyirsinizsə, lakin API 36-nın behavioural changes-lərini hələ sınaqdan keçirməmisinizsə, compileSdk = 36, targetSdk = 35 təyin edin. Kod yeni API-lərlə kompilasiya olunacaq, lakin API 36-nın behavioural changes-ləri tətbiq edilməyəcək. Bütün dəyişiklikləri sınaqdan keçirdikdən sonra targetSdk-i 36-ya qaldırın.