targetSdkVersion: แนวคิดหลัก การเปลี่ยนแปลงพฤติกรรม และ Google Play

targetSdkVersion ใน Android คืออะไร?

targetSdkVersion เป็นพารามิเตอร์จำนวนเต็มใน build.gradle ที่ประกาศ API Level ที่แอปได้รับการทดสอบ ระบบ Android ใช้พารามิเตอร์นี้เพื่อตัดสินใจว่า behavioural changes ใดที่จะนำไปใช้กับแอปในขณะรันไทม์ หาก targetSdkVersion = 33 Android จะใช้ behavioural changes ทั้งหมดที่นำมาจนถึง API 33 รวมอยู่ด้วย แต่จะไม่ใช้การเปลี่ยนแปลงของ API 34+ หาก targetSdkVersion = 34 — การเปลี่ยนแปลงจนถึง API 34 จะถูกนำไปใช้ และต่อไปเรื่อย ๆ

ความแตกต่างหลักระหว่าง targetSdkVersion และ minSdkVersion คือกลไกการทำงาน minSdk จะถูกตรวจสอบครั้งเดียวระหว่างการติดตั้งและบล็อกการติดตั้งหากไม่เป็นไปตามเงื่อนไข targetSdkVersion ส่งผลต่อพฤติกรรมรันไทม์ของระบบบนแต่ละอุปกรณ์ โดยไม่ขึ้นกับเวอร์ชัน Android ที่แอปทำงานอยู่ แอปเดียวกันกับ targetSdk 31 จะทำงานแตกต่างกันบน Android 13, 14 และ 15 เพราะ behavioural changes ที่สูงกว่า 31 ถูกปิดใช้งาน

กลไก targetSdkVersion เป็นเครื่องมือความเข้ากันได้ย้อนหลังที่สร้างใน Android หากไม่มีมัน ทุกการอัปเดตระบบปฏิบัติการจะทำให้แอปเก่าหลายพันรายการเสียหาย Google นำกลไกนี้มาใช้ใน Android 2.1 (API Level 7) และตั้งแต่นั้นมาใช้เป็นวิธีมาตรฐานในการแนะนำกฎความปลอดภัย ความเป็นส่วนตัว และการจัดการทรัพยากรใหม่โดยไม่ทำลายแอปพลิเคชันที่มีอยู่

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // ทดสอบบน Android 16
        versionCode = 1
        versionName = "1.0.0"
    }
}

// ตรวจสอบ targetSdk ปัจจุบันในโค้ด
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion มี targetSdk ของแอป
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

ในตัวอย่าง targetSdk = 36 เปิดใช้งาน behavioural changes ทั้งหมดของ Android 16 โค้ดตรวจสอบ targetSdkVersion ผ่าน context.applicationInfo.targetSdkVersion — ซึ่งช่วยให้ระบุโหมดความเข้ากันได้ที่เปิดใช้งานอยู่ได้แบบไดนามิก ฟังก์ชันตัวช่วยมีประโยชน์สำหรับไลบรารีที่ต้องปรับให้เข้ากับ targetSdk ของแอปพลิเคชันที่เรียกใช้

Behavioural Changes: targetSdk ส่งผลต่อแอปอย่างไร

Behavioural changes คือการปรับเปลี่ยนพฤติกรรมของระบบ Android ที่ใช้เฉพาะกับแอปที่มี targetSdkVersion >= ระดับ API Level ที่กำหนด ทุกเวอร์ชันหลักใหม่ของ Android จะแนะนำ behavioural changes และหากแอปไม่อัปเดต targetSdk การเปลี่ยนแปลงเหล่านี้จะไม่มีผล กลไกนี้ช่วยให้นักพัฒนาสามารถอัปเดตแอปตามจังหวะของตนเอง แทนที่จะต้องทำพร้อมกันกับการเปิดตัวระบบปฏิบัติการใหม่

Scoped Storage (API 29) เป็นหนึ่งใน behavioural changes ที่สำคัญที่สุด แอปที่มี targetSdk 29+ ไม่สามารถเข้าถึงไฟล์โดยตรงไปยังไดเรกทอรีที่ใช้ร่วมกัน Pictures, Downloads, Music, Documents ได้ แต่จะใช้ MediaStore สำหรับสื่อ SAF (Storage Access Framework) สำหรับไฟล์ทั่วไป และ getExternalFilesDir() สำหรับพื้นที่เก็บข้อมูลส่วนตัว แอปเก่าที่มี targetSdk 28 และต่ำกว่ายังคงทำงานกับ Full Storage Access แบบเดิม แต่สิ่งนี้สร้างความเสี่ยงด้านความปลอดภัย

POST_NOTIFICATIONS (API 33) คือการอนุญาตรันไทม์สำหรับการส่งการแจ้งเตือน แอปที่มี targetSdk 33+ ต้องขออนุญาต Manifest.permission.POST_NOTIFICATIONS จากผู้ใช้ผ่านกล่องโต้ตอบมาตรฐาน หากไม่ได้รับอนุญาต NotificationManager.silent() จะไม่แสดงการแจ้งเตือนแก่ผู้ใช้ บน Android 13+ หากไม่มีสิทธิ์นี้ การแจ้งเตือนแบบพุชและการแจ้งเตือนภายในจะไม่แสดง ซึ่งอาจลดการมีส่วนร่วมของผู้ใช้ได้อย่างมาก

วิธีตรวจสอบ targetSdk ปัจจุบัน

ค่า targetSdkVersion สามารถหาได้ผ่าน ADB: คำสั่ง adb shell dumpsys package com.example.myapp | grep targetSdk แสดงผล targetSdk=34 ในโค้ด context.getApplicationInfo().targetSdkVersion คืนค่าเป็นจำนวนเต็ม สำหรับการวิเคราะห์ ควรบันทึก targetSdk ร่วมกับ android.os.Build.VERSION.SDK_INT เพื่อทำความเข้าใจว่า behavioural changes ใดทำงานจริงในแต่ละเซสชัน

ข้อกำหนดของ Google Play สำหรับ targetSdkVersion (2026)

Google Play กำหนดข้อกำหนด targetSdkVersion ที่บังคับสำหรับแอปที่เผยแพร่ทั้งหมด ตั้งแต่สิงหาคม 2024 ค่า targetSdk ขั้นต่ำ = 33 (Android 13) ตั้งแต่สิงหาคม 2025 targetSdk = 34 คาดว่าตั้งแต่สิงหาคม 2026 Google จะกำหนด targetSdk = 35 (Android 15) แอปใหม่และการอัปเดตแอปที่มีอยู่ต้องปฏิบัติตามข้อกำหนดเหล่านี้ มิฉะนั้นคอนโซลจะบล็อกการเผยแพร่ นโยบายนี้เป็นของ Google Play ไม่ใช่ข้อจำกัดของ Android Runtime: แอปที่มี targetSdk 34 สามารถทำงานบน Android 16 ได้ แต่ไม่สามารถเผยแพร่ใน Play Store ได้

Android App Bundle (AAB) เป็นรูปแบบการเผยแพร่ที่บังคับตั้งแต่สิงหาคม 2021 APK ไม่ได้รับการยอมรับใน Google Play อีกต่อไป (ยกเว้นแอปที่มีขนาดใหญ่กว่า 150 MB และโครงการเดิมบางส่วน) รูปแบบ AAB ช่วยให้ Google สร้าง APK ที่ปรับให้เหมาะสมสำหรับแต่ละ API Level และความหนาแน่นของหน้าจอ ซึ่งลดขนาดดาวน์โหลดลง 15-30% ในการตรวจสอบ targetSdk Google Play จะวิเคราะห์ manifest ของ AAB และแสดงข้อผิดพลาดพร้อมค่าขั้นต่ำที่ต้องการหากไม่เป็นไปตามข้อกำหนด

Google Play Console ตรวจสอบ targetSdkVersion ไม่เพียงเมื่ออัปโหลด AAB ใหม่ แต่ยังเมื่ออัปเดตแอปที่มีอยู่ หากแอปของคุณมี targetSdk 33 และ Google เพิ่มเกณฑ์ขั้นต่ำเป็น 34 — คุณจะไม่สามารถเผยแพร่การอัปเดตใด ๆ จนกว่าจะเพิ่ม targetSdk สำหรับแอปที่ไม่ได้อัปเดตเป็นเวลานาน Google Play อาจนำออกจากการเผยแพร่โดยอัตโนมัติ (unpublish)

วิธีอัปเดต targetSdkVersion โดยไม่มีข้อผิดพลาด

การอัปเดต targetSdkVersion ไม่ใช่แค่การเปลี่ยนตัวเลขใน build.gradle แต่ละ behavioural change สามารถทำลายฟังก์ชันการทำงานที่มีอยู่ได้หากไม่ได้เตรียมโค้ดล่วงหน้า ขอแนะนำให้เริ่มเตรียมการ 3-6 เดือนก่อนกำหนดเส้นตายของ Google Play โดยเฉพาะอย่างยิ่งหากแอปมีขนาดใหญ่และใช้ API ระบบจำนวนมาก

กระบวนการทีละขั้นตอน: ขั้นตอนที่ 1 — ศึกษา behavioural changes สำหรับ API Level ใหม่ในเอกสาร Android Developers (หน้า "Behavioural Changes by API Level") ขั้นตอนที่ 2 — สร้าง branch targetSdk-update และเปลี่ยน targetSdk เป็นค่าใหม่ ขั้นตอนที่ 3 — รันแอปบนอีมูเลเตอร์หรืออุปกรณ์ที่มี API Level ใหม่และตรวจสอบทุกฟังก์ชันที่เกี่ยวข้องกับการเปลี่ยนแปลง ขั้นตอนที่ 4 — แก้ไขข้อผิดพลาด: เพิ่มสิทธิ์ เปลี่ยนการจัดการไฟล์ อัปเดต manifest

ขั้นตอนที่ 5 — ทดสอบบนอุปกรณ์เก่า การเพิ่ม targetSdk ไม่ส่งผลต่ออุปกรณ์ที่มี API Level ต่ำกว่า targetSdk ใหม่ แต่ behavioural changes ใช้กับอุปกรณ์ทั้งหมดที่มี API Level >= targetSdk หากคุณเพิ่ม targetSdk จาก 33 เป็น 34 บนอุปกรณ์ที่มี API 34+ behavioural changes ของ API 34 จะเปิดใช้งาน บนอุปกรณ์ที่มี API 33 จะไม่มีอะไรเปลี่ยนแปลง

// การเตรียมพร้อมสำหรับ 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 จำกัด Advertising ID ตั้งแต่ API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — ตัวระบุไม่พร้อมใช้งาน ใช้ MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // ตรวจสอบ: behavioural changes ใดที่ทำงานอยู่
    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")
        }
    }
}

คลาส AdsManager แสดงการเตรียมพร้อมสำหรับ Privacy Sandbox (API 35) Advertising ID จะไม่สามารถใช้ได้ตั้งแต่ API 35 เป็นต้นไปด้วย targetSdk 35+ ฟังก์ชัน getActiveChanges แสดงรูปแบบที่ถูกต้องสำหรับการตรวจสอบ behavioural changes: ต้องตรวจสอบทั้ง SDK_INT ของอุปกรณ์และ targetSdk ของแอป เฉพาะเมื่อทั้งสองเงื่อนไขตรงกัน การเปลี่ยนแปลงจึงจะทำงานจริง

Android 15 (API 35): behavioural changes ที่สำคัญ

Android 15 (API 35, Vanilla Ice Cream) นำเสนอ behavioural changes ที่สำคัญหลายประการที่นักพัฒนาต้องพิจารณาเมื่ออัปเดต targetSdk เป็น 35 อย่างแรก — Privacy Sandbox for Android นี่คือโครงการริเริ่มของ Google เพื่อแทนที่ Advertising ID ด้วย API ที่เป็นส่วนตัวมากขึ้น: Topics API (ความสนใจของผู้ใช้), Protected Audience (การกำหนดเป้าหมายซ้ำ) และ Attribution Reporting (การแปลง) ตั้งแต่ API 35 Advertising ID จะไม่เป็นตัวระบุที่เสถียรอีกต่อไปและอาจคืนค่าเป็น null

การเปลี่ยนแปลงที่สอง — Foreground Service Types (API 34, ต่อเนื่องใน API 35) ตั้งแต่ API 34 ทุกแอปที่มี targetSdk 34+ ต้องระบุประเภทบริการเบื้องหน้าใน manifest: dataSync, systemExempted, shortService, location, mediaPlayback และอื่น ๆ หากไม่มี ระบบจะสร้าง ForegroundServiceTypeNotAllowedException ใน API 35 มีการเพิ่มประเภท health ใหม่และการตรวจสอบประเภทที่มีอยู่ถูกทำให้เข้มงวดขึ้น ต้องตรวจสอบบริการเบื้องหน้าทั้งหมด

การเปลี่ยนแปลงที่สาม — ข้อจำกัดของ SCHEDULE_EXACT_ALARM ตั้งแต่ API 35 แอปที่มี targetSdk 35+ ไม่สามารถใช้ SCHEDULE_EXACT_ALARM โดยไม่ได้รับอนุญาตอย่างชัดแจ้งจากผู้ใช้ ระบบจะแสดงกล่องโต้ตอบและผู้ใช้ต้องอนุมัติการกำหนดเวลาที่แน่นอน สำหรับนาฬิกาปลุกและตัวจับเวลา นี่หมายถึงขั้นตอน UX เพิ่มเติม ทางเลือกคือใช้นาฬิกาปลุกแบบไม่แน่นอนที่มีระยะเผื่อ 10 นาที

// Android 15 (API 35): ตรวจสอบ 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+: ต้องการสิทธิ์จากผู้ใช้
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // ต่ำกว่า API 35 — นาฬิกาปลุกแบบแม่นยำพร้อมใช้งานโดยไม่ต้องขอสิทธิ์
        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 และข้อจำกัดของนาฬิกาปลุกเป็น behavioural changes ที่สำคัญที่สุดสองประการของ API 35 SDK โฆษณาจะต้องย้ายไปใช้ Topics API และ Attribution Reporting สำหรับแอปที่มีนาฬิกาปลุกและการเตือน — การปรับ UX สำหรับกล่องโต้ตอบการอนุญาต การเพิกเฉยต่อการเปลี่ยนแปลงเหล่านี้จะทำให้แอปขัดข้องขณะรันไทม์บน Android 15 หรือรายได้จากโฆษณาเสียหาย

ความแตกต่างระหว่าง targetSdk และ compileSdk

ความแตกต่างระหว่าง targetSdkVersion และ compileSdkVersion เป็นหนึ่งในแหล่งที่มาของความสับสนที่พบบ่อยที่สุดในหมู่นักพัฒนา Android compileSdkVersion คือเวอร์ชันของ SDK ที่ใช้คอมไพล์โค้ด มันกำหนดว่า API ใดบ้างที่พร้อมใช้งานในเวลาคอมไพล์ แต่ไม่ส่งผลต่อพฤติกรรมรันไทม์ targetSdkVersion คือเวอร์ชันที่แอปถูกทดสอบ — มันกำหนดว่า behavioural changes ใดที่ใช้ในรันไทม์ compileSdk สามารถและควรสูงกว่าหรือเท่ากับ targetSdk

กฎง่าย ๆ คือ: compileSdk >= targetSdk >= minSdk compileSdk มักจะเท่ากับ API Level ที่เสถียรล่าสุด (ในปี 2026 — 36) targetSdk ควรสูงที่สุดเท่าที่เป็นไปได้ในบรรดาเวอร์ชันที่คุณทดสอบ minSdk ควรต่ำที่สุดเท่าที่เป็นไปได้เพื่อการเข้าถึงสูงสุด การเพิ่ม compileSdk ไม่จำเป็นต้องทดสอบ behavioural changes — มันเพียงเปิดการเข้าถึง API ใหม่สำหรับคอมไพเลอร์ การเพิ่ม targetSdk ต้องมีวงจรการทดสอบ behavioural changes ทั้งหมดอย่างสมบูรณ์

ในทางปฏิบัติ: หากคุณต้องการใช้ API ใหม่จาก Android 16 (API 36) แต่ยังไม่ได้ทดสอบ behavioural changes ของ API 36 ให้ตั้งค่า compileSdk = 36, targetSdk = 35 โค้ดจะคอมไพล์ด้วย API ใหม่ แต่ behavioural changes ของ API 36 จะไม่ถูกนำไปใช้ เมื่อคุณทดสอบการเปลี่ยนแปลงทั้งหมดแล้ว — เพิ่ม targetSdk เป็น 36