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

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

- Published: 2026-05-29
- Updated: 2026-06-06
- Author: SharpSkill
- Tags: android, android-16, kotlin, desktop-mode, interview
- Reading time: 10 min

---

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 จะถูกซ่อนอยู่หลังแถบสถานะและแถบนำทาง

```kotlin
// MainActivity.kt
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](https://developer.android.com/develop/ui/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](https://developer.android.com/jetpack/androidx/releases/window) มี `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 จะเปิดเซสชันเดสก์ท็อปอิสระที่มีแถบงาน หน้าต่างปรับขนาดได้ เดสก์ท็อปเสมือนหลายชุด และรองรับคีย์บอร์ดกับเมาส์อย่างเต็มรูปแบบ

```kotlin
// LaunchOnExternalDisplay.kt
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](https://android-developers.googleblog.com/2026/03/android-devices-extend-seamlessly-to.html) เพื่อลดความกระจัดกระจายทั่วทั้งระบบนิเวศ Samsung DeX ผสานรวม API ของแพลตฟอร์มชุดเดียวกันนี้ ทำให้เกิดเป้าหมายการพัฒนาที่เป็นหนึ่งเดียว

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

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

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

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

```kotlin
// DeliveryNotificationHelper.kt
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](/technologies/android/interview-questions/android-background-work) การเข้าใจว่าเมื่อใดควรใช้ `ProgressStyle` แทนการแจ้งเตือนแบบ `setProgress()` มาตรฐานเป็นสิ่งจำเป็น `ProgressStyle` เหมาะกับเส้นทางหลายขั้นตอนที่มีจุดหมายสำคัญแยกชัดเจน ส่วน `setProgress()` ยังคงเหมาะกับงานเดี่ยว เช่น การดาวน์โหลดไฟล์

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

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

```kotlin
// DetailActivity.kt
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](/technologies/android/interview-questions/android-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](/technologies/android/interview-questions/android-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 ใหม่มาให้โดยไม่มีความเสี่ยงด้านความเข้ากันได้ จึงนำมาใช้ได้อย่างอิสระ

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/android/android-16-new-apis-desktop-mode-interview-questions