targetSdkVersion: konsep kunci, behavioural changes dan Google Play

Apa itu targetSdkVersion di Android?

targetSdkVersion — parameter bilangan bulat dalam build.gradle yang mendeklarasikan API Level tempat aplikasi diuji. Sistem Android menggunakan parameter ini untuk memutuskan behavioural changes mana yang akan diterapkan pada aplikasi selama eksekusi. Jika targetSdkVersion = 33, Android menerapkan semua behavioural changes yang diperkenalkan hingga API 33 termasuk, tetapi tidak menerapkan perubahan API 34+. Jika targetSdkVersion = 34 — perubahan hingga API 34 diterapkan, dan seterusnya.

Perbedaan utama antara targetSdkVersion dan minSdkVersion — mekanisme kerjanya. minSdk diperiksa sekali saat instalasi dan memblokir instalasi jika kondisi tidak terpenuhi. targetSdkVersion memengaruhi perilaku runtime sistem pada setiap perangkat, terlepas dari versi Android mana aplikasi dijalankan. Aplikasi yang sama dengan targetSdk 31 akan berperilaku berbeda di Android 13, 14, dan 15, karena behavioural changes di atas 31 dinonaktifkan.

Mekanisme targetSdkVersion — adalah alat kompatibilitas mundur yang tertanam di Android. Tanpanya, setiap pembaruan OS akan merusak ribuan aplikasi lama. Google memperkenalkan mekanisme ini di Android 2.1 (API Level 7) dan sejak itu menggunakannya sebagai cara standar untuk memperkenalkan aturan keamanan, privasi, dan manajemen sumber daya baru tanpa mengganggu fungsi aplikasi yang ada.

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

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

// Pemeriksaan targetSdk saat ini dalam kode
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion berisi targetSdk aplikasi
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Dalam contoh, targetSdk = 36 mengaktifkan semua behavioural changes Android 16. Kode memeriksa targetSdkVersion melalui context.applicationInfo.targetSdkVersion — ini memungkinkan penentuan dinamis mode kompatibilitas mana yang aktif. Fungsi pembantu berguna untuk pustaka yang harus beradaptasi dengan targetSdk aplikasi pemanggil.

Behavioural Changes: bagaimana targetSdk memengaruhi aplikasi

Behavioural changes — adalah modifikasi perilaku sistem Android yang hanya diterapkan pada aplikasi dengan targetSdkVersion >= API Level tertentu. Setiap rilis major Android baru memperkenalkan behavioural changes, dan jika aplikasi tidak memperbarui targetSdk, perubahan ini tidak berlaku. Mekanisme semacam itu memungkinkan pengembang memperbarui aplikasi dengan kecepatan mereka sendiri, tidak sinkron dengan rilis versi OS baru.

Scoped Storage (API 29) — salah satu behavioural changes paling signifikan. Aplikasi dengan targetSdk 29+ tidak dapat memperoleh akses File langsung ke direktori bersama Pictures, Downloads, Music, Documents. Sebagai gantinya, MediaStore digunakan untuk multimedia, SAF (Storage Access Framework) untuk file arbitrer, dan getExternalFilesDir() untuk penyimpanan sendiri. Aplikasi lama dengan targetSdk 28 ke bawah terus bekerja dengan Full Storage Access lama, tetapi ini menciptakan ancaman keamanan.

POST_NOTIFICATIONS (API 33) — izin runtime untuk mengirim notifikasi. Aplikasi dengan targetSdk 33+ harus meminta izin Manifest.permission.POST_NOTIFICATIONS dari pengguna melalui dialog standar. Jika izin tidak diberikan, NotificationManager.silent() tidak menampilkan notifikasi kepada pengguna. Di Android 13+ tanpa izin ini, notifikasi push dan notifikasi lokal tidak akan ditampilkan, yang dapat secara signifikan mengurangi keterlibatan pengguna.

Cara memeriksa targetSdk saat ini

Nilai targetSdkVersion aplikasi dapat diperoleh melalui ADB: perintah adb shell dumpsys package com.example.myapp | grep targetSdk menampilkan targetSdk=34. Dalam kode, context.getApplicationInfo().targetSdkVersion mengembalikan bilangan bulat. Untuk analitik, berguna untuk mencatat targetSdk bersama dengan android.os.Build.VERSION.SDK_INT untuk memahami behavioural changes mana yang benar-benar aktif di setiap sesi.

Persyaratan Google Play untuk targetSdkVersion (2026)

Google Play menetapkan persyaratan wajib untuk targetSdkVersion untuk semua aplikasi yang dipublikasikan. Mulai Agustus 2024 targetSdk minimum = 33 (Android 13). Mulai Agustus 2025 — targetSdk = 34. Diperkirakan mulai Agustus 2026 Google akan mensyaratkan targetSdk = 35 (Android 15). Aplikasi baru dan pembaruan aplikasi yang ada harus memenuhi persyaratan ini, jika tidak konsol akan memblokir publikasi. Ini adalah kebijakan Google Play, bukan batasan Android Runtime: aplikasi dengan targetSdk 34 dapat berjalan di Android 16, tetapi tidak dapat dipublikasikan di Play Store.

Android App Bundle (AAB) — format publikasi wajib sejak Agustus 2021. APK tidak lagi diterima di Google Play (kecuali — aplikasi dengan ukuran > 150 MB dan beberapa proyek legacy). Format AAB memungkinkan Google menghasilkan APK yang dioptimalkan untuk setiap API Level dan kerapatan layar, mengurangi ukuran unduhan sebesar 15-30%. Untuk memeriksa targetSdk, Google Play menganalisis manifes AAB dan jika tidak sesuai, menampilkan kesalahan dengan nilai minimum yang diperlukan.

Google Play Console memeriksa targetSdkVersion tidak hanya saat mengunggah AAB baru, tetapi juga saat memperbarui aplikasi yang ada. Jika aplikasi Anda memiliki targetSdk 33 dan Google menaikkan ambang minimum menjadi 34 — Anda tidak dapat merilis pembaruan apa pun hingga Anda menaikkan targetSdk. Untuk aplikasi yang sudah lama tidak diperbarui, Google Play dapat secara otomatis menghapusnya dari publikasi (unpublish).

Cara memperbarui targetSdkVersion tanpa kesalahan

Memperbarui targetSdkVersion — bukan sekadar mengubah angka di build.gradle. Setiap behavioural change dapat merusak fungsionalitas yang ada jika kode tidak dipersiapkan sebelumnya. Disarankan untuk memulai persiapan 3-6 bulan sebelum tenggat waktu Google Play, terutama jika aplikasi besar dan menggunakan banyak API sistem.

Proses langkah demi langkah: Langkah 1 — pelajari behavioural changes untuk API Level baru di dokumentasi Android Developers (halaman "Behavioural Changes by API Level"). Langkah 2 — buat cabang targetSdk-update dan ubah targetSdk ke nilai baru. Langkah 3 — jalankan aplikasi di emulator atau perangkat dengan API Level baru dan periksa setiap fungsionalitas yang terkait dengan perubahan. Langkah 4 — perbaiki kesalahan: tambahkan izin, ubah cara kerja dengan file, perbarui manifes.

Langkah 5 — uji pada perangkat lama. Peningkatan targetSdk tidak memengaruhi perangkat dengan API Level lebih rendah dari targetSdk baru, tetapi behavioural changes diterapkan pada semua perangkat dengan API Level >= targetSdk. Jika Anda menaikkan targetSdk dari 33 ke 34, pada perangkat dengan API 34+ behavioural changes API 34 akan aktif. Pada perangkat dengan API 33 tidak ada yang berubah.

// Persiapan untuk 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? {
        // Privacy Sandbox membatasi Advertising ID mulai API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — pengidentifikasi tidak tersedia, gunakan MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Pemeriksaan: behavioural changes mana yang aktif
    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")
        }
    }
}

Kelas AdsManager menunjukkan persiapan untuk Privacy Sandbox (API 35). Advertising ID tidak lagi tersedia mulai API 35 dengan targetSdk 35+. Fungsi getActiveChanges menunjukkan pola yang benar untuk memeriksa behavioural changes: SDK_INT perangkat dan targetSdk aplikasi harus diperiksa secara bersamaan. Hanya jika kedua kondisi terpenuhi, perubahan benar-benar aktif.

Android 15 (API 35): behavioural changes kunci

Android 15 (API 35, Vanilla Ice Cream) memperkenalkan beberapa behavioural changes kritis yang harus dipertimbangkan pengembang saat memperbarui targetSdk ke 35. Pertama — Privacy Sandbox for Android. Ini adalah inisiatif Google untuk mengganti Advertising ID dengan API yang lebih privat: Topics API (minat pengguna), Protected Audience (remarketing), dan Attribution Reporting (konversi). Mulai API 35, Advertising ID tidak lagi menjadi pengidentifikasi yang stabil dan dapat mengembalikan nilai nol.

Perubahan kedua — Foreground Service Types (API 34, dilanjutkan di API 35). Mulai API 34, setiap aplikasi dengan targetSdk 34+ harus menentukan tipe layanan foreground di manifes: dataSync, systemExempted, shortService, location, mediaPlayback, dan lainnya. Tanpa ini, sistem menghasilkan ForegroundServiceTypeNotAllowedException. Di API 35, tipe baru health ditambahkan dan pemeriksaan tipe yang ada diperketat. Semua layanan foreground harus ditinjau ulang.

Perubahan ketiga — pembatasan SCHEDULE_EXACT_ALARM. Mulai API 35, aplikasi dengan targetSdk 35+ tidak dapat menggunakan SCHEDULE_EXACT_ALARM tanpa izin eksplisit pengguna. Sistem menampilkan dialog, dan pengguna harus menyetujui penjadwalan yang tepat. Untuk alarm dan pengatur waktu, ini berarti langkah tambahan dalam UX. Alternatif — menggunakan alarm inexact dengan cadangan 10 menit.

// Android 15 (API 35): pemeriksaan 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+: memerlukan izin pengguna
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Di bawah API 35 — alarm tepat tersedia tanpa izin
        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 dan pembatasan alarm — dua behavioural changes paling kritis di API 35. Untuk SDK iklan, migrasi ke Topics API dan Attribution Reporting akan diperlukan. Untuk aplikasi dengan alarm dan pengingat — adaptasi UX ke dialog izin. Mengabaikan perubahan ini akan menyebabkan crash aplikasi di runtime pada Android 15 atau monetisasi iklan yang tidak berfungsi.

Perbedaan antara targetSdk dan compileSdk

Perbedaan antara targetSdkVersion dan compileSdkVersion — salah satu topik paling membingungkan di kalangan pengembang Android. compileSdkVersion — adalah versi SDK yang digunakan untuk mengompilasi kode. Ini menentukan API mana yang tersedia selama kompilasi, tetapi tidak memengaruhi perilaku runtime. targetSdkVersion — adalah versi tempat aplikasi diuji, menentukan behavioural changes mana yang diterapkan di runtime. compileSdk dapat dan harus lebih tinggi atau sama dengan targetSdk.

Aturannya sederhana: compileSdk >= targetSdk >= minSdk. compileSdk biasanya sama dengan API Level stabil terakhir (pada 2026 — 36). targetSdk harus setinggi mungkin di antara versi yang telah diuji. minSdk harus serendah mungkin untuk cakupan maksimal. Menaikkan compileSdk tidak memerlukan pengujian behavioural changes — hanya membuka akses ke API baru untuk kompilator. Menaikkan targetSdk memerlukan siklus pengujian penuh semua behavioural changes.

Dalam praktiknya: jika Anda ingin menggunakan API baru dari Android 16 (API 36), tetapi behavioural changes API 36 belum diuji, setel compileSdk = 36, targetSdk = 35. Kode akan dikompilasi dengan API baru, tetapi behavioural changes API 36 tidak akan diterapkan. Setelah Anda menguji semua perubahan — naikkan targetSdk ke 36.