targetSdkVersion: asosiy tushunchalar, behavioural changes va Google Play

Android-da targetSdkVersion nima?

targetSdkVersion — build.gradle dagi ilova sinovdan o'tkazilgan API Level ni e'lon qiluvchi butun son parametri. Android tizimi ushbu parametrdan qaysi behavioural changes larni ilovaga bajarilish vaqtida qo'llashni hal qilish uchun foydalanadi. Agar targetSdkVersion = 33 bo'lsa, Android API 33 gacha kiritilgan barcha behavioural changes larni qo'llaydi, lekin API 34+ o'zgarishlarini qo'llamaydi. Agar targetSdkVersion = 34 bo'lsa — API 34 gacha o'zgarishlar qo'llaniladi va hokazo.

targetSdkVersion va minSdkVersion o'rtasidagi asosiy farq — ta'sir mexanizmi. minSdk o'rnatish vaqtida bir marta tekshiriladi va shart bajarilmasa o'rnatishni bloklaydi. targetSdkVersion ilova qaysi Android versiyasida ishga tushirilganidan qat'i nazar, har bir qurilmada tizimning runtime xatti-harakatiga ta'sir qiladi. targetSdk 31 bo'lgan bir xil ilova Android 13, 14 va 15 da turlicha ishlaydi, chunki 31 dan yuqori behavioural changes o'chirilgan.

targetSdkVersion mexanizmi — Android ga o'rnatilgan orqaga qarab moslik vositasidir. Usiz har bir OT yangilanishi minglab eski ilovalarni buzardi. Google ushbu mexanizmni Android 2.1 (API Level 7) da joriy qildi va shundan beri uni mavjud ilovalar ishini buzmasdan yangi xavfsizlik, maxfiylik va resurslarni boshqarish qoidalarini joriy qilishning standart usuli sifatida ishlatadi.

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Android 16 da sinovdan o'tkazilgan
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Joriy targetSdk ni kodda tekshirish
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion ilovaning targetSdk ini o'z ichiga oladi
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Misolda targetSdk = 36 Android 16 ning barcha behavioural changes larini faollashtiradi. Kod context.applicationInfo.targetSdkVersion orqali targetSdkVersion ni tekshiradi — bu qaysi moslik rejimi yoqilganligini dinamik aniqlash imkonini beradi. Yordamchi funksiya chaqiruvchi ilovaning targetSdk iga moslashishi kerak bo'lgan kutubxonalar uchun foydalidir.

Behavioural Changes: targetSdk ilovaga qanday ta'sir qiladi

Behavioural changes — bu faqat targetSdkVersion >= ma'lum API Level bo'lgan ilovalarga qo'llaniladigan Android tizim xatti-harakati modifikatsiyalaridir. Har bir yangi major Android relizi behavioural changes larni joriy qiladi va agar ilova targetSdk ni yangilamasa, bu o'zgarishlar kuchga kirmaydi. Bunday mexanizm dasturchilarga ilovani o'z tempida yangilash imkonini beradi, OT ning yangi versiyasi chiqishi bilan sinxron emas.

Scoped Storage (API 29) — eng muhim behavioural changes lardan biri. targetSdk 29+ bo'lgan ilovalar Pictures, Downloads, Music, Documents umumiy kataloglariga to'g'ridan-to'g'ri File kirishini ololmaydi. Buning o'rniga multimedia uchun MediaStore, ixtiyoriy fayllar uchun SAF (Storage Access Framework) va o'z saqlashi uchun getExternalFilesDir() ishlatiladi. targetSdk 28 va undan past bo'lgan eski ilovalar eski Full Storage Access bilan ishlashda davom etadi, ammo bu xavfsizlik tahdidini yaratadi.

POST_NOTIFICATIONS (API 33) — bildirishnomalar yuborish uchun runtime ruxsati. targetSdk 33+ bo'lgan ilovalar standart dialog orqali foydalanuvchidan Manifest.permission.POST_NOTIFICATIONS ruxsatini so'rashi kerak. Ruxsat berilmasa, NotificationManager.silent() foydalanuvchiga bildirishnomalarni ko'rsatmaydi. Android 13+ da bu ruxsatsiz push-bildirishnomalar va lokal notifikatsiyalar shunchaki ko'rsatilmaydi, bu foydalanuvchi jalbini sezilarli darajada kamaytirishi mumkin.

Joriy targetSdk ni qanday tekshirish mumkin

Ilovaning targetSdkVersion qiymatini ADB orqali olish mumkin: adb shell dumpsys package com.example.myapp | grep targetSdk buyrug'i targetSdk=34 chiqaradi. Kodda context.getApplicationInfo().targetSdkVersion butun son qaytaradi. Analitika uchun targetSdk ni android.os.Build.VERSION.SDK_INT bilan birgalikda log qilish foydali, har bir sessiyada qaysi behavioural changes lar haqiqatda faolligini tushunish uchun.

Google Play ning targetSdkVersion talablari (2026)

Google Play barcha nashr qilinadigan ilovalar uchun targetSdkVersion ga majburiy talablar o'rnatadi. Avgust 2024 dan minimal targetSdk = 33 (Android 13). Avgust 2025 dan — targetSdk = 34. Avgust 2026 dan Google targetSdk = 35 (Android 15) talab qilishi kutilmoqda. Yangi ilovalar va mavjud ilovalarning yangilanishlari ushbu talablarga javob berishi kerak, aks holda konsol nashrni bloklaydi. Bu Google Play siyosati, Android Runtime cheklovi emas: targetSdk 34 bo'lgan ilova Android 16 da ishlashi mumkin, lekin Play Store da nashr etilmaydi.

Android App Bundle (AAB) — Avgust 2021 dan majburiy nashr formatidir. APK endi Google Play da qabul qilinmaydi (istisno — hajmi > 150 MB bo'lgan ilovalar va ba'zi legacy loyihalar). AAB formati Google ga har bir API Level va ekran zichligi uchun optimallashtirilgan APK lar yaratish imkonini beradi, bu yuklab olish hajmini 15-30% kamaytiradi. targetSdk ni tekshirish uchun Google Play AAB manifestini tahlil qiladi va nomuvofiqlik holatida minimal talab qilinadigan qiymatni ko'rsatadigan xato beradi.

Google Play Console targetSdkVersion ni nafaqat yangi AAB yuklanganda, balki mavjud ilova yangilanayotganda ham tekshiradi. Agar ilovangiz targetSdk 33 bo'lsa va Google minimal chegarani 34 ga ko'tarsa — targetSdk ni oshirmaguningizcha hech qanday yangilanishni chiqara olmaysiz. Uzoq vaqt yangilanmagan ilovalar uchun Google Play avtomatik ravishda ularni nashrdan olib tashlashi mumkin (unpublish).

targetSdkVersion ni xatosiz qanday yangilash kerak

targetSdkVersion yangilanishi — shunchaki build.gradle da raqamni o'zgartirish emas. Har bir behavioural change agar kod oldindan tayyorlanmagan bo'lsa, mavjud funksionallikni buzishi mumkin. Google Play muddatidan 3-6 oy oldin tayyorgarlikni boshlash tavsiya etiladi, ayniqsa ilova katta bo'lsa va ko'plab tizim API laridan foydalansa.

Bosqichma-bosqich jarayon: 1-qadam — yangi API Level uchun behavioural changes larni Android Developers hujjatlarida o'rganing (sahifa: "Behavioural Changes by API Level"). 2-qadam — targetSdk-update branch yarating va targetSdk ni yangi qiymatga o'zgartiring. 3-qadam — ilovani yangi API Level bilan emulyator yoki qurilmada ishga tushiring va o'zgarishlar bilan bog'liq har bir funksionallikni tekshiring. 4-qadam — xatolarni tuzating: ruxsatlar qo'shing, fayllar bilan ishlashni o'zgartiring, manifestni yangilang.

5-qadam — eski qurilmalarda sinovdan o'tkazing. targetSdk ni oshirish API Level yangi targetSdk dan past bo'lgan qurilmalarga ta'sir qilmaydi, lekin behavioural changes API Level >= targetSdk bo'lgan barcha qurilmalarda qo'llaniladi. Agar targetSdk ni 33 dan 34 ga oshirgan bo'lsangiz, API 34+ bo'lgan qurilmalarda behavioural changes API 34 faollashadi. API 33 bo'lgan qurilmalarda hech narsa o'zgarmaydi.

// targetSdk 35 ga tayyorgarlik: 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 dan cheklaydi
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — identifikator mavjud emas, MeasurementManager dan foydalanamiz
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Tekshirish: qaysi behavioural changes faol
    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 klassi Privacy Sandbox (API 35) ga tayyorgarlikni ko'rsatadi. Advertising ID targetSdk 35+ bilan API 35 dan boshlab mavjud bo'lmaydi. getActiveChanges funksiyasi behavioural changes larni tekshirishning to'g'ri namunasini ko'rsatadi: bir vaqtning o'zida qurilmaning SDK_INT va ilovaning targetSdk ini tekshirish kerak. Faqat ikkala shart ham bajarilganda o'zgarish haqiqatda faoldir.

Android 15 (API 35): asosiy behavioural changes

Android 15 (API 35, Vanilla Ice Cream) dasturchilar targetSdk ni 35 ga yangilashda hisobga olishi kerak bo'lgan bir nechta muhim behavioural changes larni joriy qiladi. Birinchisi — Privacy Sandbox for Android. Bu Google ning Advertising ID ni maxfiyroq API lar bilan almashtirish tashabbusi: Topics API (foydalanuvchi qiziqishlari), Protected Audience (remarketing) va Attribution Reporting (konversiyalar). API 35 dan boshlab Advertising ID barqaror identifikator bo'lishdan to'xtaydi va nol qiymatini qaytarishi mumkin.

Ikkinchi o'zgarish — Foreground Service Types (API 34, API 35 da davom ettirilgan). API 34 dan boshlab targetSdk 34+ bo'lgan har bir ilova manifestda foreground-xizmat turini belgilashi kerak: dataSync, systemExempted, shortService, location, mediaPlayback va boshqalar. Busiz tizim ForegroundServiceTypeNotAllowedException yaratadi. API 35 da yangi health turi qo'shildi va mavjud turlarning tekshiruvi qattiqlashtirildi. Barcha foreground-xizmatlar qayta ko'rib chiqilishi kerak.

Uchinchi o'zgarish — SCHEDULE_EXACT_ALARM cheklovi. API 35 dan boshlab targetSdk 35+ bo'lgan ilovalar foydalanuvchining aniq ruxsatisiz SCHEDULE_EXACT_ALARM dan foydalana olmaydi. Tizim dialog ko'rsatadi va foydalanuvchi aniq rejalashtirishni tasdiqlashi kerak. Budilniklar va taymerlar uchun bu UX da qo'shimcha qadam demakdir. Muqobil — 10 daqiqa zaxirasi bilan aniq bo'lmagan alarmlardan foydalanish.

// Android 15 (API 35): SCHEDULE_EXACT_ALARM tekshiruvi
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+: foydalanuvchi ruxsati talab qilinadi
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // API 35 dan past — aniq alarmlar ruxsatsiz mavjud
        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 va alarm cheklovi — API 35 ning eng muhim behavioural changes laridan ikkitasi. Reklama SDK lari uchun Topics API va Attribution Reporting ga migratsiya talab qilinadi. Budilniklar va eslatmalarga ega ilovalar uchun — ruxsat dialogi ostida UX adaptatsiyasi. Ushbu o'zgarishlarga e'tibor bermaslik Android 15 da runtime da ilovaning ishdan chiqishiga yoki reklama monetizatsiyasining ishlamasligiga olib keladi.

targetSdk va compileSdk o'rtasidagi farq

targetSdkVersion va compileSdkVersion o'rtasidagi farq — Android dasturchilari orasida eng ko'p chalkashlikka sabab bo'ladigan mavzulardan biridir. compileSdkVersion — kod kompilyatsiya qilinadigan SDK versiyasidir. U kompilyatsiya vaqtida qaysi API lar mavjudligini aniqlaydi, lekin runtime xatti-harakatiga ta'sir qilmaydi. targetSdkVersion — ilova sinovdan o'tkazilgan versiyadir, u runtime da qaysi behavioural changes qo'llanilishini belgilaydi. compileSdk targetSdk dan yuqori yoki teng bo'lishi mumkin va kerak.

Qoida oddiy: compileSdk >= targetSdk >= minSdk. compileSdk odatda oxirgi barqaror API Level ga teng (2026 yilda — 36). targetSdk sinovdan o'tkazgan versiyalar orasida imkon qadar yuqori bo'lishi kerak. minSdk maksimal qamrov uchun imkon qadar past bo'lishi kerak. compileSdk ni oshirish behavioural changes sinovini talab qilmaydi — u faqat kompilyator uchun yangi API larga kirishni ochadi. targetSdk ni oshirish barcha behavioural changes larning to'liq sinov siklini talab qiladi.

Amaliyotda: Android 16 dan (API 36) yangi API ishlatmoqchi bo'lsangiz, lekin API 36 ning behavioural changes larini hali sinovdan o'tkazmagan bo'lsangiz, compileSdk = 36, targetSdk = 35 ni o'rnating. Kod yangi API lar bilan kompilyatsiya qilinadi, lekin API 36 ning behavioural changes lari qo'llanilmaydi. Barcha o'zgarishlarni sinovdan o'tkazgandan so'ng — targetSdk ni 36 ga oshiring.