Google I/O 2026 lands in eight days, on May 19. The keynote will spend a chunk of its runtime on what Google has been calling "Adaptive Everywhere" — Android 17's redesign of the form factor story, where phones, foldables, tablets, Chromebooks, car displays, and XR headsets are no longer separate targets with separate quality bars. They're one target. The same APK has to run beautifully on a 4-inch phone screen and a 27-inch Chromebook desktop, and Google Play will enforce that with API 37 starting in August 2027.

If you're an indie dev who's been treating the tablet experience of your app as a "we'll fix that someday" item, that someday is now on a clock. This guide walks through what Adaptive Everywhere actually changes, what's enforceable, what's voluntary, and the practical migration plan you can execute in the next four to six weeks before the I/O keynote noise — and the stable Android 17 cut in June — eats your calendar.

What Adaptive Everywhere actually is#

The Android 17 message is a unification message. For the last decade Android tablet apps have been a depressing story: 90% of apps in the Play Store are locked to portrait, scale poorly on tablet hardware, and ship with a developer opt-out that says "please don't resize me." Google has been trying to fix this for five years. Adaptive Everywhere is the version where the fix becomes mandatory.

Three things change in Android 17 specifically:

Restrictions on orientation and resizability are ignored on large screens. This is the single biggest behavioral change. If your app targets API 37 and is running on a device where sw > 600 dp, the system will override your manifest's android:screenOrientation and android:resizableActivity tags. Your app gets the full available window whether it asked for it or not. The opt-out that has carried indie apps for a decade is gone.

A unified layout system across phone, tablet, ChromeOS, and XR. Android 17 redesigns the responsive layout primitives in Jetpack Compose to handle the full form-factor spectrum. The window-size-class API gets expanded, the foldable posture API moves from experimental to stable, and a new XR layout class lets your app render into a 3D-anchored window without rewriting your UI tree.

Google Play enforcement on API 37. New apps and updates targeting API 37 will be required to pass the adaptive quality bar starting in August 2027. The Play Console quality report already shows you whether your app currently passes — most indie apps don't.

The cumulative effect is that the cheapest path to compliance is no longer "lock to portrait and pretend tablets don't exist." It's actually building the adaptive layout, because the system will run your app full-window on a tablet regardless of what your manifest says, and if it looks broken, that's a one-star review surface and a Play quality penalty.

What's enforceable vs voluntary#

The split between mandatory and recommended matters because indie dev time is finite.

Mandatory for API 37 targeting:

Removing or ignoring screenOrientation and resizableActivity restrictions on large screens
Passing the adaptive quality bar for Google Play distribution (August 2027 deadline for new apps and updates)
Supporting the full window size on sw > 600 dp devices

Recommended but not enforced:

Migrating from View-based layouts to Jetpack Compose for new adaptive UI work
Adopting the new XR layout class
Building per-form-factor navigation patterns (NavigationRail on tablet, NavigationBar on phone)
Using WindowSizeClass instead of hard-coded screen-width checks

The pragmatic path for an indie team is to focus the next six weeks on the mandatory list and treat the recommended list as a slower migration that follows the stable release.

The six-week migration plan#

This assumes you have an existing Android app that currently targets API 35 or 36, locks portrait orientation, and has never been seriously tested on a tablet. The goal is to be API 37–ready before stable Android 17 ships in June.

Week 1: audit#

Open your AndroidManifest.xml and find every android:screenOrientation declaration and every android:resizableActivity="false". List them. These are the things that are about to stop working as you expect them to.

Install your app on a tablet emulator running Android 17 Beta 4. Run through your three most-used user flows. Note what breaks: text that overflows, dialogs that get cut off, UI that's pinned to one side of a wide screen.

Pull your Play Console adaptive quality report. It'll tell you exactly which screens fail the quality bar today.

The first real change is your root layout. If you're using a single Scaffold with a bottom NavigationBar, a tablet user sees that bar pinned to the bottom of a 1200-pixel-wide screen, which is wrong. The fix is to switch to NavigationSuiteScaffold, which Google added in Material 3 specifically for this — it renders as a bottom bar on phone, a navigation rail on small tablet, and a permanent navigation drawer on large tablet, all without you writing the breakpoint logic.

kotlin

NavigationSuiteScaffold(
    navigationSuiteItems = {
        item(
            selected = selected == Route.Home,
            onClick = { navigate(Route.Home) },
            icon = { Icon(Icons.Default.Home, contentDescription = null) },
            label = { Text("Home") }
        )
        // ... other items
    }
) {
    HomeScreen()
}

That's an afternoon's work and it fixes the most visually broken thing in 80% of indie tablet experiences.

Week 3: list-detail pattern#

The second biggest visual gap on tablet is the list-detail pattern. On phone you push from a list to a detail screen. On tablet you should show both side by side. Jetpack Compose has ListDetailPaneScaffold which handles this:

kotlin

val navigator = rememberListDetailPaneScaffoldNavigator<Item>()

ListDetailPaneScaffold(
    directive = navigator.scaffoldDirective,
    value = navigator.scaffoldValue,
    listPane = {
        AnimatedPane {
            ItemList(onItemClick = { navigator.navigateTo(ListDetailPaneScaffoldRole.Detail, it) })
        }
    },
    detailPane = {
        AnimatedPane {
            navigator.currentDestination?.content?.let { ItemDetail(it) }
        }
    }
)

This handles the breakpoint between "show one pane at a time" and "show both" without you wiring it. Apply it anywhere your app has a master/detail flow: inbox → message, library → book, conversations → thread.

Week 4: text and image scaling#

The third tier of issues is text and image scaling. On phone you can get away with hard-coded sp values. On tablet — and especially on Chromebook — the same text on a 27-inch screen at the same sp is comically small.

Two patterns help. For text, switch to the Material 3 type scale (MaterialTheme.typography.headlineLarge, etc.) and let the system pick the right size class. For images, swap fixed dimensions for WindowSizeClass-aware values, or use Modifier.aspectRatio() and let the surrounding layout drive the actual pixel size.

Week 5: orientation pass#

This is the brittle part. Remove android:screenOrientation from every activity that doesn't have a hard requirement to be locked (a camera viewfinder is one of the few legitimate ones). Test in landscape. The cases that break are usually:

Hardcoded layout constants from when you knew the screen was 360 dp wide
Animations that assume a portrait coordinate system
Modal sheets that don't account for the available height

Fix each. The cleanest fix for most cases is to switch the offending layout to a BoxWithConstraints and recompute against the actual available space.

Week 6: Play Console quality bar#

Final week: re-run the Play Console adaptive quality report. The categories you want all-green are: large screen layouts, foldable, multi-window, keyboard/mouse, and ChromeOS. The two that tend to fail last are keyboard/mouse (your app doesn't handle a focus ring properly when there's no touch) and ChromeOS (your app crashes when resized aggressively).

The keyboard/mouse fix is mostly setting Modifier.focusable() on interactive elements and testing tab navigation. The ChromeOS fix is making sure your saved-state survives configuration changes — rememberSaveable instead of remember for anything that matters.

What I/O will probably ship on top#

Eight days out, the rumor mill has Google teasing two specific Adaptive Everywhere announcements at the keynote. The first is a new XR layout primitive that lets you anchor a Compose window in 3D space without writing OpenXR code. The second is an updated WindowSizeClass API with an extra-large tier specifically for Chromebooks and desktop displays.

Neither of those changes the six-week plan above. They're additive — features you'll adopt after the foundation work is done. The mistake to avoid is waiting for the I/O announcements before starting the foundation work. By the time the keynote ends on May 19, you'll have lost a week of runway and gained no new information that changes what's mandatory.

The submission angle#

Adaptive Everywhere isn't only a code migration. The Google Play listing itself has to change. Tablet and Chromebook screenshots are now required surfaces, not optional add-ons — you'll need at minimum a 7-inch tablet, 10-inch tablet, and Chromebook screenshot per language. The Play Console flags incomplete listings, and apps without large-screen screenshots get downranked in the tablet and Chromebook search results.

This is where the time math gets painful. A typical indie app shipping in 8 languages and now adding 3 large-screen surfaces is going from a 16-screenshot package to a 40-screenshot package. Manually that's a week of Figma work. The cheaper play is to drive the screenshot pipeline off your existing source designs and let a tool fan them out across the new device matrix.

Stora does exactly this — point it at your source screens, declare your device matrix and locales, and it generates the full set with the right safe areas, status bars, and locale-aware caption layout. The Android 17 adaptive submission becomes a 90-minute task instead of a week.

What to take away#

Adaptive Everywhere is the biggest behavioral change to Android distribution since runtime permissions in Android 6. The enforcement starts gradual, but the engineering work to comply isn't optional for anyone who wants to keep shipping to tablets and Chromebooks — which is half of the Play Store's growth surface in 2026.

The six-week plan above is the rough shape of the work. Start it before I/O, not after. The indies who finish the migration before stable Android 17 lands in June ship into a much friendlier review queue than the ones who try to cram it in alongside iOS 27 in October.

Boring infrastructure work that pays for the next two years. Worth the six weeks.

Android 17 'Adaptive Everywhere': The Indie Developer's Prep Guide Before Google I/O 2026