Galaxy Unpacked 2026: What the New Foldable and Wearable Lineup Means for Android Developers

On July 22, Samsung held Galaxy Unpacked in London and unveiled a new lineup of foldable and wearable devices. The following day, the Android developer relations team published a direct response on developer.android.com: "the variety of form factors, screen sizes, and device postures your app needs to support is expanding once again." That's a polite way of saying the adaptive layout debt you've been deferring just got a new collection notice.

I've been thinking about this across my own apps since the Unpacked announcement. Nodat, Musist, Samachar — none of them have adaptive layouts that would survive gracefully on an inner display unfolding mid-session, or on a wearable companion where a feature card suddenly needs to collapse to a watchface-sized tile. That's not unique to me. Most Android teams are in the same spot: one-form-factor apps that technically run on foldables, but don't take advantage of them, and can look broken on them.

Here's the developer-facing picture from what was announced and what the Jetpack tooling currently offers.

What Samsung Announced and Why Developers Should Care

Galaxy Unpacked 2026 landed a new generation of foldable devices alongside a refreshed wearables lineup. The specific implication for Android developers, as the Android team called out directly, is that the matrix of form factors, screen sizes, and device postures is wider than it's ever been. A single user may own a Galaxy foldable, a Galaxy Watch, and Galaxy Glasses — all of them potentially running your app or a companion surface of it, in different postures, at different times.

The foldable side is the most immediately actionable. Foldables have been around since the Galaxy Fold in 2019, but the developer story for supporting them well has historically been messy — window size class detection was inconsistent, posture APIs were spread across different library versions, and the Compose adaptive scaffolds that make multi-pane layouts tractable were either experimental or not yet stable. That situation has changed. The tooling is ready; the question is whether your codebase has caught up.

Jetpack Window 1.6.0: The Engagement Mode APIs

The Jetpack Window library has been evolving steadily through a series of alphas in 2026. The most developer-relevant changes are in the engagement mode APIs — a mechanism for understanding how a user is actively engaging with the device, which matters particularly for foldables in different posture states.

What changed in alpha05 (June 17, 2026)

Window 1.6.0-alpha05 introduced EngagementMode.PRECISE_POINTER inside WindowEngagementInfo, and simultaneously deprecated WindowLayoutInfo.engagementModes. The migration path is to call WindowInfoTracker.windowEngagementInfo() instead, which returns an observable flow of engagement state rather than the static snapshot the old property offered.

// Deprecated pattern (pre-alpha05)
val engagementModes = windowLayoutInfo.engagementModes

// New pattern
lifecycleScope.launch {
    WindowInfoTracker
        .getOrCreate(this@MainActivity)
        .windowEngagementInfo(this@MainActivity)
        .collect { engagementInfo ->
            val mode = engagementInfo.engagementMode
            if (mode == EngagementMode.PRECISE_POINTER) {
                // User has a stylus or precise input device attached
                // Consider enabling richer interaction affordances
                enablePreciseInputMode()
            }
        }
}

PRECISE_POINTER tells you that the user has a high-precision input device available — a stylus or a trackpad, typically — rather than just touch. On foldables in tabletop or laptop posture, this is common. If your app has any text editing, drawing, or fine-grained selection, this is the signal you want to key off to offer better affordances, not just a crude orientation check.

WindowSizeClass and the grid helpers

Window 1.6.0-alpha03 (April 2026) added WindowSizeClassSets grid helpers that make it easier to construct size class sets in a grid form — useful when you want to define breakpoints in a tabular way rather than as a flat list. The practical benefit is cleaner adaptive layout code when you're branching on multiple axes simultaneously (width class AND height class, for example).

// alpha03+ API: grid-form WindowSizeClassSets construction
val sizeClassSets = WindowSizeClassSets.entries
    .inGrid(columns = WindowWidthSizeClass.entries)

// Use in your adaptive layout decision:
val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
when (windowSizeClass.windowWidthSizeClass) {
    WindowWidthSizeClass.COMPACT -> showSinglePane()
    WindowWidthSizeClass.MEDIUM  -> showListWithCollapsedDetail()
    WindowWidthSizeClass.EXPANDED -> showFullListDetail()
}

This isn't glamorous. But it's the kind of API improvement that eliminates the boilerplate in real adaptive layout code, and it pairs cleanly with the scaffold APIs below.

Compose Adaptive: NavigableListDetailPaneScaffold

If you're building a new screen that needs to work on both phones and foldables — or you're retrofitting an existing one — NavigableListDetailPaneScaffold from the Material3 adaptive library is now the right primitive to reach for. It handles the dual-pane case on expanded screens and collapses to single-pane navigation on compact ones automatically, and it integrates with predictive back out of the box.

Setup

// build.gradle.kts
dependencies {
    implementation("androidx.compose.material3.adaptive:adaptive:1.1.0-beta01")
    implementation("androidx.compose.material3.adaptive:adaptive-layout:1.1.0-beta01")
    implementation("androidx.compose.material3.adaptive:adaptive-navigation:1.1.0-beta01")
}

Implementation

@Parcelize
data class NewsItem(val id: String, val title: String) : Parcelable

@Composable
fun AdaptiveNewsScreen(items: List<NewsItem>) {
    val navigator = rememberListDetailPaneScaffoldNavigator<NewsItem>()

    BackHandler(navigator.canNavigateBack()) {
        navigator.navigateBack()
    }

    NavigableListDetailPaneScaffold(
        navigator = navigator,
        listPane = {
            AnimatedPane {
                NewsListContent(
                    items = items,
                    onItemClick = { item ->
                        navigator.navigateTo(
                            pane = ListDetailPaneScaffoldRole.Detail,
                            content = item
                        )
                    }
                )
            }
        },
        detailPane = {
            AnimatedPane {
                val item = navigator.currentDestination?.contentKey
                if (item != null) {
                    NewsDetailContent(item = item)
                } else {
                    EmptyDetailPlaceholder()
                }
            }
        }
    )
}

The key thing here is the back navigation behavior. By default, NavigableListDetailPaneScaffold uses PopUntilScaffoldValueChange — which means back navigation skips intermediate content changes in multi-pane mode and jumps directly to a layout change. That's the right behavior for most apps: on a foldable with both panes visible, the user pressing back should change the layout state, not quietly swap the detail pane content. But if your app's mental model is more content-centric — a browser-style history — you can switch to BackNavigationBehavior.PopUntilContentChange instead.

Handling foldable posture changes

One thing the scaffold gives you for free: it responds to the device's window size class changes, which includes unfolding mid-session. When a user opens the fold, the scaffold transitions from single-pane to dual-pane automatically, preserving the current navigation state. You don't need to manually listen for fold events and rebuild your composition. The caveat is that you need to implement Parcelable on your content key type — which the @Parcelize annotation handles — so the scaffold can save and restore state across those transitions.

Supporting Pane Pattern for Contextual Extras

Not every screen is a list-detail. For screens where the "extra" pane is supplemental context rather than a detail view — a map alongside a location list, a timeline alongside a project view — the library also provides SupportingPaneScaffold. The API is similar: a main pane and a supporting pane that's shown alongside on expanded screens and hidden on compact ones, toggled by user action.

@Composable
fun ProjectScreen() {
    val scaffoldNavigator = rememberSupportingPaneScaffoldNavigator()

    SupportingPaneScaffold(
        directive = scaffoldNavigator.scaffoldDirective,
        value = scaffoldNavigator.scaffoldValue,
        mainPane = { AnimatedPane { MainProjectView() } },
        supportingPane = { AnimatedPane { TimelineView() } }
    )
}

The choice between the two scaffolds: use NavigableListDetailPaneScaffold when pane B is a drilldown of pane A's selection. Use SupportingPaneScaffold when both panes are peers showing different views of the same context.

What to Actually Do This Week

Given where the tooling sits and what Galaxy Unpacked just added to the target device landscape, here's how I'm prioritizing this in my own apps:

• Audit your current window size class handling. Run your app on an emulator in foldable configuration. If it looks identical in compact and expanded modes, you haven't started. That's the baseline you're fixing.
• Migrate off WindowLayoutInfo.engagementModes. If you're using the old API, alpha05 deprecated it. The new windowEngagementInfo() flow is a straightforward swap and gives you better data (reactive, not static).
• Pick one screen to migrate to NavigableListDetailPaneScaffold. Don't try to adaptive-ify your whole app at once. Pick the highest-value screen — usually a list-detail pattern — and migrate it first. Ship it, measure it, then move on.
• Add @Parcelize to your navigation content types. If you're using the adaptive scaffold, all your content key data classes need to be Parcelable. Getting this right early prevents pain when posture changes happen mid-session.
• Test on a foldable emulator, not just resizable windows. The foldable emulator accurately simulates posture changes (table-top, book, unfolded) that a generic resizable window doesn't. Android Studio ships it; use it.

The Bigger Picture

Every Galaxy Unpacked is a forcing function for Android developers. New hardware reveals which apps handle it gracefully and which ones just... work on the big screen, kind of. The apps that consistently look good across form factors aren't necessarily the ones with the biggest teams — they're the ones that took adaptive layout seriously before the new hardware landed, not after.

The tooling is genuinely good now. NavigableListDetailPaneScaffold is not an experimental API with three caveats — it's production-ready in beta01+. The Window engagement APIs are in active development but have been stable enough to build on for months. Android 17's mandatory adaptivity requirement provides the deadline.

The adaptive layout debt most Android apps are carrying is real, but it's not a rewrite — it's a retrofit. One screen at a time, starting with the one your users spend the most time in, is how you close it without stopping everything else. That's where I'm starting with Nodat this week.