minSdkVersion: ano ito, paano pumili ng minimum na bersyon ng Android

Ano ang minSdkVersion sa Android?

minSdkVersion — isang integer na parameter sa build.gradle na nagtatakda ng pinakamababang antas ng API ng Android para sa pag-install ng app. Kung ang antas ng API ng device ay mas mababa sa tinukoy na halaga, hinaharangan ng PackageManager ang pag-install, at itinatago ng Google Play Store ang app mula sa mga resulta ng paghahanap para sa naturang device. Ang minSdkVersion ay isinusulat sa AndroidManifest.xml sa yugto ng build sa pamamagitan ng tag na <uses-sdk android:minSdkVersion> at sinusuri sa bawat pag-install.

Ang halaga ng minSdkVersion ay isang kompromiso sa pagitan ng saklaw ng audience at access sa mga bagong API. Kung mas mababa ang minSdk, mas maraming device ang maaaring mag-install ng app, lalo na sa mga umuunlad na rehiyon kung saan sikat ang mga lumang Android smartphone. Kung mas mataas ang minSdk, mas kaunting backward compatibility code ang kinakailangan at mas maraming modernong API ang available nang walang runtime checks. Android Jetpack at mga library ng AndroidX ay nagbibigay ng mga backport ng maraming bagong API sa mga lumang bersyon ng Android, na nagpapahintulot sa pagpili ng mas mababang minSdk nang walang pagkawala ng functionality.

Ang minSdkVersion ay nakakaapekto sa lahat ng yugto ng pag-develop: static analysis (ginagamit ng lint ang minSdk para sa mga babala), compatibility ng dependencies (maaaring mangailangan ang mga library ng sarili nilang minSdk), pagsubok (kailangang subukan sa mga device na may minSdk) at Google Play Console (saklaw ng audience ay kinakalkula batay sa minSdk). Ang pagbabago ng minSdkVersion ay isa sa mga pinakamahalagang desisyon sa configuration ng proyekto, dahil nakakaapekto ito sa code, mga pagsubok, at base ng user.

Saan tinukoy ang minSdkVersion

Build.gradle.kts (Kotlin DSL) — ang modernong pamantayan sa mga proyekto ng Android. Ang parameter na minSdk ay itinakda sa bloke ng defaultConfig sa antas ng modyul. Ang halaga ay maaaring ma-override para sa iba't ibang uri ng build at flavor ng produkto, na nagpapahintulot sa pagsubok sa mas mababang API nang hindi binabago ang pangunahing halaga.

// build.gradle.kts — pangunahing configuration ng minSdk
android {
    namespace = "com.example.myapp"
    compileSdk = 36

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

    // Pag-override ng minSdk para sa iba't ibang flavor
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            minSdk = 26
        }
        create("premium") {
            minSdk = 26
        }
    }
}

Sa halimbawa, ang minSdk = 26 ay tumutugma sa Android 8.0 Oreo. Ito ay isang popular na halaga noong 2026: ayon sa Android Studio Distribution Dashboard, pinuputol lamang nito ang ~15% ng mga device. Ang compileSdk = 36 ay nagbibigay ng access sa lahat ng API ng Android 16, at ang targetSdk = 36 ay nag-a-activate ng mga behavioral change ng pinakabagong bersyon. Para sa debug builds, ang minSdk ay maaaring ibaba para sa pagsubok sa mga lumang emulator.

Paano pumili ng minSdkVersion: mga kadahilanan at estratehiya

Pagpili ng minSdkVersion — isang strategic na desisyon batay sa pagsusuri ng target na audience, mga kinakailangan ng API, at ecosystem ng library. Walang iisang tamang halaga para sa lahat ng proyekto. Noong 2026, inirerekomenda ng Android Studio ang minSdk = 26 (Android 8.0) bilang baseline para sa mga bagong proyekto, ngunit para sa mga B2B app o corporate solution, ang mga mas mababa o mas mataas na halaga ay katanggap-tanggap.

Mga kadahilanan sa pagpili ng minSdkVersion

Unang kadahilanan — Distribution Dashboard. Nagbibigay ang Android Studio ng mga istatistika ng mga aktibong device ayon sa antas ng API batay sa data ng Google Play, na ina-update bawat buwan. Ang minSdkVersion ay dapat sumaklaw ng hindi bababa sa 90-95% ng mga aktibong device sa target na merkado. Para sa mga internasyonal na app na may audience sa Africa at Southeast Asia, ang minSdk ay dapat ibaba sa 21 (Android 5.0) dahil sa mataas na bahagi ng mga lumang device.

Pangalawang kadahilanan — mga kinakailangan ng dependency. Ang bawat library ay may sariling minSdkVersion na tinukoy sa manifest nito. Kung ang library ay nangangailangan ng minSdk 29 at ang app — minSdk 26, ang build ay mabibigo sa error na manifest merger. Ang mga modernong library ng Google Play Services ay may minSdk 21, Firebase — minSdk 21, karamihan sa mga library ng Jetpack — minSdk 21 o 26, Compose BOM — minSdk 21. Para sa Compose ang minimum na threshold — API 21.

Pangatlong kadahilanan — mga kinakailangang API. Kung ang pangunahing functionality ng app ay nangangailangan ng API na available lamang mula sa isang tiyak na antas (halimbawa, PhotoPicker — API 34, Predicted Navigation — API 35), maaari nitong bigyang-katwiran ang pagtaas ng minSdk. Ngunit mas madalas ginagamit ang kombinasyon ng mga backport ng AndroidX (Activity Result API, NotificationCompat) at runtime checks upang mapanatili ang mababang minSdk.

Hakbang-hakbang na estratehiya sa pagpili

Hakbang 1: buksan ang Android Studio, File → New Project at tingnan ang inirerekomendang minSdk sa wizard. Hakbang 2: suriin ang Distribution Dashboard sa Android Studio (View → Tool Windows → App Inspection → Distribution Dashboard). Hakbang 3: suriin ang mga dependency ng proyekto — isagawa ang build at ayusin ang mga conflict ng manifest merger. Hakbang 4: suriin kung aling mga API ng antas X ang aktwal na ginagamit nang walang backport. Hakbang 5: itakda ang minSdk bilang pinakamababang halaga na sumasaklaw sa 90%+ ng target na audience at compatible sa lahat ng dependency.

Saklaw ng device: distribusyon ng antas ng API (2026)

Distribusyon ng device ayon sa antas ng API — isang dynamic na indicator na nagbabago bawat quarter. Ayon sa Android Studio Distribution Dashboard para sa Hunyo 2026, humigit-kumulang 85% ng mga aktibong Android device ay tumatakbo sa API 26 (Android 8.0) at mas mataas, 72% — sa API 29 (Android 10) at mas mataas, 55% — sa API 31 (Android 12) at mas mataas. Ang merkado ng Tsina ay may sariling estadistika dahil sa kawalan ng Google Play Services sa maraming device ng Huawei.

Mga device ng GMS (Google Mobile Services) ay mas mabilis na nag-a-update: ang bahagi ng API 31+ sa mga ito ay umaabot sa 68% salamat sa mga obligadong kinakailangan ng Google Play sa mga manufacturer. Mga non-GMS device (Huawei, Honor, ilang Chinese brand) ay may mas lumang distribusyon: ang bahagi ng API 31+ sa mga ito ay humigit-kumulang 35%. Kung ang app ay nakatuon sa internasyonal na merkado, umasa sa pandaigdigang estadistika. Kung sa merkado ng Tsina — isaalang-alang ang non-GMS segment.

Konklusyon: para sa internasyonal na app, ang minSdk 26 ay sumasaklaw sa 85% ng mga device na may minimal na gastos sa backward compatibility. Para sa mga app na may audience sa mga umuunlad na rehiyon, ang minSdk 21 (97% saklaw) ay makatwiran, ngunit mangangailangan ng mas maraming code para sa pagtatrabaho sa mga lumang API. Para sa Enterprise apps na may kontroladong fleet ng device, maaari mong itakda ang minSdk 31 at ganap na maalis ang fallback code.

Backward compatibility: AndroidX, lint at @RequiresApi

Backward compatibility — ang pangunahing kahirapan sa mababang minSdkVersion. Ang AndroidX (dating Support Library) ay nagbibigay ng mga backport ng modernong API sa mga lumang bersyon ng Android: AppCompatActivity para sa Material Design, FragmentManager, Loader, NotificationCompat, PreferenceFragmentCompat at dose-dosenang iba pang bahagi. Ang paggamit ng mga katumbas ng AndroidX sa halip na native na API — unang hakbang sa compatibility.

lint (static analyzer ng Android Studio) ay nag-scan ng code para sa mga tawag ng API na mas mataas sa minSdkVersion. Kung ang method ay minarkahan ng @RequiresApi na may antas ng API na mas mataas sa minSdk at tinawag nang walang check, itinatampok ng lint ang error. Para pigilan ang babala, gamitin ang anotasyong @SuppressLint("NewApi") sa method o @RequiresApi(Build.VERSION_CODES.TIRAMISU) sa buong function. Runtime checks sa pamamagitan ng Build.VERSION.SDK_INT — ang pangunahing mekanismo para sa ligtas na pagtawag ng mga bagong API sa mga lumang device.

// Halimbawa ng backward compatibility: PhotoPicker (API 34+) at fallback
import android.os.Build
import android.os.Build.VERSION
import android.os.Build.VERSION_CODES
import androidx.activity.result.contract.ActivityResultContracts
import androidx.appcompat.app.AppCompatActivity

class ImagePickerActivity : AppCompatActivity() {

    // Activity Result API (AndroidX) — gumagana sa anumang antas ng API
    private val pickImageLauncher = registerForActivityResult(
        ActivityResultContracts.GetContent()
    ) { uri ->
        uri?.let { displayImage(it) }
    }

    fun pickImage() {
        // PhotoPicker ay available lamang mula sa API 34
        if (VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // Ginagamit namin ang PhotoPicker (API 34+)
            val intent = android.provider.MediaStore
                .ACTION_PICK_IMAGES
            startActivityForResult(intent, 100)
        } else {
            // Fallback: GetContent (gumagana sa lahat ng bersyon)
            pickImageLauncher.launch("image/*")
        }
    }

    @RequiresApi(VERSION_CODES.UPSIDE_DOWN_CAKE)
    fun usePhotoPickerOnly() {
        // Ang method na ito ay hindi maaaring tawagin sa API < 34
        val intent = android.provider.MediaStore
            .ACTION_PICK_IMAGES
        startActivityForResult(intent, 100)
    }
}

Ang klase na ImagePickerActivity ay nagpapakita ng tatlong antas ng backward compatibility. Ang Activity Result API mula sa AndroidX ay gumagana sa lahat ng antas ng API, kaya para sa pangunahing pagpili ng imahe, hindi mahalaga ang minSdk. Ang PhotoPicker (ACTION_PICK_IMAGES) ay available lamang mula sa API 34 at tinatawag sa ilalim ng SDK_INT check na may fallback sa GetContent. Ang method na usePhotoPickerOnly ay minarkahan ng @RequiresApi — hindi papayagan ng lint na tawagin ito nang walang check. AppCompat mula sa AndroidX ay awtomatikong nag-a-adjust ng tema, fragment, at animation sa bersyon ng OS.

minSdkVersion sa mga library at modyul

Mga library (AAR, JAR) ay mayroon ding minSdkVersion na tinukoy sa kanilang manifest. Kapag nagkokonekta ng library, sinusuri ng Gradle ang compatibility: kung ang minSdk ng library ay mas mataas sa minSdk ng app, nabigo ang build na may error. Para sa mga pampublikong library, inirerekomenda na tukuyin ang pinakamababang posibleng minSdk (21 sa karamihan ng mga kaso) upang hindi limitahan ang mga consumer. Kung ang library ay nangangailangan ng API 29+, nawawalan ito ng ~28% ng mga potensyal na user.

Multi-module na proyekto ay maaaring magkaroon ng iba't ibang minSdkVersion para sa iba't ibang modyul. Halimbawa, ang modyul na :core:network ay maaaring magkaroon ng minSdk 26, at ang modyul na :feature:camera — minSdk 29 (dahil sa CameraX na may partikular na kinakailangan). Kinakailangan ng Google Play na ang minSdk ng pangunahing modyul na :app ay mas mababa o katumbas ng minSdk ng lahat ng dependent na modyul. Sa praktika, ang lahat ng modyul ng isang app ay karaniwang may parehong minSdk para sa pinasimpleng pagpapanatili.

// build.gradle.kts — modyul ng library na may mababang minSdk
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.mylibrary"
    compileSdk = 36

    defaultConfig {
        minSdk = 21  // Minimum para sa maximum na saklaw
        targetSdk = 36
    }
}

dependencies {
    // AndroidX Core — minSdk 21, nagdaragdag ng mga backport
    implementation("androidx.core:core-ktx:1.15.0")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

Ang modyul ng library na may minSdk = 21 ay compatible sa 97% ng mga device at hindi nililimitahan ang mga consumer. Kung ang library ay gumagamit ng API na mas mataas sa 21, ang developer ay dapat magdagdag ng runtime checks o tukuyin ang @RequiresApi sa mga kaukulang method. Ang AndroidX Core KTX (minSdk 21) ay nagbibigay ng mga backport para sa Context, Bundle, Locale at iba pang system class, na nagpapahintulot sa library na mapanatili ang mababang minSdk.

Mga karaniwang pagkakamali sa pagpili ng minSdkVersion

Mga pagkakamali sa pagpili ng minSdk ay maaaring magdulot ng libu-libong pag-install o linggo ng karagdagang pag-develop. Unang karaniwang pagkakamali — pagkopya ng minSdk mula sa template ng proyekto nang walang pagsusuri ng Distribution Dashboard. Maraming developer ang nag-iiwan ng minSdk = 21 mula sa Android Studio Template, kahit na para sa kanilang audience ang minSdk 26 ay sapat na at magbabawas ng bilang ng SDK_INT checks sa code.

Pangalawang pagkakamali — masyadong mataas na minSdk nang hindi isinasaalang-alang ang merkado. Kung magtatakda ka ng minSdk = 31 (Android 12) para sa isang internasyonal na app, mawawalan ka ng ~45% ng mga device. Para sa isang startup o app na may mass audience, ito ay isang sakuna. Palaging suriin ang Distribution Dashboard bago itaas ang minSdk at gamitin ang A/B testing sa Google Play Console kung hindi ka sigurado.

Pangatlong pagkakamali — pagwawalang-bahala sa minSdk ng mga dependency. Kapag nagdadagdag ng bagong library, suriin ang minSdk nito sa dokumentasyon o POM file. Ang Firebase ML Kit ay nangangailangan ng minSdk 21, ang ilang custom na camera library ay nangangailangan ng minSdk 29. Kung ang manifest merger ay bigo sa produksyon dahil sa bagong library, ang pag-aayos ay maaaring tumagal ng ilang araw.

// Halimbawa: pagsusuri ng compatibility ng API sa runtime
fun checkFeatureAvailability(): Boolean {
    // Karaniwang pagkakamali — pagtawag ng API nang walang SDK_INT check
    return when {
        VERSION.SDK_INT >= VERSION_CODES.UPSIDE_DOWN_CAKE -> {
            // API 34+ — ginagamit namin ang PhotoPicker
            true
        }
        VERSION.SDK_INT >= VERSION_CODES.Q -> {
            // API 29-33 — ginagamit namin ang MediaStore
            true
        }
        else -> {
            // API < 29 — ginagamit namin ang ACTION_GET_CONTENT
            true
        }
    }
}

Ang tamang arkitektura ng mga pagsusuri ng antas ng API — when na may mga saklaw na sumasaklaw sa lahat ng posibleng halaga mula minSdk hanggang compileSdk. Ang pangunahing patakaran: bawat tawag ng API ng antas X ay dapat protektahan ng pagsusuri ng VERSION.SDK_INT para sa lahat ng device na may antas ng API mula minSdk hanggang X. Ang lint ay tumutulong sa pag-detect ng mga hindi nasuring tawag, ngunit hindi nito magagarantiyahan ang kumpletong saklaw para sa dynamic na code.