Android 16 ในปี 2026: API ใหม่ Desktop Mode และคำถามสัมภาษณ์

เจาะลึก Android 16 (API 36) ครอบคลุม desktop mode, การแจ้งเตือน ProgressStyle, predictive back, การบังคับใช้ edge-to-edge และคำถามสัมภาษณ์ที่มาพร้อมกับการเปลี่ยนแปลงเหล่านี้

ภาพประกอบ desktop mode และ API ใหม่ของ Android 16 สำหรับนักพัฒนา

Android 16 (API level 36 รหัสพัฒนา "Baklava") ถือเป็นหนึ่งในการอัปเดตแพลตฟอร์มที่ส่งผลกระทบมากที่สุดนับตั้งแต่การยกเครื่องด้วย Material You ของ Android 12 หลังเปิดตัวเวอร์ชันเสถียรเมื่อวันที่ 10 มิถุนายน 2025 ปัจจุบันทำงานบนอุปกรณ์ที่ใช้งานจริงมากกว่า 21% ณ เดือนมีนาคม 2026 จึงกลายเป็นเวอร์ชัน Android เดียวที่มีการติดตั้งใช้งานแพร่หลายที่สุด สำหรับนักพัฒนา Android ที่เตรียมตัวสัมภาษณ์งานในปี 2026 การเข้าใจการเปลี่ยนแปลงของ API เหล่านี้เป็นสิ่งที่หลีกเลี่ยงไม่ได้

ประเด็นสำคัญสำหรับการสัมภาษณ์

Android 16 บังคับใช้การเปลี่ยนแปลงเชิงพฤติกรรมสามประการสำหรับแอปที่ตั้ง target เป็น API 36 ได้แก่ การเรนเดอร์แบบ edge-to-edge เป็นข้อบังคับ ข้อจำกัดด้านการหมุนหน้าจอและการปรับขนาดจะถูกเพิกเฉยบนหน้าจอขนาดใหญ่ (ตั้งแต่ 600dp ขึ้นไป) และต้องจัดการการนำทางย้อนกลับแบบ predictive back อย่างถูกต้อง ทุกการสัมภาษณ์งาน Android ในปี 2026 จะแตะอย่างน้อยหนึ่งในสามประเด็นนี้

โมเดลการปล่อย SDK ของ Android 16 และกลยุทธ์ Major-Minor

Android 16 นำโครงสร้างการปล่อยเวอร์ชันแบบคู่มาใช้ ซึ่งเปลี่ยนวิธีที่นักพัฒนาวางแผนการรับฟีเจอร์ใหม่ SDK เวอร์ชันหลัก (major) มาพร้อมกับ Beta 3 ในเดือนมีนาคม 2025 โดยล็อกการเปลี่ยนแปลงเชิงพฤติกรรมและ API หลักไว้ ตามด้วย SDK เวอร์ชันรอง (minor) เมื่อวันที่ 2 ธันวาคม 2025 ที่เพิ่ม API ใหม่โดยไม่เปลี่ยนพฤติกรรมของแพลตฟอร์ม

การแยกออกจากกันนี้มีความสำคัญในการสัมภาษณ์ เวอร์ชันหลักคือที่ที่การเปลี่ยนแปลงซึ่งทำลายความเข้ากันได้อยู่ (edge-to-edge การบังคับเรื่องการหมุนหน้าจอ) ส่วนเวอร์ชันรองให้ความสามารถใหม่ (ไลบรารี Jetpack เพิ่มเติม API ที่เกี่ยวกับ AI) โดยไม่กระทบต่อพฤติกรรมของแอปที่มีอยู่เลย Google ออกแบบโมเดลนี้เพื่อเร่งการส่งมอบ API พร้อมกับมอบเป้าหมายประจำปีที่เสถียรและคาดเดาได้ให้ทีมระดับองค์กรเพื่อการปฏิบัติตามข้อกำหนด

คำถามสัมภาษณ์ที่พบบ่อยคือเรื่อง targetSdkVersion เทียบกับ compileSdkVersion ในบริบทของโมเดลคู่นี้ คำตอบคือ targetSdkVersion = 36 จะกระตุ้นการเปลี่ยนแปลงเชิงพฤติกรรมทั้งหมดจากเวอร์ชันหลัก ส่วน SDK เวอร์ชันรองเป็นแบบเพิ่มเติมเท่านั้น ไม่ต้องเปิดใช้งานหรืออัปเดต target แต่อย่างใด

การบังคับใช้ Edge-to-Edge บน API 36

แอปที่ตั้ง target เป็น Android 16 ไม่สามารถเลือกออกจากเลย์เอาต์แบบ edge-to-edge ได้อีกต่อไป ระบบจะเพิกเฉยต่อการเรียก setDecorFitsSystemWindows(true) และแฟล็กการมองเห็น SystemUI แบบเก่า ทุกแอปต้องจัดการ window insets ให้ถูกต้อง มิฉะนั้นเสี่ยงที่องค์ประกอบ UI จะถูกซ่อนอยู่หลังแถบสถานะและแถบนำทาง

MainActivity.ktkotlin
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // enableEdgeToEdge() is now the default on API 36+
        // No opt-out available
        enableEdgeToEdge()
        setContent {
            Scaffold(
                modifier = Modifier.fillMaxSize()
            ) { innerPadding ->
                // innerPadding accounts for system bars
                MainContent(
                    modifier = Modifier.padding(innerPadding)
                )
            }
        }
    }
}

คอมโพสเอเบิล Scaffold ใน Jetpack Compose จัดการ insets โดยอัตโนมัติผ่าน innerPadding สำหรับแอปที่อิงกับ View นั้น ViewCompat.setOnApplyWindowInsetsListener ยังคงเป็นแนวทางที่แนะนำ รายละเอียดสำคัญคือ ต้องบริโภค WindowInsetsCompat.Type.systemBars() อย่างชัดเจน มิฉะนั้นระบบจะใส่ระยะ padding ตามค่าเริ่มต้นที่อาจไม่ตรงกับการออกแบบของแอป

ผู้สัมภาษณ์มักถามว่าจะเกิดอะไรขึ้นกับแอปที่พึ่งพา android:fitsSystemWindows="true" ในเลย์เอาต์ XML บน API 36 แอตทริบิวต์นี้ยังคงทำงานได้แต่ใส่เพียงระยะ padding สำหรับแถบระบบเท่านั้น มันไม่ป้องกันไม่ให้แอปวาดแบบ edge-to-edge อีกต่อไป

แอปแบบ Adaptive และการเปลี่ยนแปลงการหมุนหน้าจอบนจอขนาดใหญ่

Android 16 เพิกเฉยต่อ android:screenOrientation และ android:resizeableActivity="false" สำหรับแอปที่ไม่ใช่เกมบนจอแสดงผลที่มี smallestWidth >= 600dp แท็บเล็ต อุปกรณ์พับได้ และจอภายนอกที่เชื่อมต่อผ่าน desktop mode ล้วนเข้าเงื่อนไขนี้ สิ่งนี้ยุติยุคของเลย์เอาต์แบบโทรศัพท์ที่มีขอบดำ (letterbox) บนหน้าจอขนาดใหญ่ที่ดำเนินมาหลายปี

kotlin
// Responsive layout using WindowSizeClass
@Composable
fun AdaptiveLayout() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
    when {
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.EXPANDED -> {
            // Two-pane layout for tablets/desktop
            TwoPaneLayout()
        }
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.MEDIUM -> {
            // Adapted layout for foldables
            MediumLayout()
        }
        else -> {
            // Phone layout
            CompactLayout()
        }
    }
}

ไลบรารี Jetpack WindowManager มี WindowSizeClass ให้สำหรับการออกแบบแบบ responsive มีพร็อพเพอร์ตีสำหรับเลือกออกให้กับแอปที่ตั้ง target เป็น API 36 โดยเฉพาะ แต่ Android 17 (คาดว่าไตรมาส 2 ปี 2026) จะลบตัวเลือกออกนี้ทิ้งทั้งหมด

ผู้สัมภาษณ์มักตั้งคำถามในรูปแบบ "จะย้ายแอปที่ล็อกเป็นแนวตั้งให้รองรับหน้าจอขนาดใหญ่อย่างไร" คำตอบเกี่ยวข้องกับการแทนที่การหมุนหน้าจอแบบตายตัวด้วยเลย์เอาต์แบบ responsive การทดสอบการเปลี่ยนแปลงคอนฟิก (โดยเฉพาะ onConfigurationChanged) และการตรวจสอบว่าสถานะที่บันทึกไว้คงอยู่ผ่านการเปลี่ยนขนาดหน้าจอ

Desktop Mode และจอแสดงผลที่เชื่อมต่อ

Desktop mode เปิดตัวเป็นฟีเจอร์ที่พร้อมใช้งานทั่วไปใน Android 16 QPR3 (Pixel Drop เดือนมีนาคม 2026) รองรับอุปกรณ์ Pixel 8 ขึ้นไป และ Samsung Galaxy S26/Fold7/Flip7 การเชื่อมต่อโทรศัพท์เข้ากับจอภายนอกผ่าน USB-C จะเปิดเซสชันเดสก์ท็อปอิสระที่มีแถบงาน หน้าต่างปรับขนาดได้ เดสก์ท็อปเสมือนหลายชุด และรองรับคีย์บอร์ดกับเมาส์อย่างเต็มรูปแบบ

LaunchOnExternalDisplay.ktkotlin
fun launchOnExternalDisplay(context: Context) {
    val displayManager = context.getSystemService(
        Context.DISPLAY_SERVICE
    ) as DisplayManager
    // Find external displays
    val externalDisplays = displayManager.displays.filter {
        it.displayId != Display.DEFAULT_DISPLAY
    }
    if (externalDisplays.isNotEmpty()) {
        val options = ActivityOptions.makeBasic().apply {
            launchDisplayId = externalDisplays.first().displayId
        }
        context.startActivity(
            Intent(context, DesktopActivity::class.java),
            options.toBundle()
        )
    }
}

โทรศัพท์และจอภายนอกทำงานอย่างเป็นอิสระต่อกัน แอปจะเจาะจงกับจอแสดงผลที่มันทำงานอยู่ Google และ Samsung ร่วมมือกันพัฒนาประสบการณ์ desktop windowing เพื่อลดความกระจัดกระจายทั่วทั้งระบบนิเวศ Samsung DeX ผสานรวม API ของแพลตฟอร์มชุดเดียวกันนี้ ทำให้เกิดเป้าหมายการพัฒนาที่เป็นหนึ่งเดียว

ข้อพิจารณาสำคัญสำหรับนักพัฒนาในเรื่อง desktop mode มีดังนี้

  • เมตริกของหน้าต่างเปลี่ยนแปลงแบบไดนามิก อย่าแคชอ็อบเจกต์ Display ให้สอบถาม WindowMetricsCalculator หรือ LocalConfiguration ของ Compose ทุกครั้งที่คอนฟิกเปลี่ยน
  • การรองรับคีย์บอร์ดและเมาส์ อุปกรณ์ต่อพ่วงภายนอกเป็นเรื่องปกติในเซสชันเดสก์ท็อป ต้องจัดการการกระจาย KeyEvent และสถานะ hover ของตัวชี้
  • การรองรับหลายอินสแตนซ์ ผู้ใช้เดสก์ท็อปคาดหวังหน้าต่างของแอปเดียวกันหลายบาน ให้ประกาศ android:documentLaunchMode="intoExisting" หรือจัดการ FLAG_ACTIVITY_NEW_DOCUMENT อย่างเหมาะสม

พร้อมที่จะพิชิตการสัมภาษณ์ Android แล้วหรือยังครับ?

ฝึกฝนด้วยตัวจำลองแบบโต้ตอบ, flashcards และแบบทดสอบเทคนิคครับ

การแจ้งเตือนแบบ ProgressStyle และ Live Updates

Android 16 นำเสนอ Notification.ProgressStyle ซึ่งเป็นเทมเพลตการแจ้งเตือนใหม่สำหรับเส้นทางผู้ใช้ที่เน้นความคืบหน้า เช่น การติดตามบริการเรียกรถ การอัปเดตการจัดส่ง และการนำทาง สิ่งนี้มาแทนที่เลย์เอาต์การแจ้งเตือนแบบกำหนดเองที่ทำกันเฉพาะกิจด้วยรูปแบบมาตรฐานที่ระบบส่งเสริมให้แสดงเด่นขึ้น

DeliveryNotificationHelper.ktkotlin
fun buildDeliveryNotification(
    context: Context,
    orderId: String,
    progress: Float,  // 0.0 to 1.0
    currentStep: String
): Notification {
    val style = Notification.ProgressStyle()
        .setStyledByProgress(true)
        .setProgress(progress)
        .setProgressTrackerIcon(
            Icon.createWithResource(context, R.drawable.ic_delivery_truck)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_preparing)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_in_transit)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.34f)
                .setColor(context, R.color.segment_delivered)
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.0f)
                .setLabel("Order placed")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.33f)
                .setLabel("Preparing")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.66f)
                .setLabel("In transit")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(1.0f)
                .setLabel("Delivered")
        )

    return Notification.Builder(context, DELIVERY_CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle("Order #$orderId")
        .setContentText(currentStep)
        .setStyle(style)
        .setOngoing(true)
        .build()
}

ProgressStyle รองรับ segment (ส่วนของแถบความคืบหน้าที่มีสี) point (จุดหมายสำคัญที่มีป้ายกำกับ) และไอคอนตัวติดตามที่เลื่อนไปตามแถบ การตั้งค่า setStyledByProgress(true) ทำให้ระบบลงสีให้กับ segment ตามความคืบหน้าที่เสร็จสิ้น สำหรับการเตรียมตัวสัมภาษณ์เรื่องการแจ้งเตือนบน Android การเข้าใจว่าเมื่อใดควรใช้ ProgressStyle แทนการแจ้งเตือนแบบ setProgress() มาตรฐานเป็นสิ่งจำเป็น ProgressStyle เหมาะกับเส้นทางหลายขั้นตอนที่มีจุดหมายสำคัญแยกชัดเจน ส่วน setProgress() ยังคงเหมาะกับงานเดี่ยว เช่น การดาวน์โหลดไฟล์

การนำทางย้อนกลับแบบ Predictive Back ด้วย OnBackInvokedCallback

Android 16 ทำให้การย้ายจาก onBackPressed() ไปสู่ API OnBackInvokedCallback ที่ดำเนินมาหลายปีเสร็จสมบูรณ์ ระบบจะแสดงแอนิเมชัน "ชะโงกดู" (peek) ของหน้าจอปลายทางระหว่างการปัดย้อนกลับ ทำให้ผู้ใช้สามารถยืนยันหรือยกเลิกได้ แอปที่ยังคงโอเวอร์ไรด์ onBackPressed() โดยไม่ลงทะเบียน callback จะทำให้แอนิเมชันนี้เสีย

DetailActivity.ktkotlin
class DetailActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= 36) {
            onBackInvokedDispatcher.registerOnBackInvokedCallback(
                OnBackInvokedDispatcher
                    .PRIORITY_SYSTEM_NAVIGATION_OBSERVER
            ) {
                // Observe back navigation without intercepting
                // Log analytics or trigger save-draft logic
                analyticsTracker.logBackNavigation(
                    screen = "detail"
                )
            }
        }
    }
}

ลำดับความสำคัญใหม่ PRIORITY_SYSTEM_NAVIGATION_OBSERVER ช่วยให้แอปสังเกตเหตุการณ์การย้อนกลับได้โดยไม่บล็อกแอนิเมชันของระบบ Android 16 ยังเพิ่ม finishAndRemoveTaskCallback และ moveTaskToBackCallback สำหรับพฤติกรรม back-stack แบบกำหนดเองที่ยังคงผสานรวมกับแอนิเมชัน predictive ได้

Predictive back ยังทำงานบนการนำทางแบบ 3 ปุ่มใน Android 16 ด้วย การกดปุ่มย้อนกลับค้างไว้จะเริ่มแอนิเมชันตัวอย่าง นี่เป็นหัวข้อสัมภาษณ์ที่พบบ่อย ผู้สมัครที่กล่าวถึงแต่การนำทางด้วยท่าทาง (gesture) จะพลาดเรื่องราวไปครึ่งหนึ่ง

Notification Cooldown และการจัดกลุ่มแบบบังคับ

การเปลี่ยนแปลงการแจ้งเตือนเพิ่มเติมอีกสองข้อส่งผลต่อทุกแอป Android การหน่วงเวลาการแจ้งเตือน (notification cooldown) จะลดปริมาณการแจ้งเตือนที่ถาโถมมาอย่างรวดเร็วจากแอปเดียวกัน โดยค่อย ๆ ลดระดับเสียงลงในเวลาประมาณ 60 วินาทีก่อนรีเซ็ต ฟีเจอร์นี้เปิดใช้งานโดยค่าเริ่มต้นและนักพัฒนาไม่สามารถเขียนทับได้

การจัดกลุ่มการแจ้งเตือนแบบบังคับหมายความว่าระบบจะจัดกลุ่มการแจ้งเตือนโดยอัตโนมัติ ไม่ว่าแอปจะใช้ setGroup() หรือไม่ก็ตาม แอปที่พึ่งพาความโดดเด่นของการแจ้งเตือนแต่ละรายการเพื่อเพิ่มการมีส่วนร่วมอาจต้องทบทวนกลยุทธ์การแจ้งเตือนใหม่

สำหรับการเตรียมตัวสัมภาษณ์ การเปลี่ยนแปลงเหล่านี้เข้าคู่ได้ดีกับคำถามเรื่องKotlin coroutines และ Flow เนื่องจากการจัดกลุ่มและการควบคุมอัตราการแจ้งเตือนอย่างมีประสิทธิภาพมักเกี่ยวข้องกับรูปแบบ debouncing ที่อิงกับ coroutine

Health Connect FHIR APIs และ RangingManager

Android 16 ขยายความสามารถของ Health Connect ด้วยการรองรับการเขียน FHIR (Fast Healthcare Interoperability Resources) ทำให้แอปสุขภาพสามารถสร้างและจัดเก็บเวชระเบียนที่มีโครงสร้างได้ API RangingManager รวมการวัดระยะทางและมุมข้าม BLE channel sounding, BLE RSSI, Ultra-Wideband และ Wi-Fi RTT เข้าด้วยกัน ซึ่งรวบสิ่งที่ก่อนหน้านี้ต้องใช้พื้นผิว API แยกกันถึงสี่ชุด

ตัวเลือกรูปภาพ (photo picker) ได้รับ API การปรับแต่งที่ลึกขึ้น ทำให้นักพัฒนาควบคุมรูปลักษณ์ของตัวเลือกได้ขณะที่ยังคงรักษาโมเดลความปลอดภัยแบบ sandbox เดิมไว้ การค้นหาผ่านผู้ให้บริการสื่อบนคลาวด์ถูกเพิ่มเข้ามาใน Developer Preview 2

API เหล่านี้มีโอกาสปรากฏในการสัมภาษณ์ Android ทั่วไปน้อยกว่า แต่มีความสำคัญอย่างยิ่งสำหรับตำแหน่งงานเฉพาะทางในด้านเทคโนโลยีสุขภาพ IoT หรือแอปพลิเคชันที่เน้นสื่อเป็นหลัก

คำถามและคำตอบสัมภาษณ์ Android 16

ต่อไปนี้คือคำถามที่มีโอกาสปรากฏมากที่สุดในการสัมภาษณ์นักพัฒนา Android ปี 2026 ซึ่งดึงมาจากการเปลี่ยนแปลงเชิงพฤติกรรมและ API ที่กล่าวถึงข้างต้น

ถาม: การเปลี่ยนแปลงเชิงพฤติกรรมที่บังคับใช้เมื่อตั้ง target เป็น API 36 มีอะไรบ้าง มีการบังคับใช้สามอย่าง ได้แก่ การเรนเดอร์แบบ edge-to-edge (ไม่มีตัวเลือกออก) ข้อจำกัดการหมุนหน้าจอและการปรับขนาดถูกเพิกเฉยบนหน้าจอตั้งแต่ 600dp ขึ้นไป และการนำทางย้อนกลับแบบ predictive back ที่เปิดใช้งานทั่วทั้งระบบ แอปต้องจัดการ WindowInsets อย่างถูกต้อง รองรับเลย์เอาต์แบบ responsive และย้ายจาก onBackPressed() ไปสู่ OnBackInvokedCallback

ถาม: desktop mode ส่งผลต่อสถาปัตยกรรมแอปอย่างไร desktop mode สร้างเซสชันจอแสดงผลอิสระ แอปต้องหลีกเลี่ยงการแคชอ็อบเจกต์ Display รองรับเมตริกของหน้าต่างแบบไดนามิก จัดการอินพุตจากคีย์บอร์ดและเมาส์ และคำนึงถึงสถานการณ์หลายอินสแตนซ์ API ActivityOptions.launchDisplayId ช่วยให้เจาะจงไปยังจอแสดงผลเฉพาะได้ด้วยโปรแกรม

ถาม: เมื่อใดที่ ProgressStyle ควรมาแทนที่ setProgress() ProgressStyle เหมาะกับเส้นทางผู้ใช้หลายขั้นตอนที่มีจุดหมายสำคัญแยกชัดเจน (เรียกรถ จัดส่ง นำทาง) ส่วน setProgress() มาตรฐานยังคงเหมาะกับความคืบหน้าของงานเดี่ยว (ดาวน์โหลด อัปโหลดไฟล์) ProgressStyle ได้รับการแสดงผลที่โดดเด่นขึ้นในแถบการแจ้งเตือน

ถาม: โมเดลการปล่อย SDK แบบ major/minor ของ Android 16 คืออะไร เวอร์ชันหลัก (มีนาคม 2025) มีการเปลี่ยนแปลงเชิงพฤติกรรมและต้องอัปเดต targetSdkVersion ส่วนเวอร์ชันรอง (ธันวาคม 2025) เพิ่ม API ใหม่โดยไม่มีการเปลี่ยนพฤติกรรม จึงไม่ต้องเพิ่ม targetSdkVersion โมเดลนี้แยกความเสถียรออกจากนวัตกรรม

ถาม: predictive back ทำงานร่วมกับการนำทางแบบ 3 ปุ่มอย่างไร บน API 36 ขึ้นไป การกดปุ่มย้อนกลับค้างไว้บนการนำทางแบบ 3 ปุ่มจะเรียกแอนิเมชัน predictive เดียวกันกับการนำทางด้วยท่าทาง แอปต้องลงทะเบียน OnBackInvokedCallback ด้วยลำดับความสำคัญที่เหมาะสม ลำดับความสำคัญ PRIORITY_SYSTEM_NAVIGATION_OBSERVER ช่วยให้สังเกตได้โดยไม่ขัดจังหวะ

เริ่มฝึกซ้อมเลย!

ทดสอบความรู้ของคุณด้วยตัวจำลองสัมภาษณ์และแบบทดสอบเทคนิคครับ

บทสรุป

  • edge-to-edge ไม่ใช่ทางเลือกอีกต่อไปบน API 36 ตรวจสอบทุกหน้าจอเพื่อให้จัดการ WindowInsets ได้ถูกต้อง โดยเฉพาะ toolbar แบบกำหนดเองและ bottom sheet
  • แทนที่ไฟล์ manifest ที่ล็อกการหมุนหน้าจอด้วยเลย์เอาต์แบบ responsive ของ Jetpack Compose โดยใช้ WindowSizeClass ก่อนที่ Android 17 จะลบตัวเลือกออกทิ้ง
  • desktop mode พร้อมใช้งานจริงบน Pixel 8 ขึ้นไปและเรือธงของ Samsung ทดสอบแอปกับจอภายนอก อินพุตจากคีย์บอร์ด และสถานการณ์หลายอินสแตนซ์
  • ย้ายจาก onBackPressed() ไปสู่ OnBackInvokedCallback ใช้ PRIORITY_SYSTEM_NAVIGATION_OBSERVER สำหรับการติดตามข้อมูลวิเคราะห์โดยไม่บล็อกแอนิเมชันของระบบ
  • นำ Notification.ProgressStyle มาใช้กับเส้นทางผู้ใช้หลายขั้นตอนใด ๆ notification cooldown และการจัดกลุ่มแบบบังคับส่งผลต่อทุกแอปไม่ว่าจะตั้ง target SDK เป็นเวอร์ชันใด
  • โมเดล SDK แบบ major/minor หมายความว่าการเปลี่ยนแปลงเชิงพฤติกรรมจะมาปีละครั้ง ส่วน SDK เวอร์ชันรองนำ API ใหม่มาให้โดยไม่มีความเสี่ยงด้านความเข้ากันได้ จึงนำมาใช้ได้อย่างอิสระ

เริ่มฝึกซ้อมเลย!

ทดสอบความรู้ของคุณด้วยตัวจำลองสัมภาษณ์และแบบทดสอบเทคนิคครับ

แท็ก

#android
#android-16
#kotlin
#desktop-mode
#interview

แชร์

บทความที่เกี่ยวข้อง