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

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ą.

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.

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 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.

// 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 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.

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, 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.

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 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ę.

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, 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 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.