Room 3.0 – Modernizing the Room

Posted by Daniel Santiago Rivera, Software Engineer





The first alpha of Room 3.0 has been released! Room 3.0 is a major breaking version of the library that focuses on Kotlin Multiplatform (KMP) and adds support for JavaScript and WebAssembly (WASM) on top of the existing Android, iOS and JVM desktop support.

In this blog we outline the breaking changes, the reasoning behind Room 3.0, and the various things you can do to migrate from Room 2.0.

Breaking changes

Room 3.0 includes the following breaking API changes:

  • Dropping SupportSQLite APIs: 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.

  • No more Java code generation: 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.

  • Focus on KSP: We are also dropping support for Java Annotation Processing (AP) and KAPT. Room 3.0 is solely a KSP (Kotlin Symbol Processing) processor, allowing for better processing of Kotlin codebases without being limited by the Java language.

  • Coroutines first: Room 3.0 embraces Kotlin coroutines, making its APIs coroutine-first. Coroutines is the KMP-compatible asynchronous framework and making Room be asynchronous by nature is a critical requirement for supporting web platforms.

A new package

To prevent compatibility issues with existing Room 2.x implementations and for libraries with transitive dependencies to Room (for example, WorkManager), 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 android.room3.RoomDatabase.

Kotlin and Coroutines First

With no more Java code generation, Room 3.0 also requires KSP and the Kotlin compiler even if the codebase interacting with Room is in Java. It is recommended to have a multi-module project where Room usage is concentrated and the Kotlin Gradle Plugin and KSP can be applied without affecting the rest of the codebase.

Room 3.0 also requires Coroutines and more specifically DAO functions have to be suspending unless they are returning a reactive type, such as a Flow. Room 3.0 disallows blocking DAO functions. See the Coroutines on Android documentation on getting started integrating Coroutines into your application.

Migration to SQLiteDriver APIs

With the shift away from SupportSQLite, apps will need to migrate to the SQLiteDriver APIs. This migration is essential to leveraging the full benefits of Room 3.0, including allowing the use of the bundled SQLite library via the BundledSQLiteDriver. You can start migrating to the driver APIs today with Room 2.7.0+. We strongly encourage you to avoid any further usage of SupportSQLite. If you migrate your Room integrations to SQLiteDriver APIs, then the transition to Room 3.0 is easier since the package change mostly involves updating symbol references (imports) and might require minimal changes to call-sites.

For a brief overview of the SQLiteDriver APIs, check out the SQLiteDriver APIs documentation.

For more details on how to migrate Room to use SQLiteDriver APIs, check out the official documentation to migrate from SupportSQLite.

Room SupportSQLite wrapper

We understand completely removing SupportSQLite might not be immediately feasible for all projects. To ease this transition, Room 2.8.0, the latest version of the Room 2.0 series, introduced a new artifact called androidx.room:room-sqlite-wrapper. This artifact offers a compatibility API that allows you to convert a RoomDatabase into a SupportSQLiteDatabase, even if the SupportSQLite APIs in the database have been disabled due to a SQLiteDriver being installed. This provides a temporary bridge for developers who need more time to fully migrate their codebase. This artifact continues to exist in Room 3.0 as androidx.room3:room3-sqlite-wrapper to enable the migration to Room 3.0 while still supporting critical SupportSQLite usage.

For example, invocations of Database.openHelper.writableDatabase can be replaced by roomDatabase.getSupportWrapper() and a wrapper would be provided even if setDriver() is called on Room’s builder.

For more details check out the room-sqlite-wrapper documentation.

Room and SQLite Web Support

Support for the Kotlin Multiplatform targets JS and WasmJS and brings some of the most significant API changes. Specifically, many APIs in Room 3.0 are suspend functions since proper support for web storage is asynchronous. The SQLiteDriver APIs have also been updated to support the Web and a new web asynchronous driver is available in androidx.sqlite:sqlite-web. It is a Web Worker based driver that enables persisting the database in the Origin private file system (OPFS).

For more details on how to set up Room for the Web check out the Room 3.0 release notes.

Custom DAO Return Types

Room 3.0 introduces the ability to add custom integrations to Room similar to RxJava and Paging. Through a new annotation API called @DaoReturnTypeConverter you can create your own integration such that Room’s generated code becomes accessible at runtime, this enables  @Dao functions having their custom return types without having to wait for the Room team to add the support. Existing integrations are migrated to use this functionality and thus will now require for those who rely on it to add the converters to the @Database or @Dao definitions.

For example, the Paging converter will be located in the android.room3:room3-paging artifact and it's called PagingSourceDaoReturnTypeConverter. Meanwhile for LiveData the converter is in android.room3:room3-livedata and is called LiveDataReturnTypeConverter.

For more details check out the DAO Return Type Converters section in the Room 3.0 release notes.

Maintenance mode of Room 2.x

Since the development of Room will be focused on Room 3, the current Room 2.x version enters maintenance mode. This means that no major features will be developed but patch releases (2.8.1, 2.8.2, etc.) will still occur with bug fixes and dependency updates. The team is committed to this work until Room 3 becomes stable.

Final thoughts

We are incredibly excited about the potential of Room 3.0 and the opportunities it unlocks for the Kotlin ecosystem. Stay tuned for more updates as we continue this journey!

TikTok reduces code size by 58% and improves app performance for new features with Jetpack Compose

Posted by Ajesh R Pai, Developer Relations Engineer & Ben Trengrove, Developer Relations Engineer

TikTok is a global short-video platform known for its massive user base and innovative features. The team is constantly releasing updates, experiments, and new features for their users. Faced with the challenge of maintaining velocity while managing technical debt, the TikTok Android team turned to Jetpack Compose.

The team wanted to enable faster, higher-quality iteration of product requirements. By leveraging Compose, the team sought to improve engineering efficiency by writing less code and reducing cognitive load, while also achieving better performance and stability.

Streamlining complex UI to accelerate developer productivity

TikTok pages are often more complex than they appear, containing numerous layered conditional requirements. This complexity often resulted in difficult-to-maintain, sub-optimally structured View hierarchies and excessive View nesting, which caused performance degradation due to an increased number of measure passes.

Compose offered a direct solution to this structural problem.

Furthermore, Compose’s measurement strategy helps reduce double taxation, making measure performance easier to optimize. 

To improve developer productivity, TikTok’s central Design System team provides a component library for teams working on different app features.  The team observed that Development in Compose is simple; leveraging small composables is highly effective, while incorporating large UI blocks with conditional logic is both straightforward and has minimal overhead.


Building a path forward through strategic migration

By strategically adopting Jetpack Compose, TikTok was able to stay on top of technical debt, while also continuing to focus on creating great experiences for their users. The ability of Compose to handle conditional logic cleanly and streamline composition allowed the team to achieve up to a 78% reduction in page loading time on new or fully rewritten pages. This improvement was 20–30% in smaller cases, and 70–80% for full rewrites and new features. They also were able to reduce their code size by 58%, when compared to the same feature built in Views. The team has further shared a couple of learnings:  

TikTok team’s overall strategy was to incrementally migrate specific user journeys. This gave them an opportunity to migrate, confirm measurable benefits, then scale to more screens. They started with using Compose to simplify the overall structure in the QR code feature and saw the improvements. The team later expanded the migration to the Login and Sign-up experiences. 

The team shared some additional learnings:  

While checking performance during migration, the TikTok team found that using many small ComposeViews to replace elements inside a single ViewHolder, caused composition overhead. They achieved better results by expanding the migration to use one single ComposeView for the entire ViewHolder.

When migrating a Fragment inside ViewPager, which has custom height logic and conditional logic to hide and show ui based on experiments, the performance wasn’t impacted. In this case, migrating the ViewPager to Composable performed better than migrating the Fragment. 

Jun Shen really likes that Compose "reduces the amount of code required for feature development, improves testability, and accelerates delivery". The team plans to steadily increase Compose adoption, making it their preferred framework in the long term. Jetpack Compose proved to be a powerful solution for improving both their developer experience and production metrics at scale.

Get Started with Jetpack Compose

Learn more about how Jetpack Compose can help your team.

Chrome for Android Update

 Hi, everyone! We've just released Chrome 146 (146.0.76380.115) for Android. It'll become available on Google Play over the next few days. 

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.


Android releases contain the same security fixes as their corresponding Desktop releases (Windows & Mac: 146.0.7680.75/.76, Linux:  146.0.7680.75) unless otherwise noted.

Krishna Govind

Stable Channel Update for Desktop

The Stable channel has been updated to 146.0.7680.75/76 for Windows/Mac  and 146.0.7680.75 for Linux, which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log



Security Fixes and Rewards

Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.


This update includes 2 security fixes. Please see the Chrome Security Page for more information.


[N/A][491421267] High CVE-2026-3909: Out of bounds write in Skia. Reported by Google on 2026-03-10

[N/A][491410818] High CVE-2026-3910: Inappropriate implementation in V8. Reported by Google on 2026-03-10


Google is aware that exploits for both CVE-2026-3909 & CVE-2026-3910 exist in the wild.


We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.


Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista

Google Chrome

Whisk is moving to Flow on April 30, 2026

On April 30, 2026, the best capabilities from Whisk are moving directly into Flow, Google's unified platform for AI-powered image and video creation.

Users with active Whisk accounts will receive an email announcing this change. An in-product notification will guide them through migrating their content to Flow.

  • April 30, 2026 — Whisk discontinued. Any media remaining in a user's Whisk library after this date will be permanently deleted and will no longer be recoverable.
  • Now through April 30 — Users should save their libraries. In the coming weeks, users will see an opt-in notification in Whisk with instructions to migrate their content to Flow. Users can also download their data directly from Whisk at any time before the April 30 deadline.
  • AI credits – no action needed. Because Whisk and Flow use the same AI credits platform, your existing credits are already available in Flow.
  • Geographic availability – Flow is not yet available in all countries. Users in unsupported regions will lose access to Whisk on April 30, 2026 without a migration path. We recommend encouraging them to download their content before the deadline. See Flow's supported countries. See Flow's supported countries.

Getting started

  • Admins: We recommend proactively communicating this change to affected users in your organization ahead of the April 30, 2026, deadline.
  • End users: Users will receive an email announcement and an in-product notification in Whisk with steps to migrate their assets to Flow. Migration is opt-in and assets will not transfer automatically.

Rollout pace

Impact

  • Impacts all Google Workspace customers and Workspace Individual subscribers

Resources

Use Help me schedule in Gmail to easily set up a meeting time with multiple guests

Finding time to meet often requires numerous back-and-forth emails, particularly when coordinating between multiple internal and external stakeholders. To address this, we are expanding the "Help me schedule" functionality in Gmail (introduced in October 2025) to support group meetings.

Previously, "Help me schedule" was limited to scheduling between two individuals. With this update, users can now coordinate meetings with multiple guests directly from the Gmail compose window.

Gemini in Gmail detects when you are trying to coordinate a time within an email and will surface a Help me schedule button in the toolbar. If there is more than one recipient on the thread, Gemini will propose ideal time slots that work for you and any colleagues, if you have visibility to their calendar. While the initial guest list is pulled automatically from the email thread, users have full control to edit guests as needed.

When a recipient receives the email, they can cross-reference the proposed availability against their own colleagues' schedules. Once a recipient selects a time, a Calendar invite is automatically sent to all guests.


Core capabilities:

  • Analyze schedules and suggest meeting times: Gemini proposes ideal time slots that work for you and your colleagues (that you have calendar visibility for), based on their availability, working hours, and other factors
  • Manage guest list: The initial guest list for the meeting gets pulled automatically from the email thread, and users have full control to edit the guests
  • Automate invites: Once a recipient selects a time, a Calendar invite is automatically sent to all guests, including external participants.

Getting started

Rollout pace

Availability

  • Business: Business Standard and Plus
  • Enterprise: Enterprise Starter, Standard, and Plus
  • AI Add-ons: Google AI Pro for Education
  • Other Editions: Frontline Plus

Resources