compileSdkVersion — एप्लिकेशन को कंपाइल करते समय उपयोग किया जाने वाला Android SDK संस्करण। यह पैरामीटर build.gradle में निर्दिष्ट किया जाता है और यह निर्धारित करता है कि डेवलपर के लिए बिल्ड समय पर कौन से API उपलब्ध हैं: एक विशिष्ट API Level से क्लास, विधियाँ, स्थिरांक और इंटरफ़ेस। targetSdkVersion के विपरीत, compileSdkVersion रनटाइम व्यवहार को प्रभावित नहीं करता है — Android के व्यवहारिक परिवर्तन इस पैरामीटर पर निर्भर नहीं करते हैं। Android Developers के अनुसार, compileSdk कम से कम targetSdk के बराबर होना चाहिए, और आदर्श रूप से नवीनतम स्थिर API Level के बराबर होना चाहिए।
मुख्य बातें
compileSdkVersion build.gradle में एक पूर्णांक पैरामीटर है जो निर्दिष्ट करता है कि कोड को किस Android SDK संस्करण के विरुद्ध कंपाइल किया जाए। जब आप android.* या androidx.* से क्लास का उपयोग करके कोड लिखते हैं, तो कंपाइलर उन्हें निर्दिष्ट compileSdk संस्करण में उपलब्ध API के विरुद्ध जाँचता है। यदि कोई विधि API 36 में पेश की गई थी और compileSdk = 35 है, तो कोड कंपाइल नहीं होगा। यदि compileSdk = 36 है, तो कोड कंपाइल होगा, लेकिन बिना जाँच के API 35 वाले डिवाइस पर उस विधि को कॉल करने से क्रैश हो जाएगा।
compileSdkVersion Android SDK Platform से लोड होता है जो Android Studio में SDK Manager के माध्यम से स्थापित होती है। प्रत्येक API Level की अपनी प्लेटफ़ॉर्म होती है: android-21, android-29, android-34, android-35, android-36। प्लेटफ़ॉर्म में android.jar होता है — क्लास, विधियों और स्थिरांकों का एक सेट जिसका उपयोग Kotlin/Java कंपाइलर करता है। यदि प्लेटफ़ॉर्म स्थापित नहीं है, तो Gradle पहले बिल्ड पर इसे sdkmanager के माध्यम से स्वचालित रूप से डाउनलोड करेगा।
AGP (Android Gradle Plugin) संस्करण 8.7+ Kotlin DSL में android- उपसर्ग के बिना compileSdk = 36 के माध्यम से compileSdk को पूर्णांक के रूप में निर्दिष्ट करने की अनुशंसा करता है। compileSdk को Groovy DSL में compileSdkVersion 36 के माध्यम से या पूर्वावलोकन SDK संस्करणों (डेवलपर पूर्वावलोकन) के लिए compileSdkPreview के माध्यम से भी सेट किया जा सकता है। compileSdkPreview का उपयोग आधिकारिक रिलीज़ से पहले आगामी API Level के परीक्षण के लिए किया जाता है।
// build.gradle.kts — compileSdkVersion कॉन्फ़िगरेशन
android {
namespace = "com.example.myapp"
// compileSdk = 36 — नवीनतम स्थिर API Level (Android 16)
compileSdk = 36
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 26
targetSdk = 36
versionCode = 1
versionName = "1.0.0"
}
}
// वैकल्पिक: पूर्वावलोकन संस्करणों के लिए compileSdkPreview
// compileSdkPreview = "Baklava"उदाहरण में, compileSdk = 36 सभी Android 16 (Baklava) API तक पहुँच प्रदान करता है। Android SDK Platform 36 को SDK Manager में स्थापित किया जाना चाहिए। "Baklava" नाम के साथ compileSdkPreview का उपयोग आधिकारिक प्लेटफ़ॉर्म रिलीज़ से पहले अस्थिर API के परीक्षण के लिए किया जा सकता है। रिलीज़ के बाद, पूर्वावलोकन को स्थिर compileSdk = 36 से बदल दिया जाता है।
build.gradle में तीन API Level पैरामीटर — compileSdkVersion, targetSdkVersion और minSdkVersion — अक्सर भ्रमित होते हैं। प्रत्येक संगतता के एक अलग पहलू के लिए जिम्मेदार है, और उनके मान compileSdk >= targetSdk >= minSdk नियम का पालन करना चाहिए। minSdk निचली सीमा है: इससे नीचे के डिवाइस एप्लिकेशन नहीं देखेंगे। targetSdk परीक्षण बिंदु है: व्यवहारिक परिवर्तन इस स्तर तक सक्षम होते हैं। compileSdk छत है: इस स्तर से ऊपर के API कंपाइलर के लिए अनुपलब्ध हैं।
मुख्य व्यावहारिक नियम: compileSdk को बिना किसी डिवाइस परीक्षण के बढ़ाया जा सकता है। यह एक सुरक्षित संक्रिया है जो केवल कंपाइलर को android.jar का एक नया संस्करण प्रदान करती है। एकमात्र जोखिम deprecated API हैं जो नए प्लेटफ़ॉर्म संस्करण में हटाए जा सकते हैं, लेकिन यह कंपाइल समय पर पता चल जाता है और आसानी से ठीक हो जाता है। दूसरी ओर, targetSdk बढ़ाने के लिए पूर्ण QA चक्र की आवश्यकता होती है।
| पैरामीटर | कार्यक्षेत्र | रनटाइम को प्रभावित करता है | परीक्षण आवश्यक है |
|---|---|---|---|
| compileSdkVersion | कंपाइलेशन | नहीं | नहीं (केवल deprecated जाँच) |
| targetSdkVersion | रनटाइम | हाँ — व्यवहारिक परिवर्तन | हाँ — पूर्ण QA चक्र |
| minSdkVersion | स्थापना | नहीं | नहीं (लेकिन कवरेज को प्रभावित करता है) |
compileSdk targetSdk से अधिक क्यों हो सकता है? कल्पना करें कि Android 16 (API 36) नए API के साथ जारी किया गया जिसे आप कोड में उपयोग करना चाहते हैं, लेकिन आपने अभी तक API 36 के व्यवहारिक परिवर्तनों का परीक्षण नहीं किया है। आप compileSdk = 36 (नए API उपलब्ध), targetSdk = 35 (API 36 के व्यवहारिक परिवर्तन अक्षम) सेट करते हैं। कोड कंपाइल होगा, SDK_INT जाँच के तहत नई विधियों का उपयोग करेगा, और API 36 के व्यवहारिक परिवर्तन एप्लिकेशन को नहीं तोड़ेंगे क्योंकि targetSdk = 35 है।
compileSdk = 36, targetSdk = 36, minSdk = 26 — नवीनतम API और व्यवहारिक परिवर्तनों के साथ पूर्ण संगतता, 85% डिवाइस कवर। compileSdk = 36, targetSdk = 34, minSdk = 26 — नए API उपलब्ध, व्यवहारिक परिवर्तन केवल API 34 तक। compileSdk = 35, targetSdk = 36 — गलत: compileSdk targetSdk से कम है, API 36 अनुपलब्ध है जबकि 36 के व्यवहारिक परिवर्तन सक्रिय हैं।
compileSdkVersion अपडेट करना Android प्रोजेक्ट में सबसे सरल और सुरक्षित संक्रियाओं में से एक है। targetSdk के विपरीत, इसमें व्यवहारिक परिवर्तनों के व्यापक परीक्षण की आवश्यकता नहीं होती है। हालाँकि, कंपाइलेशन त्रुटियों और deprecated चेतावनियों से बचने के लिए कुछ चरणों का पालन करना आवश्यक है।
चरण 1 — नया प्लेटफ़ॉर्म स्थापित करें Android Studio में SDK Manager के माध्यम से: Tools → SDK Manager → SDK Platforms → नया API Level चुनें। यदि आप प्लेटफ़ॉर्म स्थापित नहीं करते हैं, तो Gradle इसे स्वचालित रूप से डाउनलोड करने का प्रयास करेगा, लेकिन इससे पहला बिल्ड धीमा हो सकता है। चरण 2 — build.gradle में compileSdk को नए मान में बदलें। चरण 3 — बिल्ड करें (Build → Make Project) और किसी भी कंपाइलेशन त्रुटि को ठीक करें।
चरण 4 — deprecated API की जाँच करें। compileSdk बढ़ाने के बाद, कुछ विधियाँ @Deprecated के रूप में चिह्नित हो सकती हैं जिनमें "removed in API X" नोट हो। Android Studio उन्हें स्ट्राइकथ्रू के साथ हाइलाइट करता है और चेतावनी देता है। deprecated कॉल को नए विकल्पों से बदलें। यदि विकल्प के लिए minSdk से अधिक API Level की आवश्यकता है, तो रनटाइम जाँच जोड़ें। चरण 5 — निर्भरताओं की जाँच करें: कुछ लाइब्रेरीज़ को compileSdk के एक विशिष्ट संस्करण की आवश्यकता हो सकती है। AGP 8.7+ compileSdk = 36 की अनुशंसा करता है।
// compileSdk बढ़ाने के बाद: deprecated API बदलना
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.os.Process
import android.app.ActivityManager
class CompileSdkMigration {
// पहले: deprecated विधि (नए API में हटाई जा सकती है)
@Suppress("DEPRECATION")
fun getMemoryClassOld(context: android.content.Context): Int {
val am = context.getSystemService(
android.content.Context.ACTIVITY_SERVICE
) as ActivityManager
return am.memoryClass // API 36 में deprecated हो सकता है
}
// बाद में: नया विकल्प (यदि उपलब्ध हो)
fun getMemoryClassNew(context: android.content.Context): Int {
if (VERSION.SDK_INT >= VERSION_CODES.BAKLAVA) {
// compileSdk 36 से नया API
val am = context.getSystemService(
android.content.Context.ACTIVITY_SERVICE
) as ActivityManager
return am.getMemoryClassSafe() // नए API का उदाहरण
}
@Suppress("DEPRECATION")
return context.getSystemService(
android.content.Context.ACTIVITY_SERVICE
) as ActivityManager
.memoryClass
}
}CompileSdkMigration क्लास सही माइग्रेशन पैटर्न दिखाती है। पुरानी विधि memoryClass को नए API में हटाया जा सकता है — कंपाइलर एक त्रुटि देगा। नया विकल्प getMemoryClassSafe केवल API 36+ पर उपलब्ध है, इसलिए इसे SDK_INT >= BAKLAVA जाँच के तहत कॉल किया जाता है। पुराने डिवाइसों के लिए, @Suppress("DEPRECATION") के साथ फ़ॉलबैक का उपयोग किया जाता है।
नए API जो compileSdkVersion बढ़ाने से उपलब्ध होते हैं, सीधे कॉल नहीं किए जा सकते यदि minSdkVersion उस API Level से कम है। रनटाइम जाँच के बिना, एप्लिकेशन पुराने डिवाइसों पर AbstractMethodError, NoSuchMethodError या VerifyError के साथ क्रैश हो जाएगा। प्राथमिक सुरक्षा तंत्र Build.VERSION.SDK_INT की जाँच करना है, केवल तभी नए API को कॉल करना जब API Level पर्याप्त हो, और पुराने संस्करणों के लिए फ़ॉलबैक प्रदान करना।
AndroidX कई नए API के लिए बैकपोर्ट प्रदान करता है, जिससे कम compileSdk के साथ भी आधुनिक विधियों का उपयोग संभव होता है। उदाहरण के लिए, androidx.activity:activity-ktx:1.9.3 से Activity Result API API 14 से शुरू होने वाले सभी Android संस्करणों पर काम करता है। AndroidX से NotificationCompat पुराने API पर आधुनिक सूचनाओं को सक्षम करता है। PhotoPicker API 34+ से शुरू होकर ActivityResultContracts.PickVisualMedia के माध्यम से उपलब्ध है।
// compileSdk 36 और minSdk 26 के साथ नए API का सुरक्षित कॉल
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.graphics.Color
class NewApiHelper {
// API 36+: रंग के साथ काम करने की नई विधि
fun formatColor(colorInt: Int): String {
if (VERSION.SDK_INT >= VERSION_CODES.BAKLAVA) {
// compileSdk 36 से नया API — API 36+ आवश्यक है
return Color.toArgbHexString(colorInt)
}
// फ़ॉलबैक: पुराने API के लिए मैन्युअल फ़ॉर्मेटिंग
return String.format(
"#%08X", (0xFFFFFFFF toLong() and colorInt.toLong())
)
}
// AndroidX: बैकपोर्ट की आवश्यकता नहीं — SDK_INT जाँच
fun isEdgeToEdgeAvailable(): Boolean {
return VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM
}
}
// Activity में उपयोग
class ColorActivity : android.app.Activity() {
override fun onCreate(savedInstanceState: android.os.Bundle?) {
super.onCreate(savedInstanceState)
val helper = NewApiHelper()
val colorStr = helper.formatColor(0xFF6200EE)
println("Color: $colorStr")
}
}NewApiHelper क्लास पुराने संस्करणों के लिए फ़ॉलबैक फ़ॉर्मेटिंग के साथ नए API Color.toArgbHexString (काल्पनिक API 36) के सुरक्षित कॉल को प्रदर्शित करती है। मुख्य सिद्धांत: compileSdk कोड में नई विधियों को कॉल करने की पहुँच देता है, लेकिन रनटाइम SDK_INT जाँच पुराने डिवाइसों पर क्रैश से बचाती है। SDK_INT जाँच के बिना, minSdk 26 और compileSdk 36 वाला एप्लिकेशन Android 8-15 पर क्रैश हो जाएगा।
Android Gradle Plugin (AGP) Android एप्लिकेशन के लिए प्राथमिक बिल्ड टूल है। प्रत्येक AGP संस्करण compileSdkVersion की एक विशिष्ट सीमा का समर्थन करता है। AGP 8.7.x (2026 में जारी) को compileSdk >= 34 की आवश्यकता है और compileSdk = 36 की अनुशंसा करता है। AGP 8.5.x compileSdk 33-35 का समर्थन करता है। यदि compileSdk AGP के न्यूनतम से कम है, तो बिल्ड त्रुटि के साथ विफल हो जाएगा: "The SDK platform (X) is not supported by this version of the Android Gradle Plugin".
NDK (Native Development Kit) भी compileSdkVersion से जुड़ा है। यदि आपका प्रोजेक्ट NDK के माध्यम से C/C++ में मूल कोड का उपयोग करता है, तो compileSdk हेडर फ़ाइलों और लाइब्रेरीज़ के संस्करण को निर्धारित करता है। NDK r27+ compileSdk 36 की अनुशंसा करता है। .so फ़ाइलों वाली लाइब्रेरीज़ के लिए, compileSdk Application.mk में APP_MIN_SDK_VERSION के माध्यम से मूल कोड के लिए न्यूनतम API Level को प्रभावित करता है।
| AGP संस्करण | न्यूनतम compileSdk | अनुशंसित compileSdk | नोट्स |
|---|---|---|---|
| 8.3.x | 33 | 34 | Android 14 समर्थन |
| 8.5.x | 33 | 35 | Android 15, R8 पूर्ण मोड |
| 8.7.x | 34 | 36 | Android 16, Kotlin 2.1 |
| 8.9.x | 35 | 36 | गैर-संक्रामक R क्लास |
Gradle (7.6+) और Kotlin (2.0+) भी compileSdk संगतता को प्रभावित करते हैं। AGP 8.7+ के लिए Gradle 8.9+ और Kotlin 2.0+ की आवश्यकता है। compileSdk बढ़ाते समय, AGP, Gradle और Kotlin को नवीनतम स्थिर संस्करणों में अपडेट करने की अनुशंसा की जाती है। आधिकारिक Android Gradle Plugin संगतता तालिका में संगतता की जाँच करें।
compileSdkVersion बढ़ाने पर समस्याएँ तीन श्रेणियों में आती हैं: कंपाइलेशन त्रुटियाँ, deprecated चेतावनियाँ और रनटाइम असंगतताएँ। कंपाइलेशन त्रुटियाँ — विधियाँ API से हटा दी जाती हैं और कोड कंपाइल नहीं होता है। Deprecated चेतावनियाँ — विधियाँ @Deprecated चिह्नित होती हैं, कोड चेतावनियों के साथ कंपाइल होता है। रनटाइम असंगतताएँ — नए API कुछ कार्यक्षमता के लिए आवश्यक होते हैं और यदि डिवाइस पर API Level अपर्याप्त है तो त्रुटियाँ उत्पन्न करते हैं।
पहली सामान्य समस्या — "Cannot resolve symbol X"। इसका मतलब है कि कोई क्लास या विधि नए SDK संस्करण में सार्वजनिक API से हटा दी गई है। समाधान: नए प्लेटफ़ॉर्म में कोई विकल्प खोजें या AndroidX समकक्ष का उपयोग करें। उदाहरण के लिए, AsyncTaskLoader क्लास को API 28 में deprecated किया गया था और नए संस्करणों में सार्वजनिक API से हटा दिया गया। विकल्पों में Kotlin Coroutines या WorkManager शामिल हैं।
दूसरी समस्या — विधि हस्ताक्षर परिवर्तन। नए API संस्करण में, कोई विधि अपने पैरामीटर की संख्या या प्रकार बदल सकती है। Kotlin/Java कंपाइलर एक त्रुटि देता है: "None of the following functions can be called with the arguments supplied"। समाधान: नए हस्ताक्षर से मेल खाने के लिए विधि कॉल को अपडेट करें या पुराने डिवाइसों के लिए पुराने हस्ताक्षर कॉल के साथ SDK_INT जाँच जोड़ें।
// compileSdk बढ़ाने पर समस्याओं का समाधान
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.content.pm.PackageManager
class CompileSdkProblemFixer {
// समस्या: विधि hasSystemFeature ने API 36 में हस्ताक्षर बदल दिया
fun hasCamera(pm: PackageManager): Boolean {
return if (VERSION.SDK_INT >= VERSION_CODES.BAKLAVA) {
// नया हस्ताक्षर: hasSystemFeature(String, FeatureType)
pm.hasSystemFeature(
PackageManager.FEATURE_CAMERA,
PackageManager.FEATURE_TYPE_BACK
)
} else {
// पुराना हस्ताक्षर: hasSystemFeature(String)
@Suppress("DEPRECATION")
pm.hasSystemFeature(PackageManager.FEATURE_CAMERA)
}
}
// समस्या: क्लास हटा दी गई, AndroidX समकक्ष का उपयोग करें
fun loadFragment(manager: androidx.fragment.app.FragmentManager) {
// android.app.FragmentManager (हटा दिया गया) के बजाय उपयोग करें
// androidx.fragment.app.FragmentManager
val fragment = CustomFragment()
manager.beginTransaction()
.replace(android.R.id.content, fragment)
.commit()
}
}CompileSdkProblemFixer क्लास सामान्य समस्याओं को हल करती है: hasSystemFeature का बदला हुआ हस्ताक्षर (API 36 में काल्पनिक परिवर्तन) विधि के सही संस्करण को कॉल करने वाली SDK_INT जाँच के माध्यम से संभाला जाता है। हटाई गई क्लास android.app.FragmentManager को उसके AndroidX समकक्ष से बदल दिया जाता है। पुराने कॉल के लिए जहाँ कोई विकल्प नहीं है, @Suppress("DEPRECATION") का उपयोग इसे बनाए रखने के कारण की व्याख्या करने वाली टिप्पणी के साथ किया जाता है।
अक्सर पूछे जाने वाले प्रश्न
compileSdkVersion कोड को कंपाइल करने के लिए उपयोग किया जाने वाला Android SDK संस्करण है। यह निर्धारित करता है कि बिल्ड समय पर डेवलपर के लिए कौन से API उपलब्ध हैं। compileSdk रनटाइम व्यवहार को प्रभावित नहीं करता है — व्यवहारिक परिवर्तन targetSdkVersion द्वारा प्रबंधित किए जाते हैं। compileSdk >= targetSdk और >= minSdk होना चाहिए। compileSdk बढ़ाने से नए API तक पहुँच मिलती है लेकिन deprecated विधियों और AGP संगतता की जाँच की आवश्यकता होती है।
compileSdkVersion कंपाइलेशन को नियंत्रित करता है: कोड में कॉल करने के लिए कौन से API उपलब्ध हैं। targetSdkVersion रनटाइम व्यवहार को नियंत्रित करता है: कौन से व्यवहारिक परिवर्तन लागू होते हैं। compileSdk targetSdk से अधिक हो सकता है — यह नए संस्करण के व्यवहारिक परिवर्तनों को सक्रिय किए बिना कोड में नए API का उपयोग करने की अनुमति देता है। compileSdk हमेशा >= targetSdk होता है। minSdk सबसे निचला पैरामीटर है, targetSdk मध्यम है, compileSdk सबसे ऊँचा है।
2026 में, compileSdk = 36 (Android 16, कोडनेम Baklava) की अनुशंसा की जाती है। यह नवीनतम Android संस्करण के सभी API तक पहुँच प्रदान करता है। लाइब्रेरीज़ और SDK के लिए, आप उपभोक्ताओं को अपग्रेड करने के लिए मजबूर करने से बचने के लिए compileSdk = 35 या 34 का उपयोग कर सकते हैं। compileSdk को SDK Manager के माध्यम से स्थापित किया जाना चाहिए और AGP संस्करण द्वारा समर्थित होना चाहिए। AGP 8.7+ के लिए compileSdk >= 34 आवश्यक है।
compileSdk बढ़ाने के बाद त्रुटियाँ आमतौर पर हटाए गए API के कारण होती हैं: @Deprecated चिह्नित और हटाई गई क्लास या विधियाँ। समाधान: नए SDK में कोई विकल्प खोजें, AndroidX समकक्ष का उपयोग करें, या @SuppressLint जोड़ें। दूसरा कारण मैनिफ़ेस्ट में नई अनिवार्य अनुमतियाँ हैं। तीसरा विधि हस्ताक्षर परिवर्तन है: दस्तावेज़ की जाँच करें और SDK_INT जाँच के साथ कॉल को नए हस्ताक्षर में अपडेट करें।
compileSdkVersion को targetSdk से स्वतंत्र रूप से बढ़ाया जा सकता है। targetSdk = 34 के साथ compileSdk = 36 का कॉन्फ़िगरेशन मान्य है: कोड नए API के साथ कंपाइल होता है, लेकिन API 35-36 के व्यवहारिक परिवर्तन सक्रिय नहीं होते हैं। compileSdk बढ़ाना सुरक्षित है और इसके लिए QA की आवश्यकता नहीं है। targetSdk बढ़ाने के लिए व्यवहारिक परिवर्तनों के पूर्ण परीक्षण चक्र की आवश्यकता होती है। compileSdk को नवीनतम स्थिर API Level पर रखने की अनुशंसा की जाती है।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें