targetSdkVersion: মূল ধারণা, আচরণগত পরিবর্তন এবং Google Play

Android-এ targetSdkVersion কী?

targetSdkVersion build.gradle-এ একটি পূর্ণসংখ্যা প্যারামিটার যা API Level ঘোষণা করে যার against অ্যাপ পরীক্ষিত হয়েছে। Android সিস্টেম এই প্যারামিটার ব্যবহার করে সিদ্ধান্ত নেয় যে runtime-এ অ্যাপে কোন behavioural changes প্রয়োগ করতে হবে। যদি targetSdkVersion = 33 হয়, Android API 33 পর্যন্ত অন্তর্ভুক্ত সকল behavioural changes প্রয়োগ করে, কিন্তু API 34+-এর পরিবর্তনগুলি প্রয়োগ করে না। targetSdkVersion = 34 হলে — API 34 পর্যন্ত পরিবর্তনগুলি প্রয়োগ হয়, এবং এভাবেই চলতে থাকে।

targetSdkVersion এবং minSdkVersion-এর মধ্যে মূল পার্থক্য হলো কর্মপদ্ধতি। minSdk ইনস্টলেশনের সময় একবার পরীক্ষা করা হয় এবং শর্ত পূরণ না হলে ইনস্টলেশন ব্লক করে। targetSdkVersion প্রতিটি ডিভাইসে সিস্টেমের runtime আচরণকে প্রভাবিত করে, অ্যাপ Android-এর কোন ভার্সনে চলছে তা নির্বিশেষে। targetSdk 31-যুক্ত একই অ্যাপ Android 13, 14 এবং 15-এ ভিন্ন আচরণ করবে, কারণ 31-এর উপরের behavioural changes নিষ্ক্রিয়।

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-এর সকল behavioural changes সক্রিয় করে। কোড context.applicationInfo.targetSdkVersion-এর মাধ্যমে targetSdkVersion পরীক্ষা করে — এটি গতিশীলভাবে নির্ধারণ করতে দেয় কোন সামঞ্জস্য মোড সক্রিয়। সহায়ক ফাংশনটি লাইব্রেরিগুলির জন্য উপযোগী যা কলিং অ্যাপ্লিকেশনের targetSdk-এর সাথে খাপ খাইয়ে নিতে হবে।

Behavioural Changes: targetSdk অ্যাপকে কীভাবে প্রভাবিত করে

Behavioural changes হলো Android সিস্টেম আচরণের পরিবর্তন যা শুধুমাত্র targetSdkVersion >= একটি নির্দিষ্ট API Level-যুক্ত অ্যাপগুলিতে প্রয়োগ করা হয়। প্রতিটি নতুন প্রধান Android রিলিজ behavioural changes প্রবর্তন করে, এবং যদি একটি অ্যাপ targetSdk আপডেট না করে, এই পরিবর্তনগুলি কার্যকর হয় না। এই প্রক্রিয়াটি ডেভেলপারদের নতুন OS রিলিজের সাথে সিঙ্ক্রোনাসভাবে নয়, বরং নিজস্ব গতিতে অ্যাপ আপডেট করতে দেয়।

Scoped Storage (API 29) সবচেয়ে গুরুত্বপূর্ণ behavioural changes-এর একটি। 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 একটি পূর্ণসংখ্যা ফেরত দেয়। বিশ্লেষণের জন্য, প্রতিটি সেশনে কোন behavioural changes প্রকৃতপক্ষে সক্রিয় তা বোঝার জন্য 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-এ সংখ্যা পরিবর্তন করা নয়। কোড আগে থেকে প্রস্তুত না করা হলে প্রতিটি behavioural change বিদ্যমান কার্যকারিতা ভেঙে দিতে পারে। Google Play-র সময়সীমার 3-6 মাস আগে প্রস্তুতি শুরু করার পরামর্শ দেওয়া হয়, বিশেষ করে যদি অ্যাপ বড় হয় এবং অনেক সিস্টেম API ব্যবহার করে।

ধাপে ধাপে প্রক্রিয়া: ধাপ 1 — Android Developers ডকুমেন্টেশন-এ (পৃষ্ঠা "Behavioural Changes by API Level") নতুন API Level-এর জন্য behavioural changes অধ্যয়ন করুন। ধাপ 2 — targetSdk-update ব্রাঞ্চ তৈরি করুন এবং targetSdk নতুন মানে পরিবর্তন করুন। ধাপ 3 — নতুন API Level-যুক্ত এমুলেটর বা ডিভাইসে অ্যাপ চালান এবং পরিবর্তনগুলির সাথে সম্পর্কিত প্রতিটি বৈশিষ্ট্য পরীক্ষা করুন। ধাপ 4 — ত্রুটিগুলি ঠিক করুন: অনুমতি যোগ করুন, ফাইল হ্যান্ডলিং পরিবর্তন করুন, ম্যানিফেস্ট আপডেট করুন।

ধাপ 5 — পুরোনো ডিভাইসে পরীক্ষা করুন। targetSdk বাড়ানো নতুন targetSdk-এর চেয়ে কম API Level-যুক্ত ডিভাইসগুলিকে প্রভাবিত করে না, কিন্তু behavioural changes API Level >= targetSdk-যুক্ত সকল ডিভাইসে প্রয়োগ হয়। আপনি যদি targetSdk 33 থেকে 34-এ বাড়ান, API 34+-যুক্ত ডিভাইসে API 34-এর behavioural changes সক্রিয় হবে। 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
        }
    }

    // পরীক্ষা: কোন behavioural changes সক্রিয়
    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 ফাংশন behavioural changes পরীক্ষার সঠিক প্যাটার্ন দেখায়: আপনাকে ডিভাইসের SDK_INT এবং অ্যাপের targetSdk উভয়ই পরীক্ষা করতে হবে। শুধুমাত্র যখন উভয় শর্ত মিলে তখন পরিবর্তনটি প্রকৃতপক্ষে সক্রিয়।

Android 15 (API 35): মূল behavioural changes

Android 15 (API 35, Vanilla Ice Cream) বেশ কয়েকটি গুরুত্বপূর্ণ behavioural changes প্রবর্তন করে যা ডেভেলপারদের 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-এর দুটি সবচেয়ে গুরুত্বপূর্ণ behavioural changes। বিজ্ঞাপন SDK-কে Topics API এবং Attribution Reporting-এ স্থানান্তর করতে হবে। অ্যালার্ম এবং রিমাইন্ডারযুক্ত অ্যাপগুলির জন্য — অনুমতি ডায়ালগের জন্য UX অভিযোজন। এই পরিবর্তনগুলি উপেক্ষা করলে Android 15-এ runtime-এ অ্যাপ ক্র্যাশ বা ভাঙা বিজ্ঞাপন নগদীকরণ হবে।

targetSdk এবং compileSdk-এর মধ্যে পার্থক্য

targetSdkVersion এবং compileSdkVersion-এর মধ্যে পার্থক্য Android ডেভেলপারদের মধ্যে বিভ্রান্তির সবচেয়ে সাধারণ উৎসগুলির মধ্যে একটি। compileSdkVersion হলো SDK-এর ভার্সন যার against কোড কম্পাইল করা হয়। এটি নির্ধারণ করে কম্পাইল সময়ে কোন API উপলব্ধ, কিন্তু runtime আচরণকে প্রভাবিত করে না। targetSdkVersion হলো ভার্সন যার against অ্যাপ পরীক্ষিত — এটি নির্ধারণ করে runtime-এ কোন behavioural changes প্রয়োগ হয়। compileSdk targetSdk-এর থেকে বেশি বা সমান হতে পারে এবং হওয়া উচিত।

নিয়মটি সহজ: compileSdk >= targetSdk >= minSdk। compileSdk সাধারণত সর্বশেষ স্থিতিশীল API Level-এর সমান (2026-এ — 36)। targetSdk যতটা সম্ভব বেশি হওয়া উচিত যেসব ভার্সন আপনি পরীক্ষা করেছেন সেগুলির মধ্যে। minSdk সর্বাধিক পৌঁছানোর জন্য যতটা সম্ভব কম হওয়া উচিত। compileSdk বাড়ানোর জন্য behavioural changes পরীক্ষার প্রয়োজন নেই — এটি শুধুমাত্র কম্পাইলারের জন্য নতুন API-তে অ্যাক্সেস খোলে। targetSdk বাড়ানোর জন্য সকল behavioural changes-এর সম্পূর্ণ পরীক্ষা চক্র প্রয়োজন।

ব্যবহারিক ক্ষেত্রে: আপনি যদি Android 16 (API 36) থেকে নতুন API ব্যবহার করতে চান কিন্তু API 36-এর behavioural changes পরীক্ষা না করে থাকেন, compileSdk = 36, targetSdk = 35 সেট করুন। কোড নতুন API-এর সাথে কম্পাইল হবে, কিন্তু API 36-এর behavioural changes প্রয়োগ হবে না। একবার আপনি সমস্ত পরিবর্তন পরীক্ষা করলে — targetSdk 36-এ বাড়ান।