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 तक सीधे File एक्सेस प्राप्त नहीं कर सकते। इसके बजाय, मीडिया के लिए 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+ पर, push सूचनाएँ और स्थानीय सूचनाएँ बस प्रदर्शित नहीं होती हैं, जो उपयोगकर्ता जुड़ाव को काफी कम कर सकता है।

वर्तमान targetSdk कैसे जाँचें

targetSdkVersion मान ADB के माध्यम से प्राप्त किया जा सकता है: कमांड adb shell dumpsys package com.example.myapp | grep targetSdk targetSdk=34 आउटपुट करता है। कोड में, context.getApplicationInfo().targetSdkVersion एक पूर्णांक लौटाता है। विश्लेषण के लिए, यह समझने के लिए targetSdk को android.os.Build.VERSION.SDK_INT के साथ लॉग करना उपयोगी है कि प्रत्येक सत्र में कौन से व्यवहार परिवर्तन वास्तव में सक्रिय हैं।

targetSdkVersion के लिए Google Play की आवश्यकताएँ (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 मिनट के बफर के साथ inexact अलार्म का उपयोग करना है।

// 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 तक बढ़ाएँ।