targetSdkVersion: کلیدی تصورات، رویے کی تبدیلیاں اور Google Play

Android میں targetSdkVersion کیا ہے؟

targetSdkVersion build.gradle میں ایک عددی پیرامیٹر ہے جو API Level کا اعلان کرتا ہے جس کے خلاف ایپ کی جانچ کی گئی ہے۔ Android نظام اس پیرامیٹر کو استعمال کرتا ہے کہ runtime پر ایپ پر کون سی رویے کی تبدیلیاں لاگو کرنی ہیں۔ اگر targetSdkVersion = 33 ہے تو Android API 33 تک متعارف کرائی گئی تمام رویے کی تبدیلیوں کو لاگو کرتا ہے، لیکن API 34+ کی تبدیلیوں کو لاگو نہیں کرتا۔ اگر targetSdkVersion = 34 ہے — API 34 تک کی تبدیلیاں لاگو ہوتی ہیں، اور اسی طرح۔

targetSdkVersion اور minSdkVersion کے درمیان کلیدی فرق عمل کا طریقہ کار ہے۔ minSdk انسٹالیشن کے دوران ایک بار جانچا جاتا ہے اور اگر شرط پوری نہ ہو تو انسٹالیشن کو روک دیتا ہے۔ targetSdkVersion ہر ڈیوائس پر نظام کے runtime رویے کو متاثر کرتا ہے، قطع نظر اس کے کہ ایپ Android کے کس ورژن پر چل رہی ہے۔ targetSdk 31 والی ایک ہی ایپ Android 13، 14 اور 15 پر مختلف طریقے سے کام کرے گی، کیونکہ 31 سے اوپر کی رویے کی تبدیلیاں غیر فعال ہیں۔

targetSdkVersion میکانزم Android میں بنایا گیا ایک پسماندہ مطابقت کا آلہ ہے۔ اس کے بغیر، ہر OS اپ ڈیٹ ہزاروں پرانی ایپس کو توڑ دے گا۔ Google نے اس میکانزم کو Android 2.1 (API Level 7) میں متعارف کرایا اور اس کے بعد سے اسے موجودہ ایپلیکیشنز کو توڑے بغیر نئے سیکیورٹی، رازداری اور وسائل کے انتظام کے قواعد متعارف کرانے کے معیاری طریقہ کے طور پر استعمال کر رہا ہے۔

// build.gradle.kts — defaultConfig میں targetSdkVersion
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 Android 16 کی تمام رویے کی تبدیلیوں کو فعال کرتا ہے۔ کوڈ context.applicationInfo.targetSdkVersion کے ذریعے targetSdkVersion کو چیک کرتا ہے — یہ متحرک طور پر تعین کرنے کی اجازت دیتا ہے کہ کون سا مطابقت موڈ فعال ہے۔ مددگار فنکشن لائبریریوں کے لیے مفید ہے جنہیں کال کرنے والی ایپلیکیشن کے targetSdk کے مطابق ڈھلنے کی ضرورت ہے۔

رویے کی تبدیلیاں: targetSdk ایپ کو کیسے متاثر کرتا ہے

رویے کی تبدیلیاں Android نظام کے رویے میں تبدیلیاں ہیں جو صرف targetSdkVersion >= ایک مخصوص API Level والی ایپس پر لاگو ہوتی ہیں۔ ہر نئے بڑے Android ریلیز میں رویے کی تبدیلیاں متعارف کرائی جاتی ہیں، اور اگر کوئی ایپ targetSdk کو اپ ڈیٹ نہیں کرتی تو یہ تبدیلیاں اثر انداز نہیں ہوتیں۔ یہ میکانزم ڈویلپرز کو اپنی ایپ کو نئے OS ریلیز کے ساتھ ہم آہنگ ہونے کے بجائے اپنی رفتار سے اپ ڈیٹ کرنے کی اجازت دیتا ہے۔

Scoped Storage (API 29) سب سے اہم رویے کی تبدیلیوں میں سے ایک ہے۔ targetSdk 29+ والی ایپس مشترکہ ڈائریکٹریز Pictures، Downloads، Music، Documents تک براہ راست فائل تک رسائی حاصل نہیں کر سکتیں۔ اس کے بجائے، میڈیا کے لیے MediaStore، صوابدیدی فائلوں کے لیے SAF (Storage Access Framework) اور نجی ذخیرہ کے لیے getExternalFilesDir() استعمال کیا جاتا ہے۔ targetSdk 28 اور اس سے نیچے والی پرانی ایپس پرانی Full Storage Access کے ساتھ کام کرتی رہتی ہیں، لیکن یہ سیکیورٹی خطرہ پیدا کرتی ہیں۔

POST_NOTIFICATIONS (API 33) اطلاعات بھیجنے کے لیے runtime کی اجازت ہے۔ 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 کے ساتھ لاگ کرنا مفید ہے۔

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 سے بڑی ایپس اور کچھ پرانے پروجیکٹس کے علاوہ)۔ AAB فارمیٹ Google کو ہر API Level اور اسکرین کثافت کے لیے بہتر کردہ APK تیار کرنے کی اجازت دیتا ہے، جس سے ڈاؤن لوڈ کا سائز 15-30% کم ہوتا ہے۔ targetSdk چیک کرنے کے لیے، Google Play AAB مینی فیسٹ کا تجزیہ کرتا ہے اور اگر تعمیل نہیں کرتا تو کم از کم مطلوبہ قدر کے ساتھ خرابی جاری کرتا ہے۔

Google Play Console targetSdkVersion کو نہ صرف نیا AAB اپ لوڈ کرتے وقت چیک کرتا ہے بلکہ موجودہ ایپ کو اپ ڈیٹ کرتے وقت بھی۔ اگر آپ کی ایپ کا targetSdk 33 ہے اور Google کم از کم حد بڑھا کر 34 کر دیتا ہے — آپ targetSdk بڑھانے تک کوئی اپ ڈیٹ جاری نہیں کر سکیں گے۔ جن ایپس کو طویل عرصے سے اپ ڈیٹ نہیں کیا گیا، Google Play انہیں خود بخود اشاعت سے ہٹا سکتا ہے (unpublish)۔

غلطیوں کے بغیر targetSdkVersion کیسے اپ ڈیٹ کریں

targetSdkVersion کو اپ ڈیٹ کرنا صرف build.gradle میں نمبر تبدیل کرنا نہیں ہے۔ اگر کوڈ پہلے سے تیار نہ کیا جائے تو ہر رویے کی تبدیلی موجودہ فعالیت کو توڑ سکتی ہے۔ Google Play کی آخری تاریخ سے 3-6 ماہ پہلے تیاری شروع کرنے کی سفارش کی جاتی ہے، خاص طور پر اگر ایپ بڑی ہے اور بہت سے نظام API استعمال کرتی ہے۔

مرحلہ وار عمل: مرحلہ 1 — Android Developers دستاویزات میں (صفحہ "Behavioural Changes by API Level") نئے API Level کے لیے رویے کی تبدیلیوں کا مطالعہ کریں۔ مرحلہ 2 — targetSdk-update برانچ بنائیں اور targetSdk کو نئی قدر میں تبدیل کریں۔ مرحلہ 3 — نئے API Level والے ایمولیٹر یا ڈیوائس پر ایپ چلائیں اور تبدیلیوں سے متعلق ہر فعالیت کی جانچ کریں۔ مرحلہ 4 — خرابیاں درست کریں: اجازتیں شامل کریں، فائل ہینڈلنگ تبدیل کریں، مینی فیسٹ اپ ڈیٹ کریں۔

مرحلہ 5 — پرانی ڈیوائسز پر جانچ کریں۔ targetSdk بڑھانے سے نئے targetSdk سے کم API Level والی ڈیوائسز متاثر نہیں ہوتیں، لیکن رویے کی تبدیلیاں API Level >= targetSdk والی تمام ڈیوائسز پر لاگو ہوتی ہیں۔ اگر آپ نے targetSdk 33 سے 34 تک بڑھایا ہے، تو API 34+ والی ڈیوائسز پر 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 API 35 سے Advertising ID کو محدود کرتا ہے
        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
        }
    }

    // جانچ: کون سی رویے کی تبدیلیاں فعال ہیں
    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 فنکشن رویے کی تبدیلیوں کو چیک کرنے کا صحیح نمونہ دکھاتا ہے: ڈیوائس کے SDK_INT اور ایپ کے targetSdk دونوں کو چیک کرنا ضروری ہے۔ جب دونوں شرائط مماثل ہوں تب ہی تبدیلی حقیقت میں فعال ہے۔

Android 15 (API 35): اہم رویے کی تبدیلیاں

Android 15 (API 35, Vanilla Ice Cream) کئی اہم رویے کی تبدیلیاں متعارف کرتا ہے جنہیں ڈویلپرز کو targetSdk کو 35 میں اپ ڈیٹ کرتے وقت مدنظر رکھنا چاہیے۔ پہلی — Privacy Sandbox for Android۔ یہ Advertising ID کو زیادہ نجی API سے بدلنے کا Google کا اقدام ہے: 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 اور الارم کی پابندی API 35 کی دو سب سے اہم رویے کی تبدیلیاں ہیں۔ اشتہاری SDK کو Topics API اور Attribution Reporting پر منتقل ہونے کی ضرورت ہوگی۔ الارم اور یاد دہانیوں والی ایپس کے لیے — اجازت ڈائیلاگ کے لیے UX موافقت۔ ان تبدیلیوں کو نظر انداز کرنے سے Android 15 پر runtime میں ایپ کریش یا ٹوٹی ہوئی اشتہاری آمدنی ہوگی۔

targetSdk اور compileSdk میں فرق

targetSdkVersion اور compileSdkVersion کے درمیان فرق Android ڈویلپرز میں الجھن کے سب سے عام ذرائع میں سے ایک ہے۔ compileSdkVersion SDK کا وہ ورژن ہے جس کے خلاف کوڈ مرتب کیا جاتا ہے۔ یہ تعین کرتا ہے کہ تالیف کے وقت کون سے API دستیاب ہیں، لیکن runtime رویے کو متاثر نہیں کرتا۔ targetSdkVersion وہ ورژن ہے جس کے خلاف ایپ کی جانچ کی گئی ہے — یہ تعین کرتا ہے کہ runtime پر کون سی رویے کی تبدیلیاں لاگو ہوتی ہیں۔ compileSdk targetSdk سے زیادہ یا برابر ہو سکتا ہے اور ہونا چاہیے۔

قاعدہ سادہ ہے: compileSdk >= targetSdk >= minSdk۔ compileSdk عام طور پر تازہ ترین مستحکم API Level کے برابر ہے (2026 میں — 36)۔ targetSdk ان ورژنز میں سے زیادہ سے زیادہ ہونا چاہیے جن کی آپ نے جانچ کی ہے۔ minSdk زیادہ سے زیادہ رسائی کے لیے کم سے کم ہونا چاہیے۔ compileSdk بڑھانے کے لیے رویے کی تبدیلیوں کی جانچ ضروری نہیں — یہ صرف مرتب کرنے والے کے لیے نئے API تک رسائی کھولتا ہے۔ targetSdk بڑھانے کے لیے تمام رویے کی تبدیلیوں کے مکمل جانچ کے چکر کی ضرورت ہے۔

عملی طور پر: اگر آپ Android 16 (API 36) سے نیا API استعمال کرنا چاہتے ہیں لیکن API 36 کی رویے کی تبدیلیوں کی جانچ نہیں کی ہے، تو compileSdk = 36، targetSdk = 35 سیٹ کریں۔ کوڈ نئے API کے ساتھ مرتب ہوگا، لیکن API 36 کی رویے کی تبدیلیاں لاگو نہیں ہوں گی۔ ایک بار جب آپ تمام تبدیلیوں کی جانچ کر لیں — targetSdk کو 36 تک بڑھا دیں۔