SDK Platform: apa itu, versi dan Android SDK Manager

Apa itu SDK Platform

SDK Platform — adalah komponen fundamental Android SDK, yang merupakan kumpulan lengkap pustaka dan alat untuk mengembangkan aplikasi di bawah versi Android tertentu. Setiap platform diidentifikasi oleh API Level — bilangan bulat yang bertambah seiring rilis versi OS baru. Misalnya, Android 13 sesuai dengan API Level 33, Android 14 — API Level 34, Android 15 — API Level 35.

Tidak seperti Android Studio (IDE), SDK Platform tidak menyertakan editor kode atau debugger. Ini adalah lapisan sistem yang terhubung ke kompiler dan builder. Ketika pengembang menulis import android.app.Activity, kompiler mengambil kelas ini dari android.jar SDK Platform tertentu. Tanpa platform yang terinstal dengan API Level yang diperlukan, kode tidak akan dikompilasi.

Google merilis SDK Platform baru untuk setiap versi Android yang stabil. Sejarah mencakup lebih dari 35 API Level — dari Android 1.0 (API 1) hingga Android 15 (API 35). Setiap platform kompatibel mundur: kode yang ditulis untuk API Level 21 akan berfungsi di API Level 35, tetapi tidak sebaliknya.

Mengapa diperlukan SDK Platform terpisah untuk setiap versi

Android berkembang cepat: setiap versi menambahkan API baru, mengubah perilaku yang ada, dan memperkenalkan batasan. Misalnya, Android 10 (API 29) memperkenalkan Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — flag BroadcastReceiver wajib. Pengembang harus membangun aplikasi terhadap platform saat ini untuk menggunakan kemampuan ini.

Pada saat yang sama, aplikasi dapat berjalan di versi OS lama. Untuk ini, di Gradle ditentukan minSdk — API Level minimum di mana aplikasi berjalan. Kode menggunakan pemeriksaan versi dan panggilan API bersyarat. Pendekatan ini memastikan kompatibilitas tanpa kehilangan fitur baru.

Komposisi SDK Platform: komponen utama

SDK Platform — bukan satu file, tetapi kumpulan komponen yang bersama-sama memungkinkan kompilasi, pembangunan, dan pengujian aplikasi. Elemen utamanya adalah android.jar — arsip dengan kelas Android API yang disertakan dalam versi ini. File ini terhubung ke kompiler Kotlin atau Java dan menentukan kelas, metode, dan anotasi apa yang tersedia bagi pengembang.

Citra sistem dan emulator

Setiap SDK Platform menyertakan System Image — citra sistem operasi untuk emulator Android Virtual Device. Tanpa citra yang sesuai, emulator tidak akan dapat menjalankan perangkat virtual dengan API Level yang diperlukan. System Images tersedia dalam berbagai tipe: Google APIs (dengan layanan Google), Google Play (dengan Play Store) dan AOSP (Android murni tanpa layanan Google).

Alat build dan debug

SDK Platform menyertakan versi Build-Tools dan Platform-Tools yang dioptimalkan untuk API Level ini. Build-Tools berisi aapt2 (Android Asset Packaging Tool), dx/d8 (kompiler Dalvik/ART) dan ApkSigner. Platform-Tools menyediakan ADB (Android Debug Bridge), fastboot dan SQLite. Alat-alat ini diperbarui secara independen dari SDK Platform melalui SDK Manager.

Sumber daya platform

Setiap platform menyertakan sumber daya Android standar — tema sistem, gaya, animasi, warna, dan ukuran. Sumber daya ini digunakan selama kompilasi: jika pengembang merujuk ke @android:style/Theme.Material.Light, builder mengambil definisi dari sumber daya SDK Platform. Ini menjamin tampilan seragam komponen sistem di semua perangkat.

API Level dan versi SDK Platform

API Level — adalah pengidentifikasi bilangan bulat dari versi Android SDK. Setiap rilis Android memiliki satu API Level yang meningkat secara monoton. Pengembang menentukan API Level dalam tiga parameter kunci build.gradle: compileSdk, minSdk, dan targetSdk. Pilihan parameter ini menentukan API mana yang tersedia dan bagaimana sistem memproses aplikasi.

Google merekomendasikan menjaga minSdk tidak lebih rendah dari ambang distribusi saat ini — menurut Android Studio Distribution Dashboard (2026), sekitar 95% perangkat berjalan di Android 8.0 (API 26) dan lebih tinggi. compileSdk harus yang stabil terbaru — ini memberikan akses ke API baru dan memungkinkan pemeriksaan lint mendeteksi metode usang.

Evolusi API Level: perubahan penting

Dengan setiap API Level baru, Google memperkenalkan perubahan signifikan. Android 6.0 (API 23) menambahkan izin runtime — aplikasi meminta izin selama runtime, bukan saat instalasi. Android 8.0 (API 26) memperkenalkan pengisian otomatis formulir dan saluran notifikasi. Android 12 (API 31) secara radikal mengubah pendekatan terhadap intent — muncul SplashScreen API dan ekspor komponen melalui atribut exported. Android 14 (API 34) mewajibkan penentuan flag untuk BroadcastReceiver dan memperkenalkan batasan ketat pada foreground services.

Memahami sejarah API Level membantu pengembang memilih strategi kompatibilitas yang tepat. Jika aplikasi menggunakan compileSdk 35 tetapi minSdk 26, kode dapat memanggil metode API 35 hanya setelah pemeriksaan versi melalui Build.VERSION.SDK_INT. Pendekatan ini disebut version-gated development dan merupakan standar industri.

SDK Manager: instalasi dan konfigurasi

SDK Manager — adalah alat untuk mengelola komponen Android SDK: menginstal SDK Platform baru, memperbarui yang sudah ada, dan menghapus yang usang. SDK Manager tersedia sebagai antarmuka grafis di Android Studio dan juga baris perintah melalui sdkmanager. Melalui baris perintah, SDK Manager nyaman digunakan di pipeline CI/CD yang tidak memiliki antarmuka grafis.

SDK Manager menginstal platform di direktori Android SDK, yang secara default berada di $HOME/Android/Sdk di Linux dan macOS atau %LOCALAPPDATA%\Android\Sdk di Windows. Di dalam direktori platforms terdapat folder bernama android-{API Level}, masing-masing berisi SDK Platform lengkap.

Instalasi SDK Platform melalui sdkmanager

Perintah sdkmanager menerima pengidentifikasi paket dalam format "platforms;android-{API}". Misalnya, untuk menginstal SDK Platform 35, perintahnya terlihat seperti ini:

# Instal SDK Platform untuk API Level 35
sdkmanager "platforms;android-35"

# Instal beberapa platform dengan satu perintah
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Daftar platform yang terinstal
sdkmanager --list_installed | grep platforms

# Hapus platform usang
sdkmanager --uninstall "platforms;android-28"

Instalasi otomatis melalui Gradle

Proyek Android modern menggunakan Gradle Plugin yang dapat secara otomatis menginstal SDK Platform saat build pertama. Untuk ini, Anda perlu menentukan compileSdk di build.gradle dan menambahkan direktori SDK ke konfigurasi lokal. Android Studio juga menawarkan untuk menginstal platform yang hilang saat membuka proyek — cukup klik tombol "Install SDK Platform" di jendela sinkronisasi Gradle.

Penting untuk memperbarui SDK Platform secara teratur melalui SDK Manager — bersama dengan platform, Build-Tools dan Platform-Tools juga diperbarui, yang mempengaruhi kinerja build dan stabilitas debugging. Google merekomendasikan memeriksa pembaruan SDK setiap 2–3 minggu, terutama sebelum memublikasikan versi baru aplikasi di Google Play.

Konfigurasi citra sistem untuk emulator

Untuk menjalankan emulator dengan API Level tertentu, Anda perlu menginstal System Image versi yang sama. SDK Manager memungkinkan mengunduh citra dari berbagai arsitektur (x86_64, arm64-v8a) dan tipe (Google APIs, Google Play, AOSP). Setelah mengunduh citra, AVD Manager membuat perangkat virtual berdasarkan citra tersebut.

# Instal System Image dengan Google APIs untuk API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Buat AVD melalui baris perintah
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Daftar AVD yang dibuat
avdmanager list avd

compileSdk, targetSdk dan minSdk di Gradle

Tiga parameter di build.gradle menentukan cara kerja aplikasi dengan SDK Platform. compileSdk — API Level yang digunakan untuk kompilasi. Parameter ini menentukan kelas Android API mana yang tersedia dalam kode. compileSdk harus yang terbaru di antara ketiganya dan tidak mempengaruhi perilaku runtime — aplikasi dikompilasi tetapi hanya menggunakan API yang ada di perangkat.

minSdk — API Level minimum di mana aplikasi dapat diinstal. Google Play tidak akan mengizinkan instalasi aplikasi di perangkat dengan versi di bawah minSdk. Parameter ini menentukan ambang kompatibilitas dan mempengaruhi jangkauan audiens. Semakin rendah minSdk, semakin banyak perangkat yang didukung, tetapi semakin sedikit API baru yang dapat digunakan tanpa pemeriksaan.

targetSdk — API Level di mana aplikasi telah diuji. Sistem Android menggunakan targetSdk untuk menerapkan perubahan perilaku: jika aplikasi belum diperbarui ke API Level baru, sistem mengaktifkan mode kompatibilitas untuk versi lama. Google Play mensyaratkan targetSdk tidak lebih rendah dari level tertentu — untuk tahun 2026 ini adalah API 34 (Android 14).

Contoh konfigurasi Gradle

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
    }
}

// Versi Android SDK harus diinstal melalui SDK Manager
// sdkmanager "platforms;android-35"

Cara memilih compileSdk, minSdk dan targetSdk

Strategi pemilihan tergantung pada tujuan proyek. Untuk aplikasi baru: compileSdk — stabil terbaru (35 pada awal 2026), minSdk — API 26 (Android 8.0, mencakup 95% perangkat), targetSdk — stabil terbaru. Untuk memperbarui aplikasi yang ada: naikkan compileSdk segera, targetSdk — setelah menguji semua perubahan perilaku, minSdk — hanya jika perlu meninggalkan perangkat usang.

Google mensyaratkan targetSdk diperbarui dalam waktu satu tahun setelah rilis versi Android baru. Aplikasi yang tidak memenuhi persyaratan ini tidak dapat memublikasikan pembaruan di Google Play. Untuk melacak tenggat waktu, gunakan kalender resmi pembaruan Android OS.

Contoh bekerja dengan SDK Platform dalam kode

Saat mengembangkan untuk berbagai versi Android, perlu mempertimbangkan ketersediaan API. Jika aplikasi menggunakan compileSdk 35 tetapi berjalan di perangkat dengan API 31, memanggil metode yang ditambahkan di API 34 akan menyebabkan NoSuchMethodError atau AbstractMethodError. Untuk memanggil API baru dengan aman, digunakan pemeriksaan versi melalui Build.VERSION.SDK_INT.

Memeriksa API Level di runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Notification channels tersedia sejak API 26
            val channel = NotificationChannel(
                "updates",
                "Pembaruan",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Menggunakan API baru dengan @RequiresApi

Untuk metode yang hanya dipanggil pada versi tertentu, gunakan anotasi @RequiresApi. Ini memberi tahu pemeriksaan lint bahwa metode tersebut aman dan menonaktifkan peringatan. Dalam kombinasi dengan pemeriksaan SDK_INT, anotasi membuat kode lebih bersih dan lebih mudah dipahami oleh reviewer.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact dengan flag SCHEDULE_EXACT_ALARM
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Meminta izin 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 {
        // Metode lama setExact tanpa pemeriksaan izin
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Menentukan SDK Platform yang terinstal

Terkadang perlu mengetahui versi SDK Platform mana yang terinstal di perangkat pengembang atau di CI. Ini dapat dilakukan melalui ADB atau secara terprogram dalam kode aplikasi. Mengetahui API Level perangkat membantu saat menguji perilaku spesifik-versi.

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")
    }
    // Keluaran: SDK_INT: 35, RELEASE: 15, CODENAME: REL
}