SDK Platform: ano ito, mga bersyon at Android SDK Manager

Ano ang SDK Platform

SDK Platform — ay isang pangunahing component ng Android SDK, na kumakatawan sa isang kumpletong set ng mga library at tool para sa pag-develop ng mga app sa ilalim ng isang partikular na bersyon ng Android. Ang bawat platform ay tinutukoy ng API Level — isang integer na tumataas sa paglabas ng mga bagong bersyon ng OS. Halimbawa, ang Android 13 ay tumutugma sa API Level 33, Android 14 — API Level 34, Android 15 — API Level 35.

Hindi tulad ng Android Studio (IDE), ang SDK Platform ay hindi naglalaman ng code editor o debugger. Ito ay isang system layer na kumokonekta sa compiler at builder. Kapag ang developer ay sumulat ng import android.app.Activity, kinukuha ng compiler ang klase na ito mula sa android.jar ng partikular na SDK Platform. Kung walang naka-install na platform na may kinakailangang API Level, hindi magko-compile ang code.

Ang Google ay naglalabas ng bagong SDK Platform para sa bawat stable na bersyon ng Android. Ang kasaysayan ay sumasaklaw ng higit sa 35 API Level — mula sa Android 1.0 (API 1) hanggang Android 15 (API 35). Ang bawat platform ay backward compatible: ang code na isinulat para sa API Level 21 ay gagana sa API Level 35, ngunit hindi ang kabaligtaran.

Bakit kailangan ng hiwalay na SDK Platform para sa bawat bersyon

Ang Android ay mabilis na umuunlad: bawat bersyon ay nagdaragdag ng mga bagong API, nagbabago ng behavior ng mga umiiral na, at nagpapakilala ng mga paghihigpit. Halimbawa, Android 10 (API 29) ay nagpakilala ng Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — mandatoryong BroadcastReceiver flag. Ang developer ay dapat bumuo ng app laban sa kasalukuyang platform upang magamit ang mga kakayahang ito.

Kasabay nito, ang app ay maaaring tumakbo sa mga lumang bersyon ng OS. Para dito, sa Gradle ay tinutukoy ang minSdk — ang pinakamababang API Level kung saan tumatakbo ang app. Ang code ay gumagamit ng mga version check at conditional API calls. Ang pamamaraang ito ay nagsisiguro ng compatibility nang hindi nawawala ang mga bagong feature.

Komposisyon ng SDK Platform: mga pangunahing component

Ang SDK Platform — ay hindi isang file, kundi isang set ng mga component na magkakasamang nagbibigay-daan sa pag-compile, pag-build, at pag-test ng app. Ang pangunahing elemento ay android.jar — isang archive na may mga klase ng Android API na kasama sa bersyong ito. Ang file na ito ay kumokonekta sa Kotlin o Java compiler at tinutukoy kung anong mga klase, metodo, at annotation ang available sa developer.

System image at emulator

Ang bawat SDK Platform ay may kasamang System Image — image ng operating system para sa Android Virtual Device emulator. Kung walang kaukulang image, hindi magagawang simulan ng emulator ang isang virtual device na may kinakailangang API Level. Ang System Images ay may iba't ibang uri: Google APIs (may mga serbisyo ng Google), Google Play (may Play Store) at AOSP (purong Android na walang serbisyo ng Google).

Mga tool sa pag-build at debug

Ang SDK Platform ay may kasamang bersyon ng Build-Tools at Platform-Tools na na-optimize para sa API Level na ito. Ang Build-Tools ay naglalaman ng aapt2 (Android Asset Packaging Tool), dx/d8 (Dalvik/ART compiler) at ApkSigner. Ang Platform-Tools ay nagbibigay ng ADB (Android Debug Bridge), fastboot at SQLite. Ang mga tool na ito ay ina-update nang hiwalay sa SDK Platform sa pamamagitan ng SDK Manager.

Mga resources ng platform

Ang bawat platform ay may kasamang standard na Android resources — system theme, style, animation, kulay, at laki. Ang mga resources na ito ay ginagamit sa pag-compile: kung ang developer ay tumutukoy sa @android:style/Theme.Material.Light, kinukuha ng builder ang definition mula sa SDK Platform resources. Ito ay ginagarantiyahan ang pare-parehong hitsura ng mga system component sa lahat ng device.

API Level at mga bersyon ng SDK Platform

API Level — ay isang integer identifier ng bersyon ng Android SDK. Ang bawat release ng Android ay may isang API Level na monotonically tumataas. Tinutukoy ng developer ang API Level sa tatlong pangunahing parameter ng build.gradle: compileSdk, minSdk, at targetSdk. Ang pagpili ng mga parameter na ito ay nagdidikta kung aling mga API ang available at kung paano pinoproseso ng system ang app.

Inirerekomenda ng Google na panatilihin ang minSdk na hindi mas mababa sa kasalukuyang threshold ng distribusyon — ayon sa Android Studio Distribution Dashboard (2026), humigit-kumulang 95% ng mga device ay tumatakbo sa Android 8.0 (API 26) at mas mataas. Ang compileSdk ay dapat ang pinakabagong stable — nagbibigay ito ng access sa mga bagong API at pinapayagan ang lint checks na matukoy ang mga lumang metodo.

Ebolusyon ng API Level: mga pangunahing pagbabago

Sa bawat bagong API Level, ang Google ay nagpapakilala ng makabuluhang pagbabago. Ang Android 6.0 (API 23) ay nagdagdag ng runtime permissions — ang app ay humihingi ng pahintulot sa runtime, hindi sa pag-install. Ang Android 8.0 (API 26) ay nagpakilala ng auto-fill ng forms at notification channels. Android 12 (API 31) ay radikal na nagbago ng approach sa intents — lumitaw ang SplashScreen API at pag-export ng component sa pamamagitan ng exported attribute. Android 14 (API 34) ay nag-mandate ng pagtukoy ng mga flag para sa BroadcastReceiver at nagpakilala ng mahigpit na limitasyon sa foreground services.

Ang pag-unawa sa kasaysayan ng API Level ay tumutulong sa developer na pumili ng tamang compatibility strategy. Kung ang app ay gumagamit ng compileSdk 35 ngunit minSdk 26, ang code ay maaaring tumawag ng mga metodo ng API 35 pagkatapos lamang ng version check sa pamamagitan ng Build.VERSION.SDK_INT. Ang approach na ito ay tinatawag na version-gated development at ito ang pamantayan ng industriya.

SDK Manager: pag-install at configuration

SDK Manager — ay isang tool para sa pamamahala ng mga component ng Android SDK: pag-install ng mga bagong SDK Platform, pag-update ng mga umiiral na, at pagtanggal ng mga luma. Ang SDK Manager ay available bilang graphical interface sa Android Studio at command line sa pamamagitan ng sdkmanager. Sa pamamagitan ng command line, ang SDK Manager ay maginhawang gamitin sa CI/CD pipelines kung saan walang graphical interface.

Ang SDK Manager ay nag-i-install ng mga platform sa direktoryo ng Android SDK, na bilang default ay nasa $HOME/Android/Sdk sa Linux at macOS o %LOCALAPPDATA%\Android\Sdk sa Windows. Sa loob ng direktoryo ng platforms ay may mga folder na pinangalanang android-{API Level}, bawat isa ay naglalaman ng kumpletong SDK Platform.

Pag-install ng SDK Platform sa pamamagitan ng sdkmanager

Ang command na sdkmanager ay tumatanggap ng package identifier sa format na "platforms;android-{API}". Halimbawa, para i-install ang SDK Platform 35, ang command ay ganito:

# I-install ang SDK Platform para sa API Level 35
sdkmanager "platforms;android-35"

# Mag-install ng maraming platform sa isang command
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Listahan ng mga naka-install na platform
sdkmanager --list_installed | grep platforms

# Tanggalin ang lumang platform
sdkmanager --uninstall "platforms;android-28"

Awtomatikong pag-install sa pamamagitan ng Gradle

Ang mga modernong Android project ay gumagamit ng Gradle Plugin na maaaring awtomatikong mag-install ng SDK Platform sa unang build. Para dito, kailangan mong tukuyin ang compileSdk sa build.gradle at idagdag ang SDK directory sa lokal na configuration. Ang Android Studio ay nag-aalok din na i-install ang nawawalang platform kapag nagbukas ng project — pindutin lamang ang "Install SDK Platform" na button sa Gradle sync window.

Mahalagang regular na i-update ang SDK Platform sa pamamagitan ng SDK Manager — kasama ng platform, ang Build-Tools at Platform-Tools ay ina-update din, na nakakaapekto sa build performance at debug stability. Inirerekomenda ng Google na suriin ang mga update ng SDK tuwing 2–3 linggo, lalo na bago mag-publish ng bagong bersyon ng app sa Google Play.

Configuration ng system image para sa emulator

Para patakbuhin ang emulator na may partikular na API Level, kailangan mong i-install ang System Image ng parehong bersyon. Ang SDK Manager ay nagpapahintulot sa pag-download ng mga image ng iba't ibang architecture (x86_64, arm64-v8a) at uri (Google APIs, Google Play, AOSP). Pagkatapos i-download ang image, ang AVD Manager ay gumagawa ng virtual device batay dito.

# I-install ang System Image na may Google APIs para sa API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Gumawa ng AVD sa pamamagitan ng command line
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Listahan ng mga ginawang AVD
avdmanager list avd

compileSdk, targetSdk at minSdk sa Gradle

Tatlong parameter sa build.gradle ang tumutukoy kung paano gumagana ang app sa SDK Platform. compileSdk — API Level na ginagamit para sa pag-compile. Ang parameter na ito ay tumutukoy kung aling mga Android API class ang available sa code. Ang compileSdk ay dapat ang pinakabago sa tatlo at hindi nakakaapekto sa runtime behavior — ang app ay nagko-compile ngunit gumagamit lamang ng mga API na nasa device.

minSdk — ang pinakamababang API Level kung saan maaaring i-install ang app. Hindi papayagan ng Google Play ang pag-install ng app sa isang device na may bersyong mas mababa sa minSdk. Ang parameter na ito ay tumutukoy sa compatibility threshold at nakakaapekto sa audience coverage. Kung mas mababa ang minSdk, mas maraming device ang sinusuportahan, ngunit mas kaunting bagong API ang magagamit nang walang checks.

targetSdk — API Level kung saan nasubukan ang app. Ginagamit ng Android system ang targetSdk para mag-apply ng behavioral changes: kung ang app ay hindi na-update sa bagong API Level, ang system ay nag-a-activate ng compatibility mode para sa mga lumang bersyon. Ang Google Play ay nangangailangan ng targetSdk na hindi mas mababa sa isang partikular na antas — para sa 2026 ito ay API 34 (Android 14).

Halimbawa ng Gradle configuration

android {
    compileSdk 35

    defaultConfig {
        applicationId "com.example.app"
        minSdk 26
        targetSdk 35
        versionCode 1
        versionName "1.0"
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
}

// Ang bersyon ng Android SDK ay dapat na naka-install sa pamamagitan ng SDK Manager
// sdkmanager "platforms;android-35"

Paano pumili ng compileSdk, minSdk at targetSdk

Ang diskarte sa pagpili ay depende sa mga layunin ng proyekto. Para sa bagong app: compileSdk — pinakabagong stable (35 sa simula ng 2026), minSdk — API 26 (Android 8.0, sumasaklaw sa 95% ng mga device), targetSdk — pinakabagong stable. Para sa pag-update ng umiiral na app: itaas ang compileSdk agad, targetSdk — pagkatapos ng pagsubok sa lahat ng behavioral changes, minSdk — kung kinakailangan lamang na iwanan ang mga lumang device.

Ang Google ay nangangailangan na ang targetSdk ay ma-update sa loob ng isang taon pagkatapos ng paglabas ng bagong bersyon ng Android. Ang mga app na hindi nakakatugon sa kinakailangang ito ay hindi maaaring mag-publish ng mga update sa Google Play. Para subaybayan ang mga deadline, gamitin ang opisyal na kalendaryo ng Android OS updates.

Mga halimbawa ng paggamit ng SDK Platform sa code

Kapag nagde-develop para sa iba't ibang bersyon ng Android, kailangang isaalang-alang ang availability ng API. Kung ang app ay gumagamit ng compileSdk 35 ngunit tumatakbo sa isang device na may API 31, ang pagtawag sa mga metodong idinagdag sa API 34 ay magdudulot ng NoSuchMethodError o AbstractMethodError. Para sa ligtas na pagtawag ng mga bagong API, ginagamit ang version checks sa pamamagitan ng Build.VERSION.SDK_INT.

Pagsusuri ng API Level sa runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Ang Notification channels ay available mula sa API 26
            val channel = NotificationChannel(
                "updates",
                "Mga Update",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Paggamit ng mga bagong API na may @RequiresApi

Para sa mga metodong tinatawag lamang sa partikular na bersyon, gamitin ang @RequiresApi annotation. Ito ay nagsasabi sa lint checks na ang metodo ay ligtas at nagdi-disable ng mga babala. Kasama ng SDK_INT check, ginagawang mas malinis at mas naiintindihan ng mga reviewer ang code ng annotation.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact na may flag na SCHEDULE_EXACT_ALARM
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Humihiling ng pahintulot na SCHEDULE_EXACT_ALARM
        val intent = Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM)
        context.startActivity(intent)
    }
}

fun safeScheduleAlarm(context: Context, triggerTime: Long) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        scheduleExactAlarm(getAlarmManager(context), triggerTime)
    } else {
        // Lumang metodo setExact nang walang pagsusuri ng pahintulot
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Pagtukoy sa naka-install na SDK Platform

Minsan kailangang malaman kung anong bersyon ng SDK Platform ang naka-install sa device ng developer o sa CI. Ito ay maaaring gawin sa pamamagitan ng ADB o programmatically sa code ng app. Ang pag-alam sa API Level ng device ay tumutulong sa pag-test ng version-specific na behavior.

fun logDeviceInfo() {
    with (Build.VERSION) {
        Log.d("SDK_Demo", "SDK_INT: $SDK_INT")
        Log.d("SDK_Demo", "RELEASE: $RELEASE")
        Log.d("SDK_Demo", "CODENAME: $CODENAME")
        Log.d("SDK_Demo", "PREVIEW_SDK_INT: $PREVIEW_SDK_INT")
    }
    // Output: SDK_INT: 35, RELEASE: 15, CODENAME: REL
}