targetSdkVersion: mga pangunahing konsepto, behavioural changes at Google Play

Ano ang targetSdkVersion sa Android?

targetSdkVersion — isang integer parameter sa build.gradle na nagdedeklara ng API Level kung saan nasubukan ang app. Ginagamit ng Android system ang parameter na ito upang magpasya kung aling behavioural changes ang ilalapat sa app sa panahon ng pagpapatupad. Kung ang targetSdkVersion = 33, inilalapat ng Android ang lahat ng behavioural changes na ipinakilala hanggang sa API 33 kasama, ngunit hindi inilalapat ang mga pagbabago sa API 34+. Kung ang targetSdkVersion = 34 — inilalapat ang mga pagbabago hanggang API 34, at iba pa.

Ang pangunahing pagkakaiba sa pagitan ng targetSdkVersion at minSdkVersion — mekanismo ng pagkilos. Ang minSdk ay sinusuri nang isang beses sa pag-install at hinaharangan ang pag-install kung hindi natugunan ang kondisyon. Ang targetSdkVersion ay nakakaapekto sa runtime na gawi ng system sa bawat device, anuman ang bersyon ng Android kung saan pinapatakbo ang app. Ang parehong app na may targetSdk 31 ay mag-iiba ang gawi sa Android 13, 14 at 15, dahil ang behavioural changes na higit sa 31 ay naka-disable.

Ang mekanismo ng targetSdkVersion — ay isang tool para sa backward compatibility na naka-embed sa Android. Kung wala ito, ang bawat pag-update ng OS ay sisirain ang libu-libong lumang app. Ipinakilala ng Google ang mekanismong ito sa Android 2.1 (API Level 7) at mula noon ay ginagamit ito bilang karaniwang paraan ng pagpapakilala ng mga bagong panuntunan sa seguridad, privacy, at pamamahala ng resource nang hindi nakakaabala sa paggana ng mga umiiral na app.

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Nasubukan sa Android 16
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Pagsusuri ng kasalukuyang targetSdk sa code
fun isUsingScopedStorage(): Boolean {
    // Ang Context.getApplicationInfo().targetSdkVersion ay naglalaman ng targetSdk ng app
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Sa halimbawa, ang targetSdk = 36 ay nag-a-activate ng lahat ng behavioural changes ng Android 16. Sinusuri ng code ang targetSdkVersion sa pamamagitan ng context.applicationInfo.targetSdkVersion — pinapayagan nito ang dynamic na pagtukoy kung aling compatibility mode ang naka-enable. Ang helper function ay kapaki-pakinabang para sa mga library na kailangang umangkop sa targetSdk ng tumatawag na app.

Behavioural Changes: paano naaapektuhan ng targetSdk ang app

Behavioural changes — ay mga pagbabago sa gawi ng Android system na inilalapat lamang sa mga app na may targetSdkVersion >= isang partikular na API Level. Ang bawat bagong major release ng Android ay nagpapakilala ng behavioural changes, at kung hindi ina-update ng app ang targetSdk, ang mga pagbabagong ito ay hindi magkakabisa. Ang ganitong mekanismo ay nagpapahintulot sa mga developer na i-update ang app sa kanilang sariling bilis, hindi kasabay ng paglabas ng bagong bersyon ng OS.

Scoped Storage (API 29) — isa sa pinakamahalagang behavioural changes. Ang mga app na may targetSdk 29+ ay hindi makakakuha ng direktang File access sa mga shared directory na Pictures, Downloads, Music, Documents. Sa halip, ginagamit ang MediaStore para sa multimedia, SAF (Storage Access Framework) para sa mga arbitrary file, at getExternalFilesDir() para sa sariling storage. Ang mga lumang app na may targetSdk 28 pababa ay patuloy na gumagana sa lumang Full Storage Access, ngunit ito ay lumilikha ng banta sa seguridad.

POST_NOTIFICATIONS (API 33) — runtime permission para sa pagpapadala ng mga notification. Ang mga app na may targetSdk 33+ ay dapat humingi ng permission na Manifest.permission.POST_NOTIFICATIONS mula sa user sa pamamagitan ng standard na dialog. Kung hindi ibinigay ang permission, ang NotificationManager.silent() ay hindi nagpapakita ng mga notification sa user. Sa Android 13+ nang walang permission na ito, ang mga push notification at lokal na notification ay hindi lang ipinapakita, na maaaring makabuluhang bawasan ang pakikipag-ugnayan ng user.

Paano suriin ang kasalukuyang targetSdk

Ang halaga ng targetSdkVersion ng app ay maaaring makuha sa pamamagitan ng ADB: ang command na adb shell dumpsys package com.example.myapp | grep targetSdk ay nagpapakita ng targetSdk=34. Sa code, ang context.getApplicationInfo().targetSdkVersion ay nagbabalik ng integer. Para sa analytics, kapaki-pakinabang na i-log ang targetSdk kasama ng android.os.Build.VERSION.SDK_INT upang maunawaan kung aling behavioural changes ang aktwal na aktibo sa bawat session.

Mga kinakailangan ng Google Play para sa targetSdkVersion (2026)

Google Play ay nagtatakda ng mga mandatoryong kinakailangan para sa targetSdkVersion para sa lahat ng nai-publish na app. Mula Agosto 2024, minimum targetSdk = 33 (Android 13). Mula Agosto 2025 — targetSdk = 34. Inaasahan na mula Agosto 2026 ay hihilingin ng Google ang targetSdk = 35 (Android 15). Ang mga bagong app at update ng mga umiiral na app ay dapat matugunan ang mga kinakailangang ito, kung hindi ay haharangin ng console ang publikasyon. Ito ay patakaran ng Google Play, hindi limitasyon ng Android Runtime: isang app na may targetSdk 34 ay maaaring tumakbo sa Android 16, ngunit hindi maaaring i-publish sa Play Store.

Android App Bundle (AAB) — ang mandatoryong format ng publikasyon mula noong Agosto 2021. Ang APK ay hindi na tinatanggap sa Google Play (exception — mga app na may sukat > 150 MB at ilang legacy projects). Ang format na AAB ay nagpapahintulot sa Google na bumuo ng mga na-optimize na APK para sa bawat API Level at density ng screen, na binabawasan ang laki ng pag-download ng 15-30%. Para suriin ang targetSdk, sinusuri ng Google Play ang AAB manifest at kung hindi tugma, nagpapakita ng error na may indikasyon ng minimum na kinakailangang halaga.

Sinusuri ng Google Play Console ang targetSdkVersion hindi lamang kapag nag-a-upload ng bagong AAB, kundi pati na rin kapag nag-a-update ng umiiral na app. Kung ang iyong app ay may targetSdk 33 at itinaas ng Google ang minimum na threshold sa 34 — hindi ka makakapaglabas ng anumang update hangga't hindi mo itinaas ang targetSdk. Para sa mga app na matagal nang hindi na-update, maaaring awtomatikong alisin ng Google Play ang mga ito sa publikasyon (unpublish).

Paano i-update ang targetSdkVersion nang walang error

Pag-update ng targetSdkVersion — hindi lamang pagbabago ng numero sa build.gradle. Ang bawat behavioural change ay maaaring makasira ng umiiral na functionality kung ang code ay hindi handa nang maaga. Inirerekomenda na simulan ang paghahanda 3-6 na buwan bago ang deadline ng Google Play, lalo na kung malaki ang app at gumagamit ng maraming system API.

Hakbang-hakbang na proseso: Hakbang 1 — pag-aralan ang behavioural changes para sa bagong API Level sa dokumentasyon ng Android Developers (pahina "Behavioural Changes by API Level"). Hakbang 2 — lumikha ng branch na targetSdk-update at baguhin ang targetSdk sa bagong halaga. Hakbang 3 — patakbuhin ang app sa isang emulator o device na may bagong API Level at suriin ang bawat functionality na nauugnay sa mga pagbabago. Hakbang 4 — ayusin ang mga error: magdagdag ng mga permission, baguhin ang pagtatrabaho sa mga file, i-update ang manifest.

Hakbang 5 — subukan sa mga lumang device. Ang pagtaas ng targetSdk ay hindi nakakaapekto sa mga device na may API Level na mas mababa kaysa sa bagong targetSdk, ngunit ang behavioural changes ay inilalapat sa lahat ng device na may API Level >= targetSdk. Kung itinaas mo ang targetSdk mula 33 hanggang 34, sa mga device na may API 34+ ay mag-a-activate ang behavioural changes ng API 34. Sa mga device na may API 33, walang magbabago.

// Paghahanda para sa 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? {
        // Pinaghihigpitan ng Privacy Sandbox ang Advertising ID mula sa API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — hindi available ang identifier, gamitin ang MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Pagsusuri: aling behavioural changes ang aktibo
    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")
        }
    }
}

Ang klase na AdsManager ay nagpapakita ng paghahanda para sa Privacy Sandbox (API 35). Ang Advertising ID ay hindi na available simula sa API 35 na may targetSdk 35+. Ang function na getActiveChanges ay nagpapakita ng tamang pattern para sa pagsusuri ng behavioural changes: parehong SDK_INT ng device at targetSdk ng app ay dapat suriin nang sabay-sabay. Kapag natugunan lamang ang parehong kondisyon, ang pagbabago ay aktwal na aktibo.

Android 15 (API 35): mga pangunahing behavioural changes

Android 15 (API 35, Vanilla Ice Cream) ay nagpapakilala ng ilang kritikal na behavioural changes na dapat isaalang-alang ng mga developer kapag ina-update ang targetSdk sa 35. Una — Privacy Sandbox for Android. Ito ay inisyatiba ng Google na palitan ang Advertising ID ng mas pribadong API: Topics API (mga interes ng user), Protected Audience (remarketing), at Attribution Reporting (mga conversion). Mula sa API 35, ang Advertising ID ay hindi na isang matatag na identifier at maaaring magbalik ng zero value.

Pangalawang pagbabago — Foreground Service Types (API 34, ipinagpatuloy sa API 35). Simula sa API 34, ang bawat app na may targetSdk 34+ ay dapat tukuyin ang uri ng foreground service sa manifest: dataSync, systemExempted, shortService, location, mediaPlayback at iba pa. Kung wala ito, ang system ay bumubuo ng ForegroundServiceTypeNotAllowedException. Sa API 35, idinagdag ang bagong uri na health at pinahigpit ang pagsusuri ng mga umiiral na uri. Lahat ng foreground service ay dapat suriin.

Pangatlong pagbabago — paghihigpit sa SCHEDULE_EXACT_ALARM. Simula sa API 35, ang mga app na may targetSdk 35+ ay hindi maaaring gumamit ng SCHEDULE_EXACT_ALARM nang walang malinaw na pahintulot ng user. Ang system ay nagpapakita ng dialog, at dapat aprubahan ng user ang eksaktong pag-iskedyul. Para sa mga alarm at timer, ito ay nangangahulugan ng karagdagang hakbang sa UX. Alternatibo — gumamit ng inexact alarm na may 10 minutong reserba.

// Android 15 (API 35): pagsusuri ng 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+: nangangailangan ng pahintulot ng user
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Sa ilalim ng API 35 — eksaktong alarm ay available nang walang pahintulot
        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 at paghihigpit sa alarm — dalawang pinakamahalagang behavioural changes ng API 35. Para sa mga advertising SDK, kakailanganin ang migration sa Topics API at Attribution Reporting. Para sa mga app na may alarm at paalala — adaptasyon ng UX sa ilalim ng permission dialog. Ang pagwawalang-bahala sa mga pagbabagong ito ay hahantong sa pag-crash ng app sa runtime sa Android 15 o sa hindi paggana ng monetization sa advertising.

Pagkakaiba sa pagitan ng targetSdk at compileSdk

Pagkakaiba sa pagitan ng targetSdkVersion at compileSdkVersion — isa sa mga pinakamadalas na pinagkukunan ng kalituhan sa mga Android developer. Ang compileSdkVersion — ay ang bersyon ng SDK kung saan naka-compile ang code. Tinutukoy nito kung aling mga API ang available sa panahon ng compilation, ngunit hindi nakakaapekto sa runtime na gawi. Ang targetSdkVersion — ay ang bersyon kung saan nasubukan ang app, tinutukoy nito kung aling behavioural changes ang inilalapat sa runtime. Ang compileSdk ay maaari at dapat na mas mataas o katumbas ng targetSdk.

Ang patakaran ay simple: compileSdk >= targetSdk >= minSdk. Ang compileSdk ay karaniwang katumbas ng huling stable na API Level (sa 2026 — 36). Ang targetSdk ay dapat na kasingtaas hangga't maaari sa mga bersyong nasubukan na. Ang minSdk ay dapat na kasingbaba hangga't maaari para sa maximum na coverage. Ang pagtaas ng compileSdk ay hindi nangangailangan ng pagsubok ng behavioural changes — binubuksan lamang nito ang access sa mga bagong API para sa compiler. Ang pagtaas ng targetSdk ay nangangailangan ng buong ikot ng pagsubok ng lahat ng behavioural changes.

Sa praktika: kung gusto mong gumamit ng bagong API mula sa Android 16 (API 36), ngunit hindi mo pa nasusubukan ang behavioural changes ng API 36, itakda ang compileSdk = 36, targetSdk = 35. Ang code ay mako-compile gamit ang mga bagong API, ngunit hindi ilalapat ang behavioural changes ng API 36. Kapag nasubukan mo na ang lahat ng pagbabago — itaas ang targetSdk sa 36.