Jetpack’s Biggest Update Wave of 2026: Compose 1.11, Room 3.0 Alpha, Paging KMP and What It All Signals
Four major Jetpack library updates landed in close succession across March and April 2026, and the timing is not coincidental. Room 3.0 is a major breaking version of the library that focuses on Kotlin Multiplatform and adds support for JavaScript and WebAssembly on top of the existing Android, iOS and JVM desktop support. The Jetpack Compose April ’26 release is stable, containing version 1.11 of core Compose modules. Paging shipped expanded KMP target support. Media3 1.10 added Material 3 playback widgets and VVC codec support.
Read individually, each of these is a significant library release. Read together, they describe a platform strategy: Google is systematically rebuilding Jetpack’s most important libraries from the ground up as Kotlin Multiplatform-first infrastructure. The implication for Android developers is immediate — but the implication for the broader Kotlin ecosystem is larger and longer-term. Jetpack is becoming the persistence, UI, and media layer not just of Android apps but of Kotlin applications wherever they run.
Compose 1.11 Stable — Testing Overhaul, KMP Runtime, New Layouts, Trackpad Support
The April 2026 Compose BOM (2026.04.01) brings Compose 1.11 to stable, and this release touches more surface area than most Compose stable drops.
The testing API migration you can no longer defer. We’re introducing a major update to how Compose handles test timing. Following the opt-in period announced in Compose 1.10, the v2 testing APIs are now the default, and the v1 APIs have been deprecated. The key change is a shift in the default test dispatcher. While the v1 APIs relied on UnconfinedTestDispatcher, which executed coroutines immediately, the v2 APIs use the StandardTestDispatcher. This means that when a coroutine is launched in your tests, it is now queued and does not execute until the virtual clock is advanced.
This is the most immediately breaking change in the release. Any Compose test suite that relied on UnconfinedTestDispatcher‘s eager coroutine execution will now fail if tests were written with timing assumptions that only held under immediate dispatch. This better mimics production conditions, effectively flushing out race conditions and making your test suite significantly more robust and less flaky. To ensure your tests align with standard coroutine behavior and to avoid future compatibility issues, we strongly recommend migrating your test suite.
Migrating is straightforward: replace UnconfinedTestDispatcher with StandardTestDispatcher in your test coroutine setup, and wrap any code that needs coroutines to execute before assertions with advanceUntilIdle() or runCurrent(). Tests that pass before migration and fail after typically reveal actual race conditions in production code — which is precisely the point.
HostDefaultProvider — Compose runtime decouples from UI for KMP. We introduced HostDefaultProvider, LocalHostDefaultProvider, HostDefaultKey, and ViewTreeHostDefaultKey to supply host-level services directly through compose-runtime. This removes the need for libraries to depend on compose-ui for lookups, better supporting Kotlin Multiplatform.
This is a library author API, but its significance extends beyond library authors. The removal of the compose-ui dependency from compose-runtime is a foundational step toward running Compose in environments where a UI rendering surface is not available — headless testing environments, server-side rendering contexts, and non-Android KMP targets that want to use Compose as a logic layer without the full UI stack. If you maintain any libraries built on Compose, review your dependencies for the new compositionLocalWithHostDefaultOf API, which creates CompositionLocal instances that resolve defaults from the host through this new system.
Custom preview wrappers with @PreviewWrapper. Android Studio custom previews is a new feature that allows you to define exactly how the contents of a Compose preview are displayed. By implementing the PreviewWrapperProvider interface and applying the new @PreviewWrapper annotation, you can easily inject custom logic, such as applying a specific Theme.
For teams where Compose previews have been unreliable because every component needed to be wrapped in a specific theme or provider setup, @PreviewWrapper finally solves this at the annotation level. Define a wrapper once, apply it as an annotation, and every preview that uses it automatically receives the correct context without boilerplate wrapper composables duplicated across the codebase.
Grid and FlexBox — two new adaptive layout primitives. Compose 1.11 introduces two experimental layout APIs that directly address the mandatory adaptive compliance requirements arriving in Android 17.
The Grid layout is a CSS Grid-equivalent for Compose — explicitly defined column and row tracks, spanning across cells with gridItem(rowSpan = 2) or gridItem(columnSpan = 3), and dynamic reconfiguration of grid tracks in response to window size changes. It’s highly adaptive — you can dynamically reconfigure your grid tracks and spans to respond to device states like tabletop mode or orientation changes, ensuring your UI looks great across form factors.
Fle :antCitation[]{citations=”6f46dcae-565a-45be-bf4e-00cf0a95a43e” injected=”space”}xBox is the flexbox container equivalent — managing item sizing and space distribution based on available container dimensions, handling wrapping and multi-axis alignment. These two primitives together give Compose developers the same layout vocabulary that web developers have used for responsive design for years, now applied natively to the Compose adaptive UI model that Android 17 makes mandatory for large-screen devices.
Trackpad events reclassified as mouse input. We’ve revamped Compose support for trackpads. Basic trackpad events will now generally be considered PointerType.Mouse events, aligning mouse and trackpad behavior to better match user expectations. Previously, these trackpad events were interpreted as fake touchscreen fingers of PointerType.Touch, which led to confusing user experiences. For example, clicking and dragging with a trackpad would scroll instead of selecting.
For Android apps running on Pixel Tablet with an external trackpad, on Chromebooks, and in the Android 17 Desktop Mode environment, this reclassification fixes a deeply frustrating class of interaction bugs. Apps that relied on PointerType.Touch to detect all direct input — implementing scrolling, selection, or custom gesture handling — may need to review their pointer event handling to correctly distinguish trackpad-as-mouse from touchscreen-as-touch.
Upcoming: compileSdk 37 requirement in 1.12. In the upcoming Compose 1.12.0 release, the compileSdk will be upgraded to compileSdk 37, with AGP 9, and all apps and libraries that depend on Compose inheriting this requirement. Plan for this now — if your project is currently on a lower compileSdk, update your build toolchain before 1.12 lands.
Room 3.0 Alpha — The Most Consequential Jetpack Release in Years
Room 3.0’s first alpha is not an incremental update. It is a full architectural rewrite, and it arrives with a new Maven group, a new package name, and a list of breaking changes substantial enough that Google is maintaining Room 2.x in parallel as a maintenance branch to give teams time to migrate.
Room 3.0 is a major breaking version of the library that focuses on Kotlin Multiplatform and adds support for JavaScript and WebAssembly on top of the existing Android, iOS and JVM desktop support.
New package and artifact identifiers — you cannot miss this one. To prevent compatibility issues with existing Room 2.x implementations and for libraries with transitive dependencies to Room, Room 3.0 resides in a new package which means it also has a new Maven group and artifact IDs. For example, androidx.room:room-runtime has become androidx.room3:room3-runtime and classes such as androidx.room.RoomDatabase will now be located at androidx.room3.RoomDatabase.
This is not a namespace collision you can import-alias your way around. It is a complete package move that requires updating every Room import across your codebase. The room3- prefix consistently replaces room- across all artifact names — room3-compiler, room3-ktx, room3-paging, room3-livedata, room3-testing.
SupportSQLite APIs are gone. Room 3.0 is fully backed by the androidx.sqlite driver APIs. The SQLiteDriver APIs are KMP-compatible and removing Room’s dependency on Android’s API simplifies the API surface for Android since it avoids having two possible backends.
For the vast majority of Room users who access the database exclusively through @Dao interfaces and RoomDatabase subclasses, this change is invisible — your DAOs, entities, and migrations continue to work the same way. You are affected if your code directly accesses SupportSQLiteDatabase, SupportSQLiteStatement, or openHelper.writableDatabase. For those cases, a compatibility layer remains available through androidx.room3:room3-sqlite-wrapper. This temporary bridge allows developers to convert a RoomDatabase instance into a SupportSQLiteDatabase, even if the SupportSQLite APIs in the database have been disabled due to a SQLiteDriver being installed.
No more Java code generation — KSP is now required. Room 3.0 exclusively generates Kotlin code. This aligns with the evolving Kotlin-first paradigm but also simplifies the codebase and development process, enabling faster iterations. KAPT is no longer supported in Room 3.0. If your project uses KAPT for Room annotation processing, migrating to KSP is a prerequisite for the Room 3.0 upgrade — and given that AGP 9’s built-in Kotlin support makes KAPT redundant, this migration is one you will need to do regardless.
Coroutines-first throughout — all DAO operations are now suspend functions. Coroutines are now a core requirement of the library. Database access objects must use suspending functions unless they return reactive types like Flow, effectively removing support for blocking database operations.
For apps already using Room with coroutines — the recommended pattern since Room 2.1 — this change is mostly validation. If you have any remaining synchronous DAO functions that are not marked suspend and do not return Flow, they need to be updated. The migration guide on developer.android.com provides a systematic approach to identifying affected DAOs.
JavaScript and WebAssembly — the headline KMP expansion. The Room 3.0 release adds JavaScript and WasmJS as KMP targets. Combined with the release of the SQLiteDriver interfaces that also target JavaScript and WasmJs and a new driver WebWorkerSQLiteDriver located in the new artifact androidx.sqlite:sqlite-web, it is possible to use Room in common code that targets all major KMP platforms.
The WebWorkerSQLiteDriver uses a Web Worker-based architecture to persist the database in the Origin Private File System (OPFS) — the browser’s private, sandboxized storage area. Due to the asynchronous nature of the web platforms, Room APIs that took SQLiteStatement as argument are now suspend functions to properly support web storage, which is inherently asynchronous.
For most Android developers, JavaScript and WASM targets are not immediately relevant. But for teams building Kotlin Multiplatform applications that target Android plus web — a configuration that is becoming more common as KMP matures — this is the completion of Room’s platform coverage story. Android, iOS, JVM desktop, macOS native, Linux native, JavaScript, and WASM are now all supported under a single Room codebase.
With the release of Room 3.0, Room 2 enters maintenance mode and will only receive patch releases on top of 2.8.0, limited to bug fixes and dependency updates, until Room 3.0 reaches stability. Start planning your migration now — the alpha period is the right time to evaluate the breaking changes against your specific codebase before stable.
Paging 3 — KMP Expansion to JVM, iOS, and Beyond
While Paging 3.5 is the version referenced in developer briefings, the KMP expansion story for Paging has been rolling out across recent 3.x releases and deserves a complete picture.
Paging now ships artifacts compatible with Kotlin Multiplatform, thanks in large part to upstreamed work from CashApp’s multiplatform-paging project. This will allow us to avoid divergence between two repositories and keep them compatible. paging-common has moved all Paging 3 APIs to common and is now compatible with JVM and iOS in addition to Android. paging-testing has moved its code to common and is now compatible with JVM and iOS in addition to Android. paging-compose has moved its code to common and ships an Android artifact, matching the multiplatform support of androidx.compose.
The CashApp attribution is notable. Paging now ships artifacts compatible with Kotlin Multiplatform, thanks in large part to upstreamed work from CashApp’s multiplatform-paging project. Google’s willingness to upstream an established community KMP adaptation rather than rebuild from scratch reflects an approach that is accelerating Jetpack’s KMP coverage without requiring every library team to re-architect from zero. The pattern — community builds the KMP adaptation, Google upstreams it into the official library — is also visible in the Paging 3 target expansion across watchOS, tvOS, and linuxArm64 added in subsequent releases.
For practical Paging usage, paging-runtime, paging-guava, paging-rxjava2, and paging-rxjava3 will remain Android only. The platform-independent core — paging-common, paging-testing, and paging-compose — is where the KMP value lives. For apps using Paging with Compose for LazyColumn or LazyVerticalGrid pagination, the paging-compose artifact now targets common code and will work in any KMP target that Compose Multiplatform supports.
Media3 1.10 — The Playback Library Joins the KMP Wave
Media3 1.10’s stable release, delivers Material 3 playback widgets, VVC/H.266 codec support, and improved Transformer export speed — and positions itself within the same KMP and multiplatform direction visible across the other April Jetpack releases.
The media3-ui-compose-material3 module’s Player Composable, ProgressSlider, and PlaybackSpeedToggleButton are all written in Compose — making them inherently more portable across Compose Multiplatform targets than the previous PlayerView XML approach. And Player.mute() / Player.unmute() graduating from @UnstableApi to stable reduces the friction for apps using these APIs in shared KMP code.
The Pattern: Jetpack Is Going Multiplatform, Fast
Taken individually, each of these library releases tells its own story. Taken together, they describe a coordinated strategic shift that has been underway since 2024 and is now reaching visible momentum.
Room 3.0 is the most dramatic example: a library that was Android-only by architecture for its entire decade-long existence has been rebuilt from the ground up as a KMP-first library, complete with new Maven coordinates to signal the break. Historically, Room 2.x did not effectively cover all KMP targets, making it less competitive than established options like SQLDelight. The major changes in 3.x finally show the true power of Kotlin Multiplatform, as another existing, popular Android dependency is now fully KMP-compatible.
Compose’s HostDefaultProvider change is more subtle but equally directional — decoupling compose-runtime from compose-ui so that the runtime layer can operate in contexts where UI rendering is not available. Paging’s move of paging-common and paging-compose to common source is the persistence + presentation paging pattern becoming platform-agnostic. Media3’s Compose-based UI module is playback controls that can, in principle, be reused across platforms.
The connective tissue across all of these changes is the same: Google is building a future where the Jetpack libraries that Android developers know and depend on are the Kotlin ecosystem’s standard libraries — not just Android’s standard libraries. Aluminium OS, Android Automotive, Android XR, and whatever new platform surface Google announces at The Android Show on May 12 will all need the same persistence, UI, and media primitives. Building those primitives on KMP means building them once, correctly, for every surface.
For Android developers, the immediate practical message is equally clear: learn KSP, learn KMP conventions, migrate off KAPT and SupportSQLite, and embrace coroutines as the only async model. The Jetpack libraries are leading the way. The Android 17 ecosystem — with mandatory large-screen adaptive compliance, new companion device APIs, and an “intelligent OS” platform architecture — is where these libraries will be used. The time to get fluent with the new foundations is now.
Quick Migration Reference
Compose 1.11:
- Update BOM to 2026.04.01
- Migrate Compose tests from UnconfinedTestDispatcher to StandardTestDispatcher — wrap assertion code in advanceUntilIdle()
- Remove v1 test API @OptIn annotations (v1 APIs are now deprecated)
- Plan for compileSdk 37 + AGP 9 requirement in upcoming 1.12
Room 3.0 Alpha:
- Change Maven group from androidx.room to androidx.room3
- Migrate all Room imports from androidx.room.* to androidx.room3.*
- Migrate annotation processing from KAPT to KSP
- Mark all synchronous DAO functions as suspend or return Flow
- Replace openHelper.writableDatabase access with room3-sqlite-wrapper if needed
- Room 2.x remains in maintenance mode — no urgency to migrate before Room 3.0 reaches stable, but start evaluating now
Paging:
- If using paging-common or paging-compose in a KMP project: update to the latest stable version and verify your target platform is in the supported list
- paging-runtime remains Android-only
Media3 1.10:
- Update all Media3 artifacts to 1.10.0
- Remove @OptIn(UnstableApi::class) from Player.mute(), Player.unmute(), and Format.pcmEncoding usages