Tag Archives: Architecture

Google I/O 2022: What’s new in Jetpack

Posted by Amanda Alexander, Product Manager, Android

Android Jetpack logo on a blue background 

Android Jetpack is a key pillar of Modern Android Development. It is a suite of over 100 libraries, tools and guidance to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices so that you can focus on building unique features for your app.

Most apps in Google Play use Jetpack for app architecture. Today, over 90% of the top 1000 apps use Jetpack.

Here are the highlights of recent updates in Jetpack - an extended version of our What’s New in Jetpack talk for I/O!

Below we’ll cover updates in three major areas of Jetpack:

  1. Architecture Libraries and Guidance
  2. Performance Optimization of Applications
  3. User Interface Libraries and Guidance

And then conclude with some additional key updates.

1. Architecture Libraries and Guidance

App architecture libraries and components ensure that apps are robust, testable, and maintainable.

Data Persistence

Room is the recommended data persistence layer which provides an abstraction layer over SQLite, allowing for increased usability and safety over the platform.

In Room 2.4, support for Kotlin Symbol Processing (KSP) moved to stable. KSP showed a 2x speed improvement over KAPT in our benchmarks of Kotlin code. Room 2.4 also adds built-in support for enums and RxJava3 and fully supports Kotlin 1.6.

Room 2.5 includes the beginning of a full Kotlin rewrite. This change sets the foundation for future Kotlin-related improvements while still being binary compatible with the previous version written in the Java programming language. There is also built-in support for Paging 3.0 via the room-paging artifact which allows Room queries to return PagingSource objects. Additionally, developers can now perform JOIN queries without the need to define additional data structures since Room now supports relational query methods using multimap (nested map and array) return types.

@Query("SELECT * FROM Artist 
    JOIN Song ON Artist.artistName = 
fun getArtistToSongs(): Map<Artist, List<Song>>

Relational query methods using multimap return types

Database migrations are now simplified with updates to AutoMigrations, with added support for additional annotations and properties. A new AutoMigration property on the @Database annotation can be used to declare which versions to auto migrate to and from. And when Room needs additional information regarding table and column modifications, the @AutoMigration annotation can be used to specify the inputs.

  version = MyDb.LATEST_VERSION,
  autoMigrations = {
    @AutoMigration(from = 1, to = 2,
      spec = MyDb.MyMigration.class),
    @AutoMigration(from = 2, to = 3)
public abstract class MyDb
    extends RoomDatabase {


The DataStore library is a robust data storage solution that addresses issues with SharedPreferences. To better understand how to use this powerful replacement for many SharedPreferences use cases, you can check out a series of videos and articles in Modern Android Development Skills: DataStore which includes guidance on testing your app’s usage of the library, using it with dependency injection, and migrating from SharedPreference to Proto DataStore.

Incremental Data Fetching

The Paging library allows you to load and display small chunks of data to improve network and system resource consumption. App data can be loaded gradually and gracefully within RecyclerViews or Compose lazy lists.

Paging 3.1 provides stable support for Rx and Guava integrations, which provide Java alternatives to Paging’s native use of Kotlin coroutines. This version also has improved handling of invalidation race conditions with a new return type, LoadResult.Invalid, to represent invalid or stale data. There is also improved handling of no-op loads and operations on empty pages with the new onPagesPresented and addOnPagesUpdatedListener APIs.

To learn more about Paging 3, check out the new, simplified Paging Basics Codelab on the Android Developer site which demonstrates how to integrate the Paging library into an app that shows a list.

GIF showing Paging Basics list 

Defining In Application Navigation Model

The Navigation library is a framework for moving between destinations in an app.

The Navigation component is now integrated into Jetpack Compose via the new navigation-compose artifact which allows for composable functions to be used as destinations in your app.

The Multiple Back Stacks feature has improved to make it easier to remember state. NavigationUI now automatically saves and restores the state of popped destinations, meaning developers can support multiple back stacks without any code changes.

Large screen support was enhanced with the navigation-fragment artifact providing a prebuilt implementation of a two-pane layout in AbstractListDetailFragment. This fragment uses a SlidingPaneLayout to manage a list pane – managed by your subclass – and a detail pane, which uses a NavHostFragment.

All Navigation artifacts have been rewritten in Kotlin and feature improved nullability of classes using generics – such as NavType subclasses.

Opinionated Architecture Guidance

To learn more about how our key architecture libraries work together, you can view a collection of videos and articles covering best practices for modern Android development in a series called Modern Android Development Skills: Architecture.

2. Performance Optimization of Applications

Using performance libraries allows you to build performant apps and identify optimizations to maintain high performance, resulting in better end-user experiences.

Improving Start-up Times

App speed can have a big impact on a user’s experience, particularly when using apps right after installation. To improve that first time experience, we created Baseline Profiles. Baseline Profiles allow apps and libraries to provide the Android run-time with metadata about code path usage, which it uses to prioritize ahead-of-time compilation. This profile data is aggregated across libraries and lands in an app’s APK as a baseline.prof file, which is then used at install time to partially pre-compile the app and its statically-linked library code. This can make your apps load faster and reduce dropped frames the first time a user interacts with an app.

We’ve already started leveraging Baseline Profiles at Google. The Play Store app saw a decrease in initial page rendering time on its search results page of 40% after adopting Baseline Profiles. Baseline profiles have also been added to popular libraries, such as Fragments and Compose, to help provide a better end-user experience. To create your own baseline profile, you need to use the Macrobenchmark library.

Instrumenting Your Application

The Macrobenchmark library helps developers better understand app performance by extending Jetpack’s benchmarking coverage to more complex use-cases, including app startup and integrated UI operations such as scrolling a RecyclerView or running animations. Macrobenchmark can also be used to generate Baseline Profiles.

Macrobenchmark has been updated to increase testing speed and has several new experimental features. It also now supports Custom trace-based timing measurements using TraceSectionMetric, which allows developers to benchmark specific sections of code. Additionally, the AudioUnderrunMetric now enables detection of audio buffer underruns to help understand audible jank.

BaselineProfileRule generates profiles to help with runtime optimizations. BaselineProfileRule works similarly to other macro benchmarks, where you represent user actions as code within lambdas. In the example below, the critical user journey that the compiler should optimize ahead of time is a cold start: opening the app’s landing activity from the launcher.

class BaselineProfileGenerator {
  val baselineProfileRule = BaselineProfileRule()

  fun startup() = baselineProfileRule.collectBaselineProfile(
    packageName = "com.example.app"
  ) {

    // This block defines the app's critical user journey. Here we are
    // interested in optimizing for app startup, but you can also navigate
    // and scroll through your most important UI.

For more details and a full guide on generating and using baseline profiles with Macrobenchmark, check our guidance on the Android Developers site.

Avoiding UI Stuttering / Jank

The new JankStats library helps you track and analyze performance problems in your app’s UI, including reports on dropped rendering frames – commonly referred to as “jank.” JankStats builds on top of existing Android platform APIs, such as FrameMetrics, but can be used back to API level 16.

The library also offers additional capabilities beyond those built into the platform: heuristics that help pinpoint causes of dropped frames, UI state that provides additional context in reports, and reporting callbacks that can be used to upload data for analysis.

Here’s a closer look at the three major aspects of JankStats:

  1. Identifying Jank: This library uses internal heuristics to determine when jank has occurred, and uses that information to know when to issue jank reports so that developers have information on those problems to help analyze and fix the issues.
  2. Providing UI Context: To make the jank reports more useful and actionable, the library provides a mechanism to help track the current state of the UI and user. This information is provided whenever reports are logged, so that developers can understand not only when problems occurred, but also what the user was doing at the time. This helps to identify problem areas in the application that can then be addressed. Some of this state is provided automatically by various Jetpack libraries, but developers are encouraged to provide their own app-specific state as well.
  3. Reporting Results: On every frame, the JankStats client is notified via a listener with information about that frame, including how long the frame took to complete, whether it was considered jank, and what the UI context was during that frame. Clients are encouraged to aggregate and upload the data as they see fit for analysis that can help debug overall performance problems.

Adding Logging to your App

The Tracing library enables profiling of app performance by writing trace events to the system buffer. Tracing 1.1 supports profiling in non-debug builds back to API level 14, similar to the <profileable> manifest tag which was added in API level 29.

3. User Interface Libraries and Guidance

Several changes have been made to our UI libraries to provide better support for large-screen compatibility, foldables, and emojis.

Jetpack Compose

Jetpack Compose, Android’s modern toolkit for building native UI, has reached 1.2 beta today which has added several features to support more advanced use cases, including support for downloadable fonts, lazy layouts, and nested scrolling interoperability. Check out the What’s New in Jetpack Compose blog post to learn more.

Understanding Window State

The new WindowManager library helps developers adapt their apps to support multi-window environments and new device form factors by providing a common API surface with support back to API level 14.

The initial release targets foldable device use cases, including querying physical properties that affect how content should be displayed.

Jetpack’s SlidingPaneLayout component has been updated to use WindowManager’s smart layout APIs to avoid placing content in occluded areas, such as across a physical hinge.

Drag and Drop

The new DragAndDrop library also helps with new form factors and windowing modes by enabling developers to accept drag-and-drop data – both from inside and outside their app. DrapAndDrop includes a consistent drop target affordance and it supports back to API level 24.

Drag and drop sample GIF 

Backporting New APIs to Older API Levels

The AppCompat library allows access to new APIs on older API versions of the platform, including backports of UI features such as dark mode.

AppCompat 1.4 integrates the Emoji2 library to bring default support for new emoji to all text-based views supported by AppCompat on API level 14 and above.

Custom locale selection is now supported back to API level 14. This feature enables manual persistence of locale settings across app starts, and supports automatic persistence via a service metadata flag. This tells the library to load the locales synchronously and recreate any running Activity as needed. On API level 33 and above, persistence is managed by the platform with no additional overhead.

Other key updates


The Annotation library exposes metadata that helps tools and other developers understand your app's code. It provides familiar annotations like @NonNull that pair with lint checks to improve the correctness and usability of your code.

Annotation is migrating to Kotlin, so now developers using Kotlin will see more appropriate annotation targets, including @file.

Several highly-requested annotations have been added with corresponding lint checks. This includes annotations concerning method or function overrides, and the @DeprecatedSinceApi annotation which provides a corollary to @RequiresApi and discourages use beyond a certain API level.


We now have over 100 projects in our GitHub! Several modules are open for developer contributions using the standard GitHub-based workflow:

  • Activity
  • AppCompat
  • Biometric
  • Collection
  • Compose Compiler
  • Compose Runtime
  • Core
  • DataStore
  • Fragment
  • Lifecycle
  • Navigation
  • Paging
  • Room
  • WorkManager

Check the landing page for more information on how we handle pull requests, and to get started building with Jetpack libraries.

This was a brief tour of all the changes in Jetpack over the past few months. For more details on each Jetpack library, check out the AndroidX release notes, quickly find relevant libraries with the API picker and watch the Google I/O talks for additional highlights.

Java is a trademark or registered trademark of Oracle and/or its affiliates.

Architecture MAD Skills series wrap up

Posted by Manuel Vicente Vivo, Developer Relations Engineer

MADSkills Jetpack DataStore 

Now that our MAD Skills series on Architecture is complete, let’s do a quick wrap up of all the things we’ve covered in each episode!

Episode 1 — The data layer

Learn about the data layer and its two basic components: repositories and data sources. We'll also cover data immutability, error handling, threading, testing and more tricks and recommendations with Jose Alcérreca.

Episode 2 — The UI layer

Learn about the UI layer and its state. Tunji Dahunsi covers UI state representation, production and consumption all within the context of a unidirectional data flow app!

Episode 3 — Handling UI events

Learn all about UI events. I—Manuel Vivo—cover the different types of UI events, the best practices for handling them, and more!

Episode 4 — The domain layer

The Domain layer is an optional layer which sits between the UI and Data layers. Don Turner explains how the domain layer can simplify your app architecture, making it easier to understand and test.

Episode 5 — Organizing modules

Emily Kager shares a tip around organizing modules in Android apps.

Episode 6 — Entities

Garima Jain shares a tip about creating separate data models based on various Architecture layers in your project.


Tunji Dahunsi, Miłosz Moczkowski, Yigit Boyar, and I hung out together in a live Q&A session to answer all the questions you had!

Android and Architecture

Android and Architecture

The Android operating system provides a strong foundation for building apps that run well on a wide range of devices and form factors. That being said, we've listened to developer feedback; Issues like complex lifecycles and the lack of a recommended app architecture make it challenging to write robust apps.

 We need to make it easier—and more fun—to write robust apps, empowering developers to focus on areas where they can innovate. Today we're announcing a guide to Android app architecture along with a preview of Architecture Components. Rather than reinventing the wheel, we're also recognizing the work done by popular Android libraries.

Opinions not Prescriptions

We know that there's more than one way to write Android applications.  What we're providing is a set of guidelines that can help you architect an Android application to work best with the unique ways that Android interacts. The Android framework has well-defined APIs to handle contact points with the OS, such as Activities, but these are entry points into your application, not building blocks for your application architecture; Framework components don't force you to separate your data model from your UI components, or provide a clear way to persist data independent of the lifecycle.

Building Blocks

Android Architecture components work together to implement a sane app architecture, while they individually address developer pain points. The first set of these components helps you:

  • Automatically manage your activity and fragment lifecycles to avoid memory and resource leaks
  • Persist Java data objects to an SQLite database

Lifecycle Components

New lifecycle-aware components provide constructs to tie core components of your applications to lifecycle events, removing explicit dependency paths.

A typical Android observation model would be to start observation in onStart() and stop observation in onStop().  This sounds simple enough, but often times you'll have several asynchronous calls happening at once, all managing the lifecycles of their component.  It's easy to miss an edge case.  The lifecycle components can help.

Lifecycle, LifecycleOwner, and LifecycleObserver

The core class for all of this is Lifecycle. It uses an enumeration for the current lifecycle state along with an enumeration for lifecycle events to track the lifecycle status for its associated component.

Lifecycle States and Events

LifecycleOwner is an interface that returns a Lifecycle object from the getLifecycle() method, while LifecycleObserver is a class that can monitor the component's lifecycle events by adding annotations to its methods. Putting this all together, we can create lifecycle-aware components that can both monitor lifecycle events and query the current lifecycle state.

public class MyObserver implements LifecycleObserver {
  public MyObserver(Lifecycle lifecycle) {
    // Starts lifecycle observation
  public void startFragmentTransaction() {
     // Queries lifecycle state
     if (lifecycle.getState.isAtLeast(STARTED)) {
        // perform transaction
  // Annotated methods called when the associated lifecycle goes through these events
  public void onResume() {
  public void onPause() {
MyObserver observer = new MyObserver(aLifecycleOwner.getLifecycle());


LiveData is an observable lifecycle-aware data holder class. Your UI code subscribes to changes in the underlying data, tied into a LifecycleOwner, and LiveData makes sure the observer:
  • Gets updates to the data while the Lifecycle is in an active state (STARTED or RESUMED)
  • Is removed when the LifecycleOwner is destroyed
  • Gets up-to-date data when the LifecycleOwner restarts due to a configuration change or is restarted from the back stack
This helps to eliminate many pathways for memory leaks, and reduces crashes by avoiding updates to stopped activities.
LiveData can be observed by many listeners, each tied to a lifecycle owner such as a Fragment or Activity.


ViewModel is a helper class that contains UI data for an Activity or Fragment that serves to separate view data ownership from UI controller logic. A ViewModel is retained as long as the scope of its Activity/Fragment is alive, including when the Activity/Fragmentis destroyed and recreated due to a configuration change; This allows ViewModel to make UI data available to the recreated activity or fragment instance. Wrapping UI data stored within the ViewModel with LiveData provides the data an observable lifecycle-aware home. LiveData handles the notification side of things while the ViewModel makes sure that the data is retained appropriately.

Data Persistence

The Android Architecture Components also simplify data persistence with the Room library. Room provides an object-mapping abstraction layer that allows fluent database access while harnessing the full power of SQLite. The core framework provides built-in support for working with raw SQL content. Although these APIs are powerful, they are fairly low-level and require a great deal of time and effort to use:

  • There is no compile-time verification of raw SQL queries.
  • As your schema changes, you need to update the affected SQL queries manually. This process can be time consuming and error prone.
  • You need to write lots of boilerplate code to convert between SQL queries and Java data objects.
Room takes care of these concerns for you while providing an abstraction layer over SQLite.

Database, Entity, and DAO

There are three major components in Room:
  • Entity represents the data for a single database row, constructed using an annotated Java data object. Each Entity is persisted into its own table.
  • DAO (Data Access Object) defines the methods that access the database, using annotations to bind SQL to each method.
  • Database is a holder class that uses annotations to define the list of entities and database version. The class content defines the list of DAOs. It's also the main access point for the underlying database connection.

To use Room, you annotate the Java data objects you wish to persist as entities, create a database containing these entities, and define a DAO class with the SQL to access and modify the database.

public class User {
    private int uid;
    private String name;
    // Getters and Setters - required for Room
    public int getUid() { return uid; }
    public String getName() { return name; }
    public void setUid(int uid) { this.uid = uid; }
    public void setName(String name) { this.name = name; }

public interface UserDao {
    @Query("SELECT * FROM user")
    List getAll();
    void insertAll(User... users);

@Database(entities = {User.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
    public abstract UserDao userDao();

Guide to App Architecture 

Architecture Components are designed to be standalone, but they're most effective when they're incorporated into an effective app architecture. Today we're launching a Guide to App Architecture that shows how to build a robust, modular, and testable app using Architecture Components. The Guide has three main goals:

  •  Defining principles that apply to Android app development. 
  • Describing an app architecture that works with those principles. 
  • Showing how to implement that architecture using Architecture Components. 
 We recommend all developers who have had to deal with these problems read the Guide; Even if you're happy with your existing app architecture, the Guide will have useful principles and insights.

Just the Beginning 

We're planning to continue being opinionated, and to continue to introduce new Architecture Components to make it easier for Android developers to make informed choices when architecting their applications. We encourage you to try the preview and provide feedback on what we're doing, because we're all in this together to make robust Android app development easier and more fun. To learn more about Android Architecture, check out: