API Level: ano ito, mga bersyon ng API at targetSdk

Ano ang API Level Android?

API Level Android ay isang integer identifier na itinalaga sa bawat pampublikong release ng Android Framework API. Ang unang release na Android 1.0 ay may API Level 1, Android 1.5 — API Level 3, Android 2.2 — API Level 8, Android 4.0 — API Level 14, Android 8.0 — API Level 26, Android 12 — API Level 31, Android 14 — API Level 34, Android 15 — API Level 35, Android 16 (2025) — API Level 36. Bawat bagong API Level ay maaaring magdagdag ng mga bagong klase, metodo, constant, pahintulot at baguhin ang pag-uugali ng mga umiiral na.

Ang API Level ay hindi mahigpit na tumataas ng 1 sa bawat release. Halimbawa, ang Android 4.4W (Wear) ay may API 20, samantalang ang Android 5.0 ay API 21. Ang mga puwang ay may kaugnayan sa mga internal na iteration at Wear OS device. Para sa developer, mahalagang malaman hindi ang pangalan ng bersyon (KitKat, Lollipop, Tiramisu), kundi ang API Level nito — ito ang ginagamit sa code para sa mga pagsusuri ng kompatibilidad.

Ang pangunahing layunin ng API Level ay backward compatibility. Ang isang app na na-compile laban sa API 34 ay maaaring tumakbo sa mga device na may API 34 at mas mababa (kung hindi ito gumagamit ng mga bagong API nang walang pagsusuri). Android Runtime (ART) ay nagsusuri ng mga tawag sa API sa antas ng system at nag-aaplay ng mga pagbabago sa pag-uugali batay sa targetSdkVersion ng app.

Paano hinahawakan ng Android ang API Level

Kapag nag-i-install ng app, sinusuri ng PackageManager kung ang API Level ng device >= minSdkVersion mula sa AndroidManifest.xml. Kung hindi natugunan ang kundisyon — ang pag-install ay haharangin ng mensaheng "App not installed". Sa panahon ng runtime, sinusubaybayan ng Android Runtime ang mga tawag sa API na nangangailangan ng mas mataas na API Level at bubuo ng NoSuchMethodError o UnsatisfiedLinkError kung ang metodo ay wala sa kasalukuyang bersyon.

minSdk, targetSdk, compileSdk: mga pagkakaiba at papel ng bawat parameter

Sa file na build.gradle (Module: app), tinutukoy ng developer ang tatlong parameter ng API Level: minSdkVersion, targetSdkVersion at compileSdkVersion. Ang pagkalito sa mga ito ay isa sa mga pinakakaraniwang pagkakamali ng mga baguhang Android developer. Bawat parameter ay responsable para sa iba't ibang aspeto ng kompatibilidad, at ang kanilang mga halaga ay dapat na magkatugma.

minSdkVersion

minSdkVersion ay ang pinakamababang API Level kung saan maaaring i-install at patakbuhin ang app. Ang mga device na may API Level na mas mababa sa minSdk ay hindi nakikita ang app sa Google Play at hindi ito mai-install. Ang halaga ay pinipili batay sa target na audience: minSdk 21 (Android 5.0) ay sumasaklaw sa 97% ng mga device, minSdk 26 (Android 8.0) — mga 85%, minSdk 31 (Android 12) — mga 55% (data mula sa Android Studio Distribution Dashboard, 2026). Kung mas mababa ang minSdk, mas malawak ang saklaw, ngunit mas maraming backward compatibility code ang kailangan.

targetSdkVersion

targetSdkVersion ay ang API Level kung saan sinubukan ang app. Ginagamit ng Android ang targetSdk upang ilapat ang mga pagbabago sa pag-uugali: kung ang app ay tumutukoy ng targetSdk 33, ina-activate ng system ang lahat ng pagbabago sa pag-uugali na ipinakilala sa API 33. Kung targetSdk ay 31, hindi inaaplay ng system ang mga pagbabago sa API 32-33, pinapanatili ang kompatibilidad sa lumang pag-uugali. Ito ang pinakamahalagang parameter para sa seguridad: Google Play ay nangangailangan ng targetSdk na hindi lalampas sa 1 taon mula sa kasalukuyang API Level.

compileSdkVersion

compileSdkVersion ay ang bersyon ng Android SDK kung saan naka-compile ang code. Tinutukoy nito kung aling mga API ang available sa oras ng compilation. compileSdk ay dapat >= targetSdk at, ideal, katumbas ng pinakabagong stable na API Level. Ang pagtaas ng compileSdk ay hindi nakakaapekto sa pag-uugali sa runtime — tanging ang availability ng mga bagong API para sa compiler. Pagkatapos itaas ang compileSdk, kailangan mong suriin ang code para sa mga deprecated na API at mga bagong kinakailangan ng pahintulot.

// build.gradle.kts — halimbawa ng configuration ng API Level
plugins {
    id("com.android.application") version "8.7.0"
    id("org.jetbrains.kotlin.android") version "2.1.0"
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36  // Android 16

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

    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }

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

    kotlinOptions {
        jvmTarget = "17"
    }
}

dependencies {
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
    implementation("androidx.activity:activity-ktx:1.9.3")
}

Sa halimbawa ng build.gradle.kts, compileSdk = 36 (pinakabago sa oras ng pagsulat), targetSdk = 36, minSdk = 26 (Android 8.0). compileSdk 36 ay nagbibigay ng access sa lahat ng Android 16 API. targetSdk 36 ay nag-a-activate ng lahat ng pagbabago sa pag-uugali ng Android 16. minSdk 26 ay sumasaklaw sa ~85% ng mga device. AndroidX Activity KTX at AppCompat ay nagbibigay ng backward compatibility para sa mga fragment at tema.

AndroidManifest.xml

Ang mga parameter na minSdk at targetSdk ay maaari ring tukuyin sa AndroidManifest.xml, ngunit ang mga modernong proyekto ay gumagamit ng build.gradle — ang mga halaga mula sa Gradle ay nag-o-override sa manifest. Sa manifest, maaaring maging kapaki-pakinabang na tukuyin ang para sa mga library at module na hindi gumagamit ng Gradle build config.

Mga Pagbabago sa Pag-uugali: paano naaapektuhan ng targetSdk ang pag-uugali ng app

Mga pagbabago sa pag-uugali ay mga pagbabago sa paraan ng paggana ng Android system na inaapply lamang sa mga app na may targetSdk >= isang partikular na API Level. Bawat bagong Android release ay nagpapakilala ng mga pagbabago sa pag-uugali na maaaring makasira ng mga umiiral na app kung hindi na-update. Ito ay isang pangunahing mekanismo ng seguridad ng Android: ang mga lumang app ay patuloy na gumagana tulad ng dati, ang mga bago ay sumusunod sa kasalukuyang mga patakaran.

Mga pangunahing pagbabago sa pag-uugali ayon sa bersyon

Android 10 (API 29) — Scoped Storage: ang mga app na may targetSdk 29+ ay walang direktang access sa shared file system, sa pamamagitan lamang ng MediaStore, SAF o sariling storage. Android 11 (API 30) — Package Visibility: filter ng package, ang mga app ay nakakakita lamang ng mga naka-install na package na kanilang nakikipag-ugnayan. Android 12 (API 31) — Foreground Service Notification: lahat ng foreground service ay dapat magpakita ng notifikasyon sa loob ng 10 segundo pagkatapos magsimula. Android 13 (API 33) — POST_NOTIFICATIONS: runtime permission para sa push notifications. Android 14 (API 34) — Foreground Service Types: mandatoryong deklarasyon ng uri ng foreground service sa manifest.

// Paghawak ng mga pagbabago sa pag-uugali ng Android 13 (API 33): POST_NOTIFICATIONS
import android.Manifest
import android.content.pm.PackageManager
import android.os.Build
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class NotificationHelper {

    fun requestNotificationPermission(activity: MainActivity) {
        // Ang pahintulot na POST_NOTIFICATIONS ay gumagana lamang sa API 33+
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) {
            return  // Sa ibaba ng API 33 hindi kinakailangan ang pahintulot
        }

        when {
            ContextCompat.checkSelfPermission(
                activity,
                Manifest.permission.POST_NOTIFICATIONS
            ) == PackageManager.PERMISSION_GRANTED -> {
                // Naibigay na ang pahintulot, maaaring magpadala ng mga notifikasyon
                showNotification(activity)
            }

            activity.shouldShowRequestPermissionRationale(
                Manifest.permission.POST_NOTIFICATIONS
            ) -> {
                // Ipakita ang paliwanag kung bakit kailangan ang pahintulot
                activity.showRationale()
            }

            else -> {
                // Humingi ng pahintulot
                activity.requestPermissionLauncher.launch(
                    Manifest.permission.POST_NOTIFICATIONS
                )
            }
        }
    }

    private fun showNotification(context: Context) {
        // Lumikha at magpakita ng notifikasyon
        val notification = android.app.Notification.Builder(context, "default_channel")
            .setSmallIcon(android.R.drawable.ic_dialog_info)
            .setContentTitle("Notifikasyon")
            .setContentText("Bagong mensahe")
            .build()
        val manager = context.getSystemService(Context.NOTIFICATION_SERVICE)
            as android.app.NotificationManager
        manager.notify(1, notification)
    }
}

// Magrehistro ng requestPermissionLauncher sa Activity
class MainActivity : ComponentActivity() {
    val requestPermissionLauncher = registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Naibigay ang pahintulot
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

Halimbawa ng paghawak ng POST_NOTIFICATIONS sa Kotlin: suriin ang Build.VERSION.SDK_INT >= TIRAMISU, humingi ng runtime permission sa pamamagitan ng ActivityResultContracts.RequestPermission, hawakan ang resulta sa callback. Kung wala ang pahintulot na ito, ang app na may targetSdk 33+ ay hindi maaaring magpakita ng push notifications. Sa ibaba ng API 33, hindi kinakailangan ang pahintulot — ang code ng pagsusuri ay pumipigil sa pagtawag ng mga hindi available na API.

Scoped Storage (Android 10+)

Scoped Storage ay isa sa mga pinakamahalagang pagbabago sa pag-uugali. Simula sa API 29 (targetSdk 29+), ang app ay hindi makakakuha ng direktang file access sa mga direktoryo ng Pictures, Downloads, Music at Documents. Sa halip, ginagamit ang MediaStore para sa media, SAF (Storage Access Framework) para sa mga arbitrary na file, at getExternalFilesDir() para sa sariling storage. Ang eksepsiyon ay mga app na may pahintulot na MANAGE_EXTERNAL_STORAGE, na nangangailangan ng pag-apruba ng Google Play.

Mga Kinakailangan ng Google Play para sa API Level at targetSdk

Google Play ay nagtatakda ng mga mandatoryong kinakailangan sa targetSdkVersion para sa pag-publish ng mga app. Mula noong Agosto 2024, ang Google Play ay nangangailangan ng targetSdkVersion >= API 33 (Android 13). Bawat taon ang threshold ay tumataas: ang mga bagong app at update ay dapat tumukoy ng targetSdk na hindi lalampas sa 1 taon mula sa kasalukuyang pangunahing API Level. Ang paglabag sa kinakailangan ay humahantong sa pagharang ng publikasyon at pag-alis ng app mula sa tindahan.

Bakit pinapahigpit ng Google Play ang mga kinakailangan

Ang pangunahing dahilan ay seguridad. Bawat bagong Android API Level ay nagpapakilala ng mga pagbabago sa pag-uugali na nagsasara ng mga vector ng pag-atake: Scoped Storage (API 29) ay pumipigil sa pagnanakaw ng file, POST_NOTIFICATIONS (API 33) ay nagpoprotekta laban sa spam notifications, Foreground Service Types (API 34) ay naglilimita ng mga nakatagong background service. Ang mga app na may mababang targetSdk ay hindi nakakatanggap ng mga proteksyong ito at nagiging banta sa mga user. Hindi maaaring payagan ng Google Play ang mga lumang app sa mga modernong device.

Pagsusuri ng pagsunod sa mga kinakailangan

Sinusuri ng Google Play Console ang targetSdkVersion kapag nag-a-upload ng APK/AAB. Kung ang targetSdk ay mas mababa sa kinakailangan — hinaharangan ng console ang publikasyon gamit ang mensaheng: "Your app currently targets API level X and must target at least API level Y". Dapat i-update ng developer ang build.gradle, i-recompile ang app, subukan ang mga pagbabago sa pag-uugali at mag-upload muli. Ang format na AAB ay inirerekomenda para sa lahat ng bagong publikasyon (mandatory mula noong Agosto 2021).

Pagsusuri ng API Level sa code: Build.VERSION.SDK_INT

Build.VERSION.SDK_INT ay isang static na integer constant na naglalaman ng API Level ng device kung saan tumatakbo ang app. Ito ang pangunahing tool para sa pagsusuri ng bersyon ng Android sa runtime. Ang Build.VERSION_CODES ay naglalaman ng mga pinangalanang constant para sa bawat API Level: VERSION_CODES.TIRAMISU (33), VERSION_CODES.UPSIDE_DOWN_CAKE (34), VERSION_CODES.VANILLA_ICE_CREAM (35). Ang paghahambing sa pamamagitan ng if (SDK_INT >= VERSION_CODES.TIRAMISU) ay ang karaniwang pattern.

// Mga halimbawa ng pagsusuri ng API Level sa Android code
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import android.graphics.drawable.AdaptiveIconDrawable

class ApiLevelHelper {

    // 1. Pangunahing pagsusuri ng API Level
    fun isAtLeastTiramisu(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU  // 33
    }

    // 2. Adaptive na tawag sa API na may pagsusuri
    fun getAdaptiveIcon(drawable: android.graphics.drawable.Drawable):
            android.graphics.drawable.Drawable? {
        // Ang AdaptiveIconDrawable ay available lamang sa API 26 (Android 8)
        if (VERSION.SDK_INT >= VERSION_CODES.O) {
            return AdaptiveIconDrawable(drawable, null)
        }
        return drawable  // fallback para sa mga lumang device
    }

    // 3. Pagsusuri ng pahintulot na POST_NOTIFICATIONS (API 33+ lamang)
    fun canRequestNotificationPermission(): Boolean {
        return VERSION.SDK_INT >= VERSION_CODES.TIRAMISU
    }

    // 4. Pagpili ng provider ng larawan ayon sa API Level
    fun getImagePickerProvider(): String {
        return when {
            VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
                // API 34+ ay gumagamit ng PhotoPicker
                "photo_picker"
            }
            VERSION.SDK_INT >= VERSION_CODES.KITKAT -> {
                // API 19+ ay gumagamit ng Intent ACTION_OPEN_DOCUMENT
                "open_document"
            }
            else -> {
                // Legacy: ACTION_GET_CONTENT (lahat ng bersyon)
                "get_content"
            }
        }
    }

    // 5. Pagsusuri na estilo ng Java sa pamamagitan ng @TargetApi (para sa backward compatibility)
    @Suppress("DEPRECATION")
    fun checkLegacyStorage(): Boolean {
        // Ang pag-uugali ng Scoped Storage ay depende sa targetSdk, hindi sa SDK_INT
        return VERSION.SDK_INT < VERSION_CODES.Q  // Android 10
    }

    // 6. Impormasyon ng build para sa analytics
    fun getDeviceApiInfo(): Map<String, Any> {
        return mapOf(
            "sdk_int" to VERSION.SDK_INT,
            "release" to VERSION.RELEASE,
            "codename" to VERSION.CODENAME,
            "incremental" to VERSION.INCREMENTAL,
            "preview_sdk" to VERSION.PREVIEW_SDK_INT
        )
    }
}

// Pagsubok
fun main() {
    val helper = ApiLevelHelper()
    println("API Level: ${VERSION.SDK_INT}")
    println("Is Tiramisu+: ${helper.isAtLeastTiramisu()}")
}

Ang klase na ApiLevelHelper ay nagpapakita ng lahat ng pangunahing pattern ng pagsusuri ng API Level: isAtLeastTiramisu na may SDK_INT >= VERSION_CODES, getAdaptiveIcon na may fallback para sa mga lumang bersyon, getImagePickerProvider na may when multi-branching, getDeviceApiInfo para sa analytics. Ang pangunahing patakaran ay huwag tumawag ng mga bagong API nang hindi sinusuri ang SDK_INT, kung hindi ay mag-crash ang app na may NoSuchMethodError sa mga lumang device.

ANT (Android New API) at lint

Ang Android Studio ay may kasamang static analyzer na lint, na nagbabala tungkol sa paggamit ng API na higit sa minSdkVersion. Kung ang isang metodo ay tinawag nang walang pagsusuri ng SDK_INT, iha-highlight ito ng lint bilang error: "Call requires API level 34 (current min is 26)". Mga solusyon: magdagdag ng @RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE) sa metodo o if-check ng SDK_INT. Ang @TargetApi ay isang deprecated na annotation, @RequiresApi ay inirerekomenda.

Talaan ng kaukulang API Level at mga bersyon ng Android

Talaan ng API Level ay isang reference tool para sa developer. Sa pag-alam ng API Level ng device, matutukoy mo ang bersyon ng Android at mga available na feature. Ang talaan ay naglilista ng lahat ng pangunahing Android release mula API Level 1 (2008) hanggang API Level 36 (2025). Ang mga code name (Cupcake, Donut, Tiramisu, VanillaIceCream) ay ginagamit sa loob ng Google at sa VERSION_CODES.

Talaan: threshold API Level para sa mga pagbabago sa pag-uugali

Ang sumusunod na talaan ay nagpapakita ng mga pangunahing API Level na nagpapakilala ng mga pagbabago sa pag-uugali na sumisira sa backward compatibility kapag itinaas ang targetSdk: