# Android 16 w 2026 roku: Nowe API, tryb desktopowy i pytania rekrutacyjne

> Dogłębna analiza Android 16 (API 36) obejmująca tryb desktopowy, powiadomienia ProgressStyle, nawigację predykcyjną, wymuszone renderowanie od krawędzi do krawędzi oraz pytania zadawane na rozmowach kwalifikacyjnych.

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

---

Android 16 (poziom API 36, kryptonim „Baklava”) stanowi jedną z najbardziej przełomowych aktualizacji platformy od czasu wprowadzenia Material You w Android 12. Wydany jako wersja stabilna 10 czerwca 2025 roku, działa obecnie na ponad 21% aktywnych urządzeń (stan na marzec 2026), co czyni go najszerzej wdrożoną wersją Androida. Dla programistów Android przygotowujących się do rozmów kwalifikacyjnych w 2026 roku znajomość tych zmian w API jest absolutną koniecznością.

> **Kluczowa informacja na rozmowę kwalifikacyjną**
>
> Android 16 wymusza trzy przełomowe zmiany dla aplikacji celujących w API 36: renderowanie od krawędzi do krawędzi jest obowiązkowe, ograniczenia orientacji i zmiany rozmiaru są ignorowane na dużych ekranach (600dp+), a nawigacja predykcyjna wstecz musi być prawidłowo obsłużona. Każda rozmowa kwalifikacyjna na stanowisko programisty Android w 2026 roku dotknie przynajmniej jednego z tych tematów.

## Model wydawniczy SDK w Android 16 — strategia major/minor

Android 16 wprowadza dwuetapową strukturę wydań, która zmienia sposób planowania wdrażania funkcji. Główne SDK zostało wydane wraz z Beta 3 w marcu 2025, zamrażając zmiany zachowań i podstawowe API. Drugie, pomniejsze SDK pojawiło się 2 grudnia 2025, dodając nowe API bez modyfikacji zachowania platformy.

To rozdzielenie ma ogromne znaczenie na rozmowach kwalifikacyjnych: wydanie główne (major) to miejsce, w którym znajdują się zmiany łamiące kompatybilność (renderowanie od krawędzi do krawędzi, wymuszanie orientacji), podczas gdy wydanie pomniejsze (minor) dostarcza nowe możliwości (dodatkowe biblioteki Jetpack, API związane ze sztuczną inteligencją) bez jakiegokolwiek wpływu na istniejące zachowanie aplikacji. Google zaprojektował ten model, aby przyspieszyć dostarczanie API, jednocześnie zapewniając zespołom korporacyjnym stabilny, przewidywalny cel roczny do spełnienia wymagań zgodności.

Częste pytanie rekrutacyjne dotyczy różnicy między `targetSdkVersion` a `compileSdkVersion` w kontekście tego podwójnego modelu. Odpowiedź: ustawienie `targetSdkVersion = 36` aktywuje wszystkie zmiany zachowań z wydania głównego. Pomniejsze SDK jest wyłącznie addytywne — nie wymaga żadnego opt-in ani aktualizacji targetu.

## Wymuszony tryb od krawędzi do krawędzi w API 36

Aplikacje celujące w Android 16 nie mogą już zrezygnować z layoutów od krawędzi do krawędzi. System ignoruje wywołania `setDecorFitsSystemWindows(true)` oraz starsze flagi widoczności `SystemUI`. Każda aplikacja musi prawidłowo obsługiwać window insets, w przeciwnym razie elementy interfejsu mogą zostać zakryte przez pasek stanu i pasek nawigacji.

```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)
                )
            }
        }
    }
}
```

Komponent `Scaffold` w [Jetpack Compose](https://developer.android.com/develop/ui/compose) obsługuje insety automatycznie poprzez `innerPadding`. W przypadku aplikacji opartych na systemie View zalecanym podejściem pozostaje `ViewCompat.setOnApplyWindowInsetsListener`. Kluczowy szczegół: `WindowInsetsCompat.Type.systemBars()` musi zostać jawnie skonsumowany — w przeciwnym razie system zastosuje domyślny padding, który może nie pasować do projektu aplikacji.

Rekruterzy często pytają, co dzieje się z aplikacjami, które polegały na `android:fitsSystemWindows="true"` w layoutach XML. W API 36 ten atrybut nadal działa, ale jedynie stosuje padding dla pasków systemowych — nie zapobiega już renderowaniu aplikacji od krawędzi do krawędzi.

## Aplikacje adaptacyjne i zmiany orientacji na dużych ekranach

Android 16 ignoruje atrybuty `android:screenOrientation` oraz `android:resizeableActivity="false"` dla aplikacji niezwiązanych z grami na wyświetlaczach o `smallestWidth >= 600dp`. Dotyczy to tabletów, urządzeń składanych oraz zewnętrznych monitorów podłączonych w trybie desktopowym. Kończy to lata wyświetlania telefonicznych layoutów w trybie letterbox na dużych ekranach.

```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()
        }
    }
}
```

Biblioteka [Jetpack WindowManager](https://developer.android.com/jetpack/androidx/releases/window) dostarcza `WindowSizeClass` do tworzenia responsywnych interfejsów. Właściwość opt-out była dostępna dla aplikacji celujących konkretnie w API 36, ale Android 17 (oczekiwany w Q2 2026) usuwa tę możliwość całkowicie.

Rekruterzy często formułują to pytanie następująco: „Jak przeprowadzić migrację aplikacji zablokowanej w orientacji pionowej, aby obsługiwała duże ekrany?” Odpowiedź obejmuje zastąpienie stałej orientacji responsywnymi layoutami, testowanie zmian konfiguracji (zwłaszcza `onConfigurationChanged`) oraz weryfikację, że zapisany stan przetrwa zmiany rozmiaru ekranu.

## Tryb desktopowy i podłączone wyświetlacze

Tryb desktopowy został udostępniony jako funkcja ogólnodostępna w Android 16 QPR3 (marcowa aktualizacja Pixel Drop 2026), obsługując urządzenia Pixel 8+ oraz Samsung Galaxy S26/Fold7/Flip7. Podłączenie telefonu do zewnętrznego monitora przez USB-C uruchamia niezależną sesję desktopową z paskiem zadań, skalowalnymi oknami, wieloma wirtualnymi pulpitami oraz pełną obsługą klawiatury i myszy.

```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()
        )
    }
}
```

Telefon i zewnętrzny wyświetlacz działają niezależnie — aplikacje są przypisane do wyświetlacza, na którym zostały uruchomione. Google i Samsung [wspólnie opracowali doświadczenie okienkowe trybu desktopowego](https://android-developers.googleblog.com/2026/03/android-devices-extend-seamlessly-to.html), aby ograniczyć fragmentację w całym ekosystemie. Samsung DeX integruje te same platformowe API, tworząc jednolity cel deweloperski.

Kluczowe kwestie deweloperskie dotyczące trybu desktopowego:

- **Metryki okna zmieniają się dynamicznie.** Nigdy nie należy cache'ować obiektów `Display`. Przy każdej zmianie konfiguracji należy odpytywać `WindowMetricsCalculator` lub `LocalConfiguration` w Compose.
- **Obsługa klawiatury i myszy.** Zewnętrzne peryferia są normą w sesjach desktopowych. Konieczna jest obsługa dispatchingu `KeyEvent` oraz stanów hover wskaźnika.
- **Wsparcie dla wielu instancji.** Użytkownicy trybu desktopowego oczekują wielu okien tej samej aplikacji. Należy zadeklarować `android:documentLaunchMode="intoExisting"` lub odpowiednio obsłużyć `FLAG_ACTIVITY_NEW_DOCUMENT`.

## Powiadomienia ProgressStyle i aktualizacje na żywo

Android 16 wprowadza `Notification.ProgressStyle` — nowy szablon powiadomień dla procesów skoncentrowanych na postępie, takich jak śledzenie przejazdu, dostawy czy nawigacja. Zastępuje on doraźne niestandardowe layouty powiadomień standaryzowanym formatem promowanym przez system.

```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` obsługuje segmenty (kolorowe sekcje paska postępu), punkty (oznaczone kamienie milowe) oraz ikonę śledzenia, która przesuwa się wzdłuż paska. Ustawienie `setStyledByProgress(true)` pozwala systemowi kolorować segmenty na podstawie stopnia ukończenia. W kontekście [przygotowania do rozmów kwalifikacyjnych z zakresu powiadomień Android](/technologies/android/interview-questions/android-background-work) kluczowe jest zrozumienie, kiedy używać `ProgressStyle` zamiast standardowego `setProgress()`: `ProgressStyle` przeznaczony jest dla wieloetapowych procesów z wyraźnymi kamieniami milowymi, podczas gdy `setProgress()` pozostaje właściwy dla operacji jednoetapowych, takich jak pobieranie plików.

## Nawigacja predykcyjna wstecz z OnBackInvokedCallback

Android 16 kończy wieloletni proces migracji z `onBackPressed()` na API `OnBackInvokedCallback`. System wyświetla teraz animację „podglądu” ekranu docelowego podczas gestu cofania, pozwalając użytkownikom zatwierdzić lub anulować akcję. Aplikacje, które nadal nadpisują `onBackPressed()` bez rejestracji callbacka, łamią tę animację.

```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"
                )
            }
        }
    }
}
```

Nowy priorytet `PRIORITY_SYSTEM_NAVIGATION_OBSERVER` pozwala aplikacjom obserwować zdarzenia cofania bez blokowania animacji systemowej. Android 16 dodaje również `finishAndRemoveTaskCallback` oraz `moveTaskToBackCallback` dla niestandardowych zachowań stosu wstecz, które nadal integrują się z animacją predykcyjną.

Nawigacja predykcyjna działa również na nawigacji 3-przyciskowej w Android 16: długie naciśnięcie przycisku wstecz inicjuje animację podglądu. Jest to częsty temat na rozmowach kwalifikacyjnych — kandydaci, którzy wspominają tylko o nawigacji gestami, pomijają połowę zagadnienia.

## Wyciszanie powiadomień i obowiązkowe grupowanie

Dwie dodatkowe zmiany w powiadomieniach dotyczą każdej aplikacji Android. Mechanizm wyciszania powiadomień (notification cooldown) zmniejsza głośność alertów przy szybko następujących po sobie powiadomieniach z tej samej aplikacji, stopniowo obniżając poziom dźwięku przez około 60 sekund przed resetem. Jest domyślnie włączony i nie może być nadpisany przez programistów.

Obowiązkowe grupowanie powiadomień oznacza, że system automatycznie grupuje powiadomienia niezależnie od tego, czy aplikacja używa `setGroup()`. Aplikacje polegające na indywidualnej prominencji powiadomień do angażowania użytkowników mogą potrzebować przemyślenia strategii powiadomień.

Do przygotowań rekrutacyjnych te zmiany dobrze łączą się z pytaniami o [korutyny Kotlina i Flow](/technologies/android/interview-questions/android-kotlin-coroutines-flow), ponieważ efektywne grupowanie i throttling powiadomień często wymaga wzorców debouncing opartych na korutynach.

## Health Connect FHIR APIs i RangingManager

Android 16 rozszerza Health Connect o obsługę zapisu FHIR (Fast Healthcare Interoperability Resources), umożliwiając aplikacjom zdrowotnym tworzenie i przechowywanie ustrukturyzowanych rekordów medycznych. API `RangingManager` ujednolica pomiary odległości i kąta w technologiach BLE channel sounding, BLE RSSI, Ultra-Wideband i Wi-Fi RTT — konsolidując to, co wcześniej wymagało czterech oddzielnych powierzchni API.

Selektor zdjęć zyskuje głębsze API personalizacji, pozwalające programistom kontrolować wygląd selektora przy zachowaniu tego samego modelu bezpieczeństwa sandboxowego. Wyszukiwanie w dostawcy mediów chmurowych zostało dodane w Developer Preview 2.

Te API rzadziej pojawiają się na ogólnych rozmowach kwalifikacyjnych z Androida, ale są krytyczne dla stanowisk specjalistycznych w branży health tech, IoT czy aplikacjach intensywnie korzystających z mediów.

## Pytania i odpowiedzi rekrutacyjne dotyczące Android 16

Poniżej znajdują się pytania najczęściej pojawiające się na rozmowach kwalifikacyjnych dla programistów Android w 2026 roku, oparte na zmianach zachowań i API omówionych powyżej.

**P: Jakie są obowiązkowe zmiany zachowania przy celowaniu w API 36?**
Wymuszane są trzy zmiany: renderowanie od krawędzi do krawędzi (bez możliwości rezygnacji), ignorowanie ograniczeń orientacji/zmiany rozmiaru na ekranach >= 600dp oraz predykcyjna nawigacja wstecz włączona systemowo. Aplikacje muszą prawidłowo obsługiwać `WindowInsets`, wspierać responsywne layouty i przeprowadzić migrację z `onBackPressed()` na `OnBackInvokedCallback`.

**P: Jak tryb desktopowy wpływa na architekturę aplikacji?**
Tryb desktopowy tworzy niezależną sesję wyświetlacza. Aplikacje muszą unikać cache'owania obiektów `Display`, wspierać dynamiczne metryki okna, obsługiwać wejście z klawiatury i myszy oraz uwzględniać scenariusze wieloinstancyjne. API `ActivityOptions.launchDisplayId` pozwala programowo celować w konkretne wyświetlacze.

**P: Kiedy ProgressStyle powinien zastąpić setProgress()?**
`ProgressStyle` przeznaczony jest dla wieloetapowych procesów użytkownika z wyraźnymi kamieniami milowymi (przejazd, dostawa, nawigacja). Standardowy `setProgress()` pozostaje odpowiedni dla jednooperacyjnego postępu (pobieranie pliku, upload). `ProgressStyle` zyskuje promowaną widoczność w panelu powiadomień.

**P: Czym jest model wydawniczy major/minor SDK w Android 16?**
Wydanie główne (marzec 2025) zawiera zmiany zachowań i wymaga aktualizacji `targetSdkVersion`. Wydanie pomniejsze (grudzień 2025) dodaje nowe API bez zmian zachowań — aktualizacja `targetSdkVersion` nie jest potrzebna. Model ten oddziela stabilność od innowacji.

**P: Jak działa nawigacja predykcyjna z nawigacją 3-przyciskową?**
Na API 36+ długie naciśnięcie przycisku wstecz w nawigacji 3-przyciskowej uruchamia tę samą animację predykcyjną co nawigacja gestami. Aplikacje muszą zarejestrować `OnBackInvokedCallback` z odpowiednim priorytetem. Priorytet `PRIORITY_SYSTEM_NAVIGATION_OBSERVER` pozwala obserwować bez przechwytywania.

## Podsumowanie

- Tryb od krawędzi do krawędzi nie jest już opcjonalny w API 36. Należy przeprowadzić audyt wszystkich ekranów pod kątem prawidłowej obsługi `WindowInsets`, szczególnie niestandardowych pasków narzędzi i bottom sheetów.
- Stałą orientację w manifeście należy zastąpić responsywnymi layoutami [Jetpack Compose](/technologies/android/interview-questions/android-compose) wykorzystującymi `WindowSizeClass`, zanim Android 17 usunie możliwość opt-out.
- Tryb desktopowy jest gotowy do produkcji na Pixel 8+ i flagowcach Samsunga. Aplikacje powinny być testowane z zewnętrznymi wyświetlaczami, wejściem z klawiatury i scenariuszami wieloinstancyjnymi.
- Migracja z `onBackPressed()` na `OnBackInvokedCallback` jest konieczna. Priorytet `PRIORITY_SYSTEM_NAVIGATION_OBSERVER` służy do śledzenia analityki bez blokowania animacji systemowych.
- `Notification.ProgressStyle` powinien być adoptowany dla każdego wieloetapowego procesu użytkownika. Wyciszanie powiadomień i obowiązkowe grupowanie dotyczą wszystkich aplikacji niezależnie od docelowego SDK.
- Model major/minor SDK oznacza, że zmiany zachowań pojawiają się raz do roku. Pomniejsze SDK przynosi nowe API bez ryzyka kompatybilności — można je adoptować swobodnie.

---

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