Android 16 у 2026 році: Нові API, десктопний режим та питання на співбесідах

Android 16 (рівень API 36, кодова назва «Baklava») є однією з найвпливовіших оновлень платформи з часів запровадження Material You в Android 12. Випущений як стабільна версія 10 червня 2025 року, він працює на понад 21% активних пристроїв станом на березень 2026 року, що робить його найпоширенішою версією Android. Для розробників Android, які готуються до співбесід у 2026 році, знання цих змін API є обов'язковою вимогою.

Модель випуску SDK в Android 16 — стратегія major/minor

Android 16 запроваджує двоетапну структуру випусків, яка змінює спосіб планування впровадження функцій розробниками. Основний SDK було випущено разом із Beta 3 у березні 2025 року, зафіксувавши зміни поведінки та базові API. Другий, мінорний SDK з'явився 2 грудня 2025 року, додавши нові API без зміни поведінки платформи.

Це розділення має велике значення на співбесідах: мажорний випуск — це місце, де знаходяться зміни, що порушують сумісність (рендеринг від краю до краю, примусова орієнтація), тоді як мінорний випуск надає нові можливості (додаткові бібліотеки Jetpack, API, пов'язані зі штучним інтелектом) без жодного впливу на наявну поведінку застосунків. Google розробив цю модель, щоб прискорити доставку API, водночас забезпечуючи корпоративним командам стабільну й передбачувану річну ціль для дотримання вимог сумісності.

Поширене питання на співбесіді стосується різниці між targetSdkVersion та compileSdkVersion у контексті цієї двоетапної моделі. Відповідь: встановлення targetSdkVersion = 36 активує всі зміни поведінки з мажорного випуску. Мінорний SDK є виключно адитивним — не потребує жодного opt-in чи оновлення таргету.

Обов'язковий режим від краю до краю в API 36

Застосунки, що орієнтуються на Android 16, більше не можуть відмовитися від макетів від краю до краю. Система ігнорує виклики setDecorFitsSystemWindows(true) та застарілі прапорці видимості SystemUI. Кожен застосунок повинен коректно обробляти window insets, інакше елементи інтерфейсу можуть бути приховані за рядком стану та панеллю навігації.

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 автоматично обробляє вставки через innerPadding. Для застосунків на основі View рекомендованим підходом залишається ViewCompat.setOnApplyWindowInsetsListener. Критична деталь: WindowInsetsCompat.Type.systemBars() має бути явно спожитий, інакше система застосує стандартний padding, який може не відповідати дизайну застосунку.

Інтерв'юери часто запитують, що відбувається із застосунками, які покладалися на android:fitsSystemWindows="true" у XML-макетах. В API 36 цей атрибут все ще працює, але лише застосовує padding для системних панелей — він більше не запобігає рендерингу застосунку від краю до краю.

Адаптивні застосунки та зміни орієнтації на великих екранах

Android 16 ігнорує android:screenOrientation та android:resizeableActivity="false" для неігрових застосунків на дисплеях із smallestWidth >= 600dp. Це стосується планшетів, складних пристроїв та зовнішніх моніторів, підключених через десктопний режим. Це завершує багаторічну практику відображення телефонних макетів у режимі letterbox на великих екранах.

// 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 для адаптивного дизайну. Властивість opt-out була доступна для застосунків, що орієнтувалися конкретно на API 36, але Android 17 (очікується у Q2 2026) повністю видаляє цю можливість.

Інтерв'юери зазвичай формулюють це питання так: «Як мігрувати застосунок, заблокований у портретній орієнтації, для підтримки великих екранів?» Відповідь включає заміну фіксованої орієнтації адаптивними макетами, тестування змін конфігурації (особливо onConfigurationChanged) та перевірку того, що збережений стан витримує зміни розміру екрана.

Десктопний режим та підключені дисплеї

Десктопний режим було випущено як загальнодоступну функцію в Android 16 QPR3 (березневе оновлення Pixel Drop 2026), з підтримкою пристроїв Pixel 8+ та Samsung Galaxy S26/Fold7/Flip7. Підключення телефону до зовнішнього монітора через USB-C запускає незалежну десктопну сесію з панеллю завдань, масштабованими вікнами, кількома віртуальними робочими столами та повною підтримкою клавіатури й миші.

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 спільно розробили десктопний віконний досвід, щоб зменшити фрагментацію в екосистемі. Samsung DeX інтегрує ті самі платформні API, створюючи єдину ціль для розробників.

Ключові аспекти для розробників щодо десктопного режиму:

• Метрики вікна змінюються динамічно. Об'єкти Display ніколи не слід кешувати. При кожній зміні конфігурації необхідно опитувати WindowMetricsCalculator або LocalConfiguration у Compose.
• Підтримка клавіатури та миші. Зовнішні периферійні пристрої є нормою в десктопних сесіях. Необхідно обробляти диспетчеризацію KeyEvent та стани наведення вказівника.
• Підтримка кількох екземплярів. Користувачі десктопного режиму очікують кілька вікон одного застосунку. Слід оголосити android:documentLaunchMode="intoExisting" або відповідно обробити FLAG_ACTIVITY_NEW_DOCUMENT.

Сповіщення ProgressStyle та оновлення в реальному часі

Android 16 представляє Notification.ProgressStyle — новий шаблон сповіщень для процесів, орієнтованих на прогрес, таких як відстеження поїздок, оновлення доставок та навігація. Він замінює тимчасові кастомні макети сповіщень стандартизованим форматом, що просувається системою.

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 підтримує сегменти (кольорові секції панелі прогресу), точки (позначені віхи) та іконку відстеження, що рухається вздовж панелі. Налаштування setStyledByProgress(true) дозволяє системі розфарбовувати сегменти на основі ступеня завершення. У контексті підготовки до співбесід щодо сповіщень Android критично важливо розуміти, коли використовувати ProgressStyle замість стандартного setProgress(): ProgressStyle призначений для багатоетапних процесів із чіткими віхами, тоді як setProgress() залишається відповідним для одноопераційних процесів, таких як завантаження файлів.

Предиктивна навігація назад з OnBackInvokedCallback

Android 16 завершує багаторічну міграцію з onBackPressed() на API OnBackInvokedCallback. Система тепер показує анімацію «підглядання» цільового екрана під час жесту повернення, дозволяючи користувачам підтвердити або скасувати дію. Застосунки, які продовжують перевизначати onBackPressed() без реєстрації callback, порушують цю анімацію.

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 для кастомної поведінки стеку повернення, яка все ще інтегрується з предиктивною анімацією.

Предиктивне повернення також працює на 3-кнопковій навігації в Android 16: довге натискання кнопки повернення ініціює анімацію попереднього перегляду. Це часта тема на співбесідах — кандидати, які згадують лише жестову навігацію, пропускають половину питання.

Охолодження сповіщень та обов'язкове групування

Дві додаткові зміни в сповіщеннях впливають на кожен Android-застосунок. Механізм охолодження сповіщень зменшує гучність сповіщень при швидких послідовних повідомленнях від того самого застосунку, поступово знижуючи рівень звуку протягом приблизно 60 секунд перед скиданням. Він увімкнений за замовчуванням і не може бути перевизначений розробниками.

Обов'язкове групування сповіщень означає, що система тепер автоматично групує сповіщення незалежно від того, чи використовує застосунок setGroup(). Застосунки, які покладалися на індивідуальну помітність сповіщень для залучення користувачів, можуть потребувати перегляду своєї стратегії сповіщень.

Для підготовки до співбесід ці зміни добре поєднуються з питаннями про корутини Kotlin та Flow, оскільки ефективне групування та обмеження сповіщень часто вимагає патернів debouncing на основі корутин.

Health Connect FHIR API та RangingManager

Android 16 розширює Health Connect підтримкою запису FHIR (Fast Healthcare Interoperability Resources), дозволяючи медичним застосункам створювати та зберігати структуровані медичні записи. API RangingManager уніфікує вимірювання відстані та кута через BLE channel sounding, BLE RSSI, Ultra-Wideband та Wi-Fi RTT — консолідуючи те, що раніше вимагало чотирьох окремих API-поверхонь.

Фотоселектор отримує глибші API кастомізації, що дозволяють розробникам контролювати зовнішній вигляд селектора, зберігаючи ту саму модель безпеки sandbox. Пошук хмарного медіа-провайдера було додано в Developer Preview 2.

Ці API рідше з'являються на загальних Android-співбесідах, але є критичними для спеціалізованих посад у сфері health tech, IoT або застосунків з інтенсивним використанням медіа.

Питання та відповіді для співбесід щодо Android 16

Нижче наведено питання, які найімовірніше з'являться на співбесідах для Android-розробників у 2026 році, засновані на змінах поведінки та API, розглянутих вище.

П: Які обов'язкові зміни поведінки при орієнтації на API 36? Три зміни є обов'язковими: рендеринг від краю до краю (без можливості відмови), ігнорування обмежень орієнтації/зміни розміру на екранах >= 600dp та предиктивна навігація назад, увімкнена на рівні системи. Застосунки повинні коректно обробляти WindowInsets, підтримувати адаптивні макети та мігрувати з onBackPressed() на OnBackInvokedCallback.

П: Як десктопний режим впливає на архітектуру застосунку? Десктопний режим створює незалежну сесію дисплея. Застосунки повинні уникати кешування об'єктів Display, підтримувати динамічні метрики вікна, обробляти введення з клавіатури та миші й враховувати сценарії з кількома екземплярами. API ActivityOptions.launchDisplayId дозволяє програмно орієнтуватися на конкретні дисплеї.

П: Коли ProgressStyle має замінити setProgress()? ProgressStyle призначений для багатоетапних процесів із чіткими віхами (поїздка, доставка, навігація). Стандартний setProgress() залишається відповідним для одноопераційного прогресу (завантаження файлу, вивантаження). ProgressStyle отримує підвищену видимість у панелі сповіщень.

П: Що таке модель випуску major/minor SDK в Android 16? Мажорний випуск (березень 2025) містить зміни поведінки та вимагає оновлення targetSdkVersion. Мінорний випуск (грудень 2025) додає нові API без змін поведінки — оновлення targetSdkVersion не потрібне. Ця модель розділяє стабільність та інновації.

П: Як працює предиктивне повернення з 3-кнопковою навігацією? На API 36+ довге натискання кнопки повернення в 3-кнопковій навігації запускає ту саму предиктивну анімацію, що й жестова навігація. Застосунки повинні зареєструвати OnBackInvokedCallback з відповідним пріоритетом. Пріоритет PRIORITY_SYSTEM_NAVIGATION_OBSERVER дозволяє спостерігати без перехоплення.

Висновок

• Режим від краю до краю більше не є опціональним в API 36. Необхідно провести аудит усіх екранів на предмет коректної обробки WindowInsets, особливо кастомних панелей інструментів та bottom sheet.
• Фіксовану орієнтацію в маніфесті слід замінити адаптивними макетами Jetpack Compose з використанням WindowSizeClass до того, як Android 17 видалить можливість opt-out.
• Десктопний режим готовий до продакшену на Pixel 8+ та флагманах Samsung. Застосунки слід тестувати із зовнішніми дисплеями, введенням з клавіатури та сценаріями з кількома екземплярами.
• Міграція з onBackPressed() на OnBackInvokedCallback є необхідною. Пріоритет PRIORITY_SYSTEM_NAVIGATION_OBSERVER слід використовувати для відстеження аналітики без блокування системних анімацій.
• Notification.ProgressStyle слід впроваджувати для будь-якого багатоетапного процесу. Охолодження сповіщень та обов'язкове групування впливають на всі застосунки незалежно від цільового SDK.
• Модель major/minor SDK означає, що зміни поведінки з'являються раз на рік. Мінорний SDK приносить нові API без ризику сумісності — їх можна впроваджувати вільно.