This big release brings stable Baseline Profiles, new benchmarking modes, full tracing and more.

The Jetpack Benchmark library provides a set of tools to inspect and improve application performance in a controlled environment.

These lab tests can inspect entire end to end user flows using Macrobenchmark or implementation details in a loop with Microbenchmark.

Macrobenchmark also can be used to generate baseline profiles and now Startup Profiles. Both help to improve application performance.

All these features are provided by the androidx.benchmark library group. Despite the minor version increment from 1.1.1 to 1.2.0, a lot of new features have been added. Let’s dive into what’s new in Jetpack Benchmark 1.2.0.

New in baseline profiles

Baseline profiles improve overall code execution speed of included paths by about 30% by avoiding interpretation and the cost of class initialization by ahead of time compiling.

These profiles have been around for a while and are already used by many apps and games on the Google Play Store. Libraries can also contribute baseline profiles and improve app performance seamlessly. And with the new Gradle plugin, automated baseline profile generation is easier than ever.

✨ Baseline profile API is now stable ✨

With the Benchmark 1.2.0 release baseline profiles are no longer experimental.

When baseline profiles were introduced as an experimental feature in Benchmark 1.1.0, it shipped with the collectBaselineProfile API. It was replaced by the simpler collect. You now can generate stable baseline profiles and use UiAutomator to capture user journeys as part of the profile.

To see the API in action, check out the documentation and samples.

Above code collects a baseline profile for app startup and a user journey where UiAutomator is used to find the “For You” text, click it and then scroll a column down and up.

Set up baseline profile modules using Android Studio Canary

We’re working on improving the set up experience for baseline profiles. This new experience is available in the Android Studio Iguana Canary builds.

The Android Studio baseline profile Generator module template automates the creation of a new module to generate and benchmark baseline profiles. Running the template generates most of the typical build configuration, baseline profile generation, and verification code. The template creates code to generate and benchmark baseline profiles. This helps to improve and measure app startup times.

Create a new module and select “Baseline Profile Generator”, go through the dialog and click finish.

Now you can generate baseline profiles directly from the Run dialog in Android Studio

Automate baseline profile generation with a Gradle plugin

A high priority feature request from developers implementing baseline profiles was to help them with automating the process.

When using AGP 8.0 or newer you can now use the Baseline Profile Gradle plugin. This plugin lets you fully control baseline profile creation. It seamlessly integrates profile generation in the Gradle build pipeline. You can control when the profile will update and make sure it’s always fresh for a new release.

To use the Gradle plugin, apply it to your app and baseline profile modules. You can do this manually, following the guide or with Android Studio Iguana’s new module template for baseline profiles. The plugin offers wide configuration options for high flexibility. You can use Gradle managed devices for ease of running on a CI system. baseline-prof.txt source files no longer have to be part of your app’s source set when using the Gradle plugin. They can be considered reproducibly generated code.

Simplified profile filtering empower complex applications and library developers

Large code bases or libraries require filter mechanisms to only include specific classes in a baseline profile. The Gradle plugin provides just that. The new filter block enables including or excluding code via regular expressions.

New in Macrobenchmark

Arguments to improve benchmarks

New profiling modes

Method tracing and stack sampling modes are now available with Macrobenchmark.

With these profile modes you can get detailed information on specific areas of the code that’s being executed. To enable it, use the androidx.benchmark.profiling.mode argument with the StackSampling or MethodTracing parameters.

With MethodTracing you can see exactly which methods are being called while a code block executes. This can help to identify whether the app is doing what you expect it to do at a glance.

StackSampling highlights where the benchmark spends time across all call stacks. With this you can see where the app spends most of the time during a run.

⚠️

Note: These two modes are known to skew performance metrics. You can rely on them to see what is going on during runtime but do take frame timing or startup results with a grain of salt when method tracing or stack sampling is enabled.

⚠️

Quicker validation with dry runs

The dryRunMode.enable instrumentation argument enables quicker validation. This can be useful for presubmit environments or during development of a benchmark and brings the flag from Microbenchmark to Macrobenchmark.

Use Perfetto Sdk Tracing for higher resolution metrics

To get even more details when benchmarking you can trace app behavior with Perfetto Sdk Tracing. While this loads a library during app runtime and slows down StartupMode.COLD benchmarks, it does give you a more detailed and full picture of what’s happening during a benchmark. This can be very useful when you suspect areas of improvement not being surfaced by regular tracing.

To enable Perfetto Sdk tracing, add these dependencies to your benchmark module,

and run the benchmarks with the perfettoSdkTracing.enable instrumentation argument.

More insight with new experimental metrics

New metrics in the Macrobenchmark library provide you with more insights into data and further empower automated monitoring.

Post process anything with PerfettoTraceProcessor

The PerfettoTraceProcessor API brings every detail from a benchmark result into a single API. It’s highly flexible and enables synchronous and async trace sections, kernel-level scheduling timing, binder events and anything else that’s captured in a Perfetto trace.

Now you can use the same trace querying API in macrobenchmark. This is especially useful to create your own fully custom TraceMetric.

Surface more details with TraceSectionMetric and TraceMetric

These trace specific APIs enable quick processing of specific sections and traces of an app.

The TraceSectionMetric enables capturing custom trace sections in an app. For example, you can use the TraceSectionMetric to capture how long specific parts during activity startup took. This example shows how you can collect the duration of the onStart and onResume methods. Additionally, below sample aggregates the amount of time it took to render frames by capturing the doFrame trace using Mode.Sum.

These metrics are all surfaced as part of the benchmark results and can help inform decisions on where to optimize as well as monitor for potential performance regressions.

Macrobenchmark now also ships with the new TraceMetric. This API enables you to create your own complex metrics from macrobenchmark data as it enables you to run arbitrary queries against Perfetto traces. You can take any data that is captured in the Perfetto trace during a benchmark run and turn it into a metric. You can learn more about how to use the available data in the Perfetto documentation.

Understand power consumption with PowerMetric

PowerMetric captures the change of power, energy or battery charge metrics over time for specified duration.

This metric provides details about Battery, Energy, and Power when running on a device with power rails such as Pixel 6 or newer.

With this information you can verify how resource hungry a specific part of an application is or how different polling intervals of APIs such as location services affect battery levels. And you can even see how animations or dark mode affect power consumption and tweak how your application can save power on different display types such as AMOLED or OLED.

New in Microbenchmark

Profiling a microbenchmark is important, so we’ve made the profiling iteration loop faster, and more configurable. Profiling now runs as a separate phase in microbenchmarks, after all metrics are collected, so you can see both profiling results and measurements, or run profiling continuously in CI.

We’ve also added an experimental API to let you select a profiler in the code, while you’re iterating on the microbenchmark. This experimental API lets you configure tracing, like enabling the custom `trace()` sections that are off by default in micro to avoid interference with shouldEnableAppTagTracing.

Configure Microbenchmark behavior from within

With MicrobenchmarkConfig you can configure the way to capture a benchmark without having to rely on instrumentation arguments.

This enables configuring profiling or trace behavior, meaning you can enable trace app tags or perfetto sdk tracing per benchmark rule.

With these enabled you see a new “Trace” and “Stack Sampling Trace” link in benchmark results, which can be inspected using Android Studio Profilers.

To enable tracing, you need to add dependencies on both, the perfetto tracing and perfetto binary libraries, to your microbenchmark tests. Failure to do this will result in this runtime exception.

java.lang.RuntimeException:
Issue while enabling Perfetto SDK tracing in com.example.benchmark.test:

Error:
Unable to locate libtracing_perfetto.so required to enable Perfetto SDK.
Tried inside /data/app/com.example.benchmark.test/base.apk.

Control benchmark state without JUnit

BenchmarkState allows querying the state of a benchmark without relying on JUnit APIs. With this you can instantiate BenchmarkState, which is particularly useful when you’re not using JUnit4.

Capture and customize Perfetto traces

The PerfettoTraceRule helps you analyze test performance in detail. When using PerfettoTrace.record you can write trace-based unit tests or create your own test infrastructure on top of Perfetto traces.

Performance optimizations and bugfixes

Next to all these new features, bugs were fixed and performance of the library group improved. To see everything that changed in between version 1.1.1 and 1.2.0, read the release notes.

What’s new in Jetpack Benchmark 1.2.0 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turo is the world’s largest car sharing marketplace where guests can book any car they want, and wherever they want it, from a vibrant community of trusted hosts.

Developers at Turo recently invested heavily in improving the startup performance of its Android application. Startup time is the first impression users have of an app, and slower load times can negatively impact user retention and engagement. The team wanted to give users a faster, more streamlined experience every time they launched the app. And using Android’s best tools, resources, and practices, they were able to cut the app’s startup time by 77%.

Setting the stage with the App Startup library

App initialization includes an application’s entire startup process and all the code it runs before rendering its first UI frame. For Turo, this meant users had to wait for the app to run its initial startup, synchronous network requests, and a custom splash animation — all before they were ever shown the app’s home screen.

Turo’s developers knew that to improve the application’s loading times, they would need to condense and remove many of these cumbersome startup events. To help pare down these events, Turo engineers used Android’s App Startup library.

The App Startup library gave Turo’s developers a simple, streamlined way to initialize multiple components during the application’s launch. It also enabled them to select which components to initialize and in what order, allowing them to significantly improve load times. Having the App Startup library in place set the foundation for the rest of Turo’s startup optimization.

Deferring network requests and cutting the splash screen

Prior to optimization, the app performed multiple network requests sequentially and then displayed a custom, one-second splash animation before users could access the app’s home screen. This resulted in a slow startup process, especially if a user had poor network connectivity.

Removing the splash animation was an easy way for Turo developers to improve perceived loading time. And by making network requests parallel and asynchronous, users could access the home screen much faster. “Initially, we used a dedicated SplashActivity to run all the startup work before routing the app to the HomeActivity. However, the latest guidelines advise against this approach. Therefore, we eliminated the redundant SplashActivity and transferred all the startup logic to our root activity by leveraging the Splash Screen API,” said Pavlo Stavytskyi, a senior staff software engineer at Turo.

At the same time, the app was also performing a number of other startup network requests to tailor the experience to individual users, resulting in inconsistent user experiences.“If the app is used by a guest, some network requests help decide which screen should be shown after the splash screen,” said Pavlo. “By default, it’s the home screen. However, there are special cases where the user could be redirected either straight to an active vehicle reservation or to a feedback screen.”

The team didn’t want to slow down every app startup by checking for these niche scenarios. Instead, Turo now always opens the home screen by default while making network requests asynchronously. If a redirect is required, the appropriate screen is displayed on top of the home screen.

Applying Baseline Profiles

The Turo team also applied Baseline Profiles to improve the application’s performance. Baseline profiles help pre-compile startup code paths ahead of time, boosting Turo’s app startup time by another 15% according to Macrobenchmark tests. “After we removed all the synchronous network requests, our startup duration became more deterministic, and it made more sense to apply Baseline Profiles,” said Pavlo.

Performance improvements can lead to improved user retention, increased transactions, and better ratings. Baseline Profiles are a quick and reliable way to move the needle by a large amount.

Prioritizing startup performance

There are many factors that can impact an app’s startup time. It’s up to developers to identify where, when, and how they can improve their app to ensure it’s optimized for the best user experience.

“It’s important to start the improvement with tasks that require the least effort and produce the greatest results,” said Pavlo. “In many cases, engineering faces a conflict between allocating time and resources either on product work or performance optimization. However, treating performance as a stand-alone product feature is inevitable for its success.”

Optimize your app today

Improve your app’s startup time with Android’s best practices for app optimization, Android’s App Startup, and Baseline Profiles.

You also can read the full story of how Turo improved its app’s startup efficiency using Android’s developer tools and best practices.

Turo reduced its app startup time by 77% using Android Developer tools and best practices was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s new in Android Performance — Google I/O 2023 edition

Over the past years we have worked to make working with performance more approachable and rewarding. In this article we share the latest developments in that area. We’ll cover Baseline Profiles, tooling improvements within Android Studio, libraries and how we made the technology work better for you behind the scenes. We’re also very excited to share new experimental technology, working on top of Baseline Profiles, to provide you with even bigger startup performance improvements. Read on for a full tour of what’s new in Android Performance during Google I/O 2023, or jump directly to the end for actionable steps in your performance journey.

Updates on Baseline Profiles

Baseline Profiles improve code execution speed by about 30 %, for both app startup and runtime by avoiding just-in-time (JIT) compilation. We built several tools to help you streamline Baseline Profile creation and maintenance, including a new Android Studio Template and the Baseline Profile Gradle plugin. You can get started with both today, using Android Studio Hedgehog and the Android Gradle Plugin 8.0.0 or newer.

Streamline profile generation with the Baseline Profile Gradle Plugin

The Baseline Profile Gradle Plugin makes it easier to generate and maintain Baseline Profiles both during local development as well as CI. It performs all the necessary steps to generate and install a Baseline Profile into your application module.

To use the plugin, add an instrumented test module to your project and define a set of tests that navigate through your app to simulate critical user journeys. When you run the instrumented test, the Baseline Profile Gradle Plugin tracks all classes and methods that are executed during these user journeys and generates a Baseline Profile based on these classes and methods. It then copies the generated Baseline Profile into the application module’s source-set.

After applying the plugin, it can be configured with a new baselineProfile block in your build script. The generateBaselineProfile Gradle task runs all baseline profile tests for you. The resulting profile files are stored in a generated folder and can be accessed from there. These features remove friction from automating Baseline Profile generation, both locally and on a remote CI server. And by specifying a Gradle Managed Device to use when generating a profile, you don’t even need an attached physical device. The plugin’s DSL enables a highly configurable setup and enables you to automate and reproduce Baseline Profile generation.

Check out the code sample (currently on a separate branch) and guiding documentation to get started.

Create and manage multiple Baseline Profile source files with AGP 8+

AGP 8 onwards supports easier generation of Baseline Profile with support for multiple source files, variant specific profiles, and support for the new Gradle plugin mentioned above. The default location for Baseline Profiles now is src/main/baselineProfiles/. Baseline Profile source files stored in this directory will be picked up and merged into your application. This enables you to store separate profile files for app startup and each distinct user journey.

Easier onboarding with the Android Studio Baseline Profile Generator Template

To assist you getting started with Baseline Profiles, Android Studio Hedgehog (2023.1.1) adds the Baseline Profile Generator module wizard template. By using this template, your app can be set up with Baseline Profiles in a visually assisted way.

Get started by navigating to File > New > New Module and select Baseline Profile Generator from the list of templates.

When you’re finished, the template will have made several changes for you. It creates a new :baselineprofile test module containing basic generators and benchmarks. The BaselineProfileGenerator class creates a basic baseline profile for you and StartupBenchmarks can verify everything works as intended. Also, Baseline Profile Gradle plugin will be applied in relevant modules. Lastly, a dependency on androidx.profileinstaller will be added, to aid local verification and backwards compatibility.

From here, all you need to do is execute the Generate Baseline Profile run configuration, which runs included Baseline Profile generators and copies the generated profiles to src/release/generated/baselineProfile.

The run configuration calls the :app:generateBaselineProfile task, looks for all Baseline Profiles generators and only runs these.

The BaselineProfileGenerator is very basic and does only start your app and wait for the app startup to complete. We recommend creating a Baseline Profile for each critical user journey through your app. As user journeys vary between apps, it’s up to you to decide what to optimize. A good starting point is anything that’s directly tied to business results, such as sign up, login, checkout or other major actions your app offers. You can get inspiration from our code samples.

To get started, download Android Studio Hedgehog Canary today.

And for a guided tour through the whole onboarding process check out the updated codelab: Improve app performance with Baseline Profiles.

Introducing Startup Profiles and Dex layout optimizations

Starting with version 8.1, the Android Gradle Plugin (AGP) can pull code that’s required for app startup into the primary dex file of your app. This optimization is called dex layout optimization and helps to reduce dex page faults during app startup. This can significantly speed up app startup as only a single dex file needs to be loaded until the app has completed startup.

While AGP can create separate dex files for your app, it doesn’t know what fully defines startup for your app without your help. This is where Startup Profiles come in. You can think of Startup Profiles as a subset of Baseline Profiles that are specifically tailored to app startup. Both share the same format and use the same underlying technology. Since app startup differs for every application, libraries do not contribute to the Startup Profile.

Baseline Profiles provide performance gains of around 30 %, compared to an app that requires interpretation and JIT compilation, for example right after an update is pushed. Our early tests with Dex layout optimizations have shown an additional 30% performance improvement on top of Baseline Profile gains for app startup. This is especially beneficial since these gains are always seen in cold startups, even if your production app already has a well functioning cloud profile.

To make the most of Dex layout optimizations and Startup Profiles, you need to let the Android Framework know when your app is done with startup. If you don’t do anything, app startup will be considered done when the first frame is drawn. To make sure the Startup Profile contains information up to the point where your user can take over, use the reportFullyDrawn APIs. You can do this via the FullyDrawnReporter or the Compose ReportDrawn APIs. Additionally, you need to define the end point for the startup benchmark at a point where you deem startup complete. Match the call to reportFullyDrawn with what you’re expecting to be displayed on screen at the point where the app is ready to be used.

You can read more about Dex layout optimizations and Startup profiles in the guiding documentation.

New developments in the Macrobenchmark library

The Macrobenchmark library enables you to measure app performance, create baseline profiles and monitor whether changes to your app make a difference to app performance. The 1.2.0 will graduate to a beta release soon. Here are some feature highlights.

Utilizing new Android platform features in benchmarks

From Android 13 and newer you can generate a Baseline Profile with the BaselineProfileRule on non-rooted devices or emulators.

From Android 14 and newer, target apps no longer need to be reinstalled between benchmark runs. This enables apps to save state, such as cache, session state or login tokens between runs. This change removes the need to inject these states manually before benchmarking, which would have required a rooted device.

New APIs

✨ Baseline Profile generation is no longer considered experimental ✨

You can remove the opt-in to experimental API annotation from your code when creating a baseline profile using the collectBaselineProfile method. But if you like to stay on experimental APIs, we have a new API for your consideration.

The newly introduced collectStableBaselineProfile runs and waits until a profile is considered stable for a given amount of iterations. This means that your app’s Baseline Profile will better reflect what’s going on in your app as a code path is executed.

More powerful metrics with custom trace processing

PerfettoTraceRule enables custom trace collection in tests other than benchmarks (requires API 23+). This is a powerful feature that will allow users to collect performance and timing data about tests.

PerfettoTraceProcessor enables querying trace contents, and is the engine behind all of the existing Macrobenchmark Metric APIs. Now it’s possible to use it with TraceMetric to define fully custom metrics in the same way Macrobenchmark does from anything information in a Perfetto system trace.. This is another powerful feature that will allow users to customize their benchmarks even further.

Attributing Power consumption from benchmarks

The new PowerMetric API can be used to measure energy consumption and power states. This is a useful feature that will allow users to track the energy consumption of their benchmarks.

Bug fixes and other improvements

The team behind Macrobenchmark also made a variety of other improvements to ergonomics, fixed bugs and improved overall behavior. To learn more, check out the documentation. If you want to get more detail, you can find a full list of release notes with attached code and tracking issues here.

Android Studio Power Profiler

Android Studio Hedgehog features a new Profiler which shows power consumption on physical devices, segmented by each sub-system (such as: Camera, GPS, and more). This data is made available when recording a System Trace and helps you to visually correlate power consumption of the device to the actions happening in your app. For example, you can A/B test batching API calls vs making individual API calls to optimize power consumption in the Cellular power rail.

To get started, use a Pixel 6+ device to record a System trace and load it into Android Studio, or use the profiler to capture a System trace directly from the attached device.

Why you should focus on performance

When working on application performance, finding the right starting point can be a challenge. Working with the Android developer community, we found that engineers sometimes lack the right information to justify working on app performance.

Improving performance has a number of benefits, both for your users and for your business. For users, a fast and responsive app means a better user experience. Your users will be able to get the information they need quickly and easily, and they’ll be more likely to come back to your app.

For your business, improved performance can lead to increased revenue and decreased costs. When users are happy with your app, they’re more likely to make purchases or take other actions that benefit your business. Additionally, a well-performing app can help you save money on development and maintenance costs.

Next steps

1. Set your app up to use Baseline Profiles with the new Gradle plugin
2. Upgrade to Android Gradle Plugin 8+
3. Move existing Baseline Profiles into the new default directory src/main/baselineProfiles/
4. Download the Android Studio Hedgehog Canary to check out the Baseline Profile template and power profiler
5. Check out our updated codelab for a guided tour
6. Use the Fully Drawn and collectStableBaselineProfile APIs for better Baseline Profiles
7. Get started with Dex layout optimizations for even more performance gains
8. Implement your own Macrobenchmark tests to measure how performance moves over time
9. Record a System trace on a Pixel 6+ device to view power consumption of different subsystems (Camera, GPS, CPU, etc)
10. 👏 and share this article to help improve app performance for everyone

What’s new in Android Performance — Google I/O 2023 edition was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

MAD Skills Performance — Wrap Up

In August the MAD Skills video and blog series helping you to get started with Performance. Here’s the gist of what happened.

Setting the scene

When Introducing the MAD Skills series on Performance, we shared the model which we’re using to work with performance.

Our guidance is aligned with the three pillars: Inspect, Improve, Monitor.

This alignment and restructuring of our documentation helps to improve developer experience and make working with performance more approachable, especially for developers that are not very familiar with the area.

You can find the updated guides and documentation on d.android.com/performance.

The full story

Introducing the MAD Skills series on Performance

Important Performance Metrics

Here we cover important performance metrics around app startup and frame rate metrics, which bring in important data points for the remainder of the series.

The episode contains introductions to cold, warm and hot start, time to initial display and time to full display. It also covers why it’s important to keep work off the main thread and what frame rates to optimize for.

The full story

Important Performance Metrics

Inspecting Performance

Tomáš Mlynarič introduces you to tools and methods that help with your code’s performance.

When you inspect performance you make sure that what’s happening in your app aligns with what you expect to happen.

We introduce different ways to inspect performance, from passive, through manual and finally automated.

A key takeaway from this episode is that you always should inspect performance with a release build and on a real device.

The full story

Inspecting Performance

Improving Performance with Baseline Profiles

Baseline Profiles help your app to start and run faster by optimizing critical code paths ahead of time. This allows for a smoother user experience.

This episode contains all the info to get you going with Baseline Profiles in a nutshell. First you’ll learn what a Baseline Profile is, how it improves app and library performance. Then Tomáš Mlynarič shows you how to generate a baseline profile and how to measure the impact a new profile has on your app.

The full story

Improving Performance with Baseline Profiles

To get more detailed code, check out the samples on GitHub or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands-on guidance through the topic.

Monitoring App Performance

This episode is guiding you through best practices and provides guidance on tools that can be used to monitor app performance.

Performance can be monitored in a development environment or lab or in the field. We’re sharing best practices and tools to monitor your app’s performance.

Monitoring helps you to verify that performance moves in the right direction.

The full story

Monitoring App Performance

The Q&A session

On September 1st, we hosted a live streamed Q&A session with Carmen Jackson, Chris Craik, Tomáš Mlynarič and Ben Weiss.

During the hour-long stream we went over many questions on performance. You can re-watch the stream any time. The article will be published over the next days as well.

The full story

The Article will be added here once the article is published.

What to do now

Read our updated developer guidance on performance: https://d.android.com/performance

Create a Baseline Profile for your app to improve startup and runtime performance.

If you haven’t done so yet, check out the samples on GitHub or take the Macrobenchmarking Codelab or Baseline Profiles Codelab.

To keep up to date on Android Performance, follow @AndroidDev, @keyboardsurfer and @mlykotom on Twitter.

And keep an eye out for new MAD Skills episodes.

MAD Skills Performance — Wrap Up was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this MAD Skills article on monitoring performance I’m guiding you through best practices and provide guidance on tools that can be used to monitor app performance.

Monitoring performance verifies performance moves in the right direction.

App performance can either be monitored in a lab environment, before the app is released and in the field, when users have installed and actively use an app.

The content in this article is also available as recording on YouTube

Lab Monitoring

Performance data gathered here is invaluable, because you can learn how an app performs before it hits users. This helps you limit possible business impact and overall impact on users. Data gathered in the lab can be used as a Go/No-Go signal. If performance metrics worsen between release you can use these as justification to postpone a release or block shipping a feature.

Continuous Integration

You can also have fast turnaround time thanks to continuous integration (CI). There are various CI servers and services available and I won’t compare them here.

By using a CI pipeline you can kick off a benchmark suite every time a commit lands onto a release branch, or maybe even before it gets merged onto your main branch. This way you can compare performance between releases and raise a red flag in case the metrics are above the threshold you decided on.

Make sure to run benchmarks on real devices. Instead of maintaining your own local device pool for testing, you can use a provider that offers testing on physical devices such as Firebase Test Lab.

Firebase Test Lab keeps devices connected and up to date so you don’t have to invest in your local test device setup. You can use the scripting interface to run benchmarks on every build and continuously see results.

Step Fitting

Whether you choose to run benchmarks on local devices or with a cloud provider, spotting regressions can be tricky at times. To automate reporting you have to set thresholds for each metric that you deem important and then compare it to a previously run benchmark. You will see performance fluctuate. Some builds might complete faster and some slower. Spotting whether an increase in runtime for a benchmark is a regression in your code requires you to compare more than two builds.

Within our public AndroidX Continuous Integration pipeline we have faced this problem in the past and came up with a viable solution to it.

Instead of comparing a single build to the previous one, we accumulate a set number of builds and compare builds before and after a change has landed in the codebase.

While this might take a handful of builds to spot a regression, the approach is very reliable and scales well, even with hundreds of libraries and engineers involved.

In his article on fighting regressions with benchmarks, Chris Craik describes exactly how step fitting works in our code base and how you can integrate it into your continuous integration pipeline.

The short version is:

• Write macrobenchmark tests
• Run them on real devices
• Collect and store the output metrics
• Run the step fitting algorithm

You can read all the details about step fitting in this article

Fighting Regressions with Benchmarks in CI

Field Monitoring

You can monitor your app’s performance once your users have started using it, with field monitoring in production.

Android Vitals

The easiest way to monitor production metrics is by looking at the data Android Vitals provides. Android Vitals offers anonymized and aggregated data over your installed user base, along with peer benchmarks so you can compare your app with others. To use Android Vitals, you don’t need to make any changes to your app’s code whatsoever. Simply upload it onto the Google Play Store and we’ll take care of the rest.

Android Vitals provides you with metrics on

• App Startup Time
• Slow and Frozen Frames
• Unresponsive Activities
• Crashes
• and more

You can compare how your app is doing in different device categories such as Android operating system version, available RAM, CPU speed and others.

It’s valuable to periodically check-in on the data provided by Android Vitals to see what could be improved.

Firebase Performance Monitoring

And if you want more details, Firebase Performance Monitoring has you covered.

By adding the gradle plugin to your app, you can see information about cold start times, the rough source of slow and janky frames, and network request durations. All of this data is reported into the Firebase Console.

plugins {
  id(...)
  id("com.google.firebase.firebase-perf") version "$version"
}

And you can get even more specific data using Firebase Performance Monitoring. Begin by adding the library dependency.

dependencies {
  implementation("com.google.firebase:firebase-perf")
}

Then, you can add your own trace points for any code within your app. Here we trace when data is loaded.

Firebase.performance.newTrace(LOAD_DATA).trace {
  loadRemote()
  loadFromCache()
}

By using the Kotlin extension trace function, the call site for loading data can be wrapped. This is a quick way to span multiple method calls.

Alternatively, you can use the AddTrace annotation on a method. This provides you with a way to trace a single method every time it is called and then report it to the Firebase Console.

@AddTrace(name = "loadRemote", enabled = true)
private fun loadRemote() { ... }

We are continuously expanding our suite of Jetpack libraries related to performance.

JankStats

We have released the JankStats library that enables gathering janky frames alongside metadata such as how the user got to the state where a frame had to be dropped. After you add the dependency to your app’s build file, install JankStats into an activity window by calling createAndTrack.

override fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
    JankStats.createAndTrack(window) { frameData ->
    if (frameData.isJank) {
      logAndAddToReportingQueue()
    }
  }
}

When a frame is considered to be janky by the libraries heuristic, you can log it and add it to your reporting queue.

JankStats holds on to state for you in a PerformanceMetricsState object.

PerformanceMetricsState.getHolderForHierarchy(localView)

Here you can add and remove state in key value pairs.

metricsHolder.state?.putState(
  "Interests:TabState",
  "${tabState.currentIndex}"
)
metricsHolder.state?.removeState(“Interests:TabState”)

This enables you to add metadata such as navigation destinations, which make it easier for you to reproduce how the user reached the janky frame in the first place.

To see more usage of JankStats in action, check out the Now in Android sample, where we have added jank tracking code to key areas such as scrolling through the authors list or the for you page.

That’s all folks

This concludes our second MAD Skills series on Performance. We have shown you important performance metrics and how to inspect, improve and monitor app and library performance around app startup and smooth runtime experiences.

If you haven’t already, go and create a Baseline Profile for your app. It’s a quick way to make your app run faster and smoother.

We’re aware that there’s much more to cover when talking about performance. And while we didn’t have time to cover everything in this series we continue to add more content to our developer guidance and samples.

Also, make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance in our Q&A session on Sept 1st.

And check out our previous MAD Skills series on performance debugging to get an edge on how you can inspect what’s going on in your code.

Go and check out our improved developer documentation, which we have been updating with MAD guidance.

To get more detailed code, check out the samples on GitHub. And take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands-on guidance through the topics.

Monitoring App Performance was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this MAD Skills article on improving performance with Baseline Profiles you’ll learn what Baseline Profiles are and how they can be used to improve app startup and speed up runtime.

Baseline Profiles help your app to start and run faster by optimizing critical code paths ahead of time. This allows for a smoother user experience.

We have seen significant app launch and runtime improvements thanks to using Baseline Profiles. You can read on how Google Maps improved their app launch time by up to 40 % after introducing Baseline Profiles.

You can watch the accompanying video to this article here.

Baseline Profiles in a nutshell

Baseline Profiles are a list of classes and methods that are ahead of time compiled and installed with your app. This means that your code does not need to be interpreted using the just-in-time (JIT) compiler when the app is used. This translates into startup time improvements, reduced jank, and overall improved runtime performance for end users.

Baseline Profiles can be generated for applications and bundled with the app that’s being shipped to users. But also libraries can create their own Baseline Profile and ship it with their AAR. The Baseline Profiles from libraries will be merged into an application’s Baseline Profile and then compiled into a single file, which is shipped with the app itself.

To speed up the development process, Baseline Profiles are not installed for debug builds but only for release builds. So, to see the performance gains of your profile, always verify it against a release build.

Always verify performance gains in a release build.

Jetpack Compose is a popular example for a library that provides a Baseline Profile. By offering library consumers this profile, Jetpack Compose can minimize the impact of being an unbundled UI toolkit for release builds of an app.

Generating a Baseline Profile

The Macrobenchmark library comes with a rule to generate Baseline Profiles for you. By using UIAutomator you can drive the profile generator through an app’s critical user journeys. The API calls made in the app will be captured and integrated into the Baseline Profile which the Macrobenchmark library creates.

The minimum viable setup for a baseline profile generator looks like this.
Below code will generate a baseline profile for you and you can implement clickThroughUserJourney() to guide the generator to more complex scenarios.

@ExperimentalBaselineProfilesApi
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
    @get:Rule
    val baselineProfileRule = BaselineProfileRule()

    @Test
    fun startup() = baselineProfileRule.collectBaselineProfile(
        packageName = "com.example.app"
    ) {
        pressHome()
        startActivityAndWait()
        clickThroughUserJourney()
    }
}

You can see a how a trivial Baseline Profile generator is set up in our sample app on GitHub. And the Now in Android sample app has a more complex Baseline Profile setup.

To learn more about the Macrobenchmark library and how to set up a benchmark, read the previous article in this series, or watch the video.

Inspecting Performance

The codelab to create a Baseline Profile guides you through the latest best practices to get started and leaves you with a first Baseline Profile.

While you wait for the next article

The next article is all about monitoring app performance.

Go and check out our improved developer documentation, which we have been updating with MAD guidance.

To get more detailed code, check out the samples on GitHub or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands-on guidance through the topics.

Make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance in our Q&A session on Sept 1st

And check out the full MAD Skills series on performance debugging to get an edge on how you can inspect what’s going on in your code.

Improving Performance with Baseline Profiles was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

This MAD Skills article on inspecting performance introduces you to tools and methods that help when your code’s performance. When you inspect performance you make sure that what’s happening in your app aligns with what you expect to happen.

You can also watch this article as a MAD Skills video.

Inspecting performance is ensuring that what’s happening in your app aligns with your expectations.

We’re differentiating performance inspection in three stages: Passive, manual and automated. Each has its own place to shine and reason to be used.

Passive performance inspection

When we speak of passive performance inspection, we mean that there’s no extra work necessary to spot a performance problem, other than running it and looking at the existing output. Some problems, such as frozen frames and slow behavior can be seen when interacting with the app directly. This can help you find areas to improve your app, especially when running your app on a device with low specs such as CPU power or RAM.

Next to running the app and evaluating jank directly on screen, you can use logcat to check for slow and dropped frames, which are logged automatically for you.

Slow frames

Use the new Logcat in Android Studio to filter for the Choreographer tag and you can see dropped frames while running the app. As soon as more than 30 frames have been skipped, it’ll be logged.

Frozen frames

Frames which take longer than 700ms to render will be logged with the OpenGLRenderer tag and some more detailed information.

Non-responsive Activity

And if your app is unresponsive for more than 5 seconds, you’ll see the Activity Non-Responsive (ANR) dialog.

App launches

You can also see app launch durations in logcat, by filtering for the ActivityTaskManager tag.

Time to Initial Display (TTID) will be logged with Displayed.

Time to Full Display (TTFD) is logged with Fully Drawn.

App launch times of less than 500 ms (0.5 seconds) are desirable, as users perceive longer launch durations negatively.

You can read more about these metrics in the previous article on MAD Skills Performance Metrics.

Important Performance Metrics

Passive inspection is a great starting point to see if there are problems and can help you to roughly point in the right direction of a problem. To actually qualify which part of an app caused the problem, passive inspection rarely is enough. You’ll need to inspect your app’s code actively.

Manual performance inspection

When you have a rough understanding which parts of an app are not performing as you expect, it’s time to manually inspect what’s going on in depth. Android Studio ships with a suite of profilers which are ready to help you inspect what’s going on in your app.

Android Studio’s Profilers have parallels to the Debugger. What the Debugger is for stepping through code, looking at parameter and property values, the Profiler is for inspecting CPU, Memory, Network usage as well as possible sources of Jank.

The Profiler helps you get a detailed understanding of where a problem occurs.

And while you are developing an app, the debugger allows you to attach to an app during development and inspect problems in depth, using builds that are debuggable is most likely giving wrong performance data.

Always inspect release builds on real devices

Debuggable builds provide many features useful for development, like live edit, applying changes without reinstalling the app, or inspecting property values, changing data and otherwise using Android Studio’s debugging capabilities.

Builds that are marked as debuggable also add a performance overhead to your app. This makes performance metrics unreliable. Something that might look performing poorly on a debuggable build, actually can work well on a release build.

To verify whether a performance issue exists in a production environment or only during development, make sure to verify it on a release build release version of your app.

Set your build variant to release by switching the Build Variant to your most production like build. The Now in Android sample uses `prodRelease` for this.

Also, in your AndroidManifest.xml, mark the application as profileable. This allows profilers to inspect what’s going on in a production build.

<!--AndroidManifest.xml-->

<manifest...
  <application...
    <profileable android:shell=”true” tools:targetApi=”q” /
  </application>
</manifest>

You need to inspect release builds on a physical device.

The Android Emulator has come a long way. It boots quickly, runs smoothly and provides a seamless experience during app development. But when it comes to measuring performance, the Android Emulator is not the right tool.

When you inspect performance on an Emulator, you’re not measuring against an Android device with physical constraints but against the host machine’s capabilities. If a host system is under heavy load, the inspected app will be less performant.

Inspecting performance on a physical device will provide you with consistently useful data.

More MAD Skills on manual performance inspection

Because manual inspection of performance is a full topic on its own, we produced an entire series which aims at helping you to get a deep understanding on manual performance debugging. You can check it out here.

Automated performance inspection

Passive and manual inspection are important steps when inspecting performance. The third way to inspect performance, and likely the most reliable one to give you consistent results, is automated performance inspection. With automated performance inspection, you can reliably run the same steps in a flow time after time.

Automated inspection can help prevent a performance issue before it is shipped to your users.

And while the automation process takes a little setup, you get peace of mind when it comes to ensuring your app’s performance is consistent. We provide the Jetpack Macrobenchmark library to help you automate performance inspection. This library allows you to automate inspecting performance of entire user flows. When using the Jetpack Macrobenchmark library, you can measure key metrics such as app startup, frame timing, and other performance metrics.

Getting Started with Jetpack Macrobenchmark

All you need to get started with Jetpack Macrobenchmark is a recent version of Android Studio. We recently released a codelab that guides you through the process of creating and running your first Macrobenchmark.

Also, the overall guidance on how to create a Macrobenchmark gives you the latest instruction on getting started.

While you wait for the next article

In the next article we’ll introduce you to a fast way to improve your app’s performance with Baseline Profiles.

Go and check out our improved developer documentation, which we have been updating with MAD guidance.

To get more hands on, check out the samples on GitHub.

Or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands on guidance through the topics.

Also, make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance.

Inspecting Performance was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before you begin to work with performance effectively, we recommend you make yourself familiar with key performance metrics. By understanding what metrics you should look at, you will make inspecting, improving and monitoring performance easier.

This MAD Skills article on important performance metrics will introduce you to startup and frame rate metrics and bring in important data points for the rest of this series on performance. App startup and creating a smooth user experience have shown to have a lasting impact on user satisfaction and applications’ individual business metrics, which is why we have chosen these areas as focal points for this article.

Later in this series we have tools and libraries lined up to make it easier for you to inspect, improve, and monitor performance.

You can watch the accompanying video to this article here.

Startup phases

Application startups are the first point of interaction with your user. Making a lasting and positive first impression is even more important at scale. So your goal is to make the app startup as fast, seamless and smooth as possible.

App startup can be measured in three phases: Cold, warm and hot start.

The startup phase is determined by the current state of your app.

Cold start

A cold start begins when the application’s process is created. This is what users experience when they install your app and then launch it for the first time, launch the app after restarting their device or restart the app after the system has completely stopped it for one reason or another.

During a cold start, Application.onCreate() is called. Everything your app needs to get started is loaded from disk. When a cold start begins, memory caches are empty as well. Cold starts are the slowest startup type, because they start at process creation and end at the same time a hot start finishes. To experience a cold start of your app, force-close it and then open it again from the launcher.

Cold starts should be faster than 500 milliseconds.

When a cold start takes longer than 500 milliseconds, your users are going to notice and might get increasingly impatient and might decide to move away from your app. So keeping cold starts as fast as possible is extremely important.

Warm start

A warm start is measured from the point when Activity.onCreate() is called, just before your view hierarchy is inflated.

At this point, some resources are already inflated and memory caches warmed up.

Warm starts usually take place when you open an app after the activity was destroyed, but the app’s process is still running.

This could happen if an app has been running in the background for a while, but not long enough for the system to kill the entire process. Also, whenever an orientation change forces the activity to be destroyed and re-created, that’s a warm start.

Hot start

The final and shortest app startup type is called hot start. During a hot start, an app that is running, such an activity that was paused, becomes visible to the user and enters the started state.

Here the first frame is ready to be drawn and Activity.onStart() is called. A hot start can happen when you’re switching back and forth between apps.

Due to the nature of startup types, a cold start takes the most time. Warm and hot starts will be shorter.

All three startup types, cold, warm and hot, are measured from their corresponding starting point to at least one of two end states.

Startup end states

Time to Initial Display

The default app startup end state is called Time to Initial Display. Or TTID for short. It is automatically reported when the first frame of your application is ready to be drawn.

You can also see TTID by opening logcat and looking for the ActivityTaskManager tag with value Displayed. It will tell you how much time it took to display a specific activity. Because this is reported automatically, there’s nothing for you to configure. Every app is reporting this by default.

Time to Full Display

While time to initial display is reported automatically, the next state can be customized. It is called time to full display, or TTFD. Time to full display is an optional metric that Android can use to further optimize your app’s startup time. It is also used when running startup benchmarks on your app.

TTFD is also visible in logcat with the ActivityTaskManager tag. Look for ActivityTaskManager: Fully drawn.

You should report time to full display when everything is drawn on screen, and the data required for the user to interact with the app is available.

The API to use is Activity’s reportFullyDrawn()

reportFullyDrawn is not tied to an Activity lifecycle method and you must pick the right time to call the API that makes sense for your app.

And while it’s important to call the method around the time your app is ready to be used, being absolutely precise on a frame level is not required.

The Now in Android sample app is considered to be fully drawn when both the interests and feed have been loaded.

Once these two states are met, we call reportFullyDrawn when the current local view is ready to be drawn. You can check out the code in more detail on GitHub.

Frame Timing Metrics

Making sure you don’t drop frames is very important for a smooth user experience. Most frames aren’t dropped in a static state but when the user is scrolling or you’re otherwise animating content. If an app is doing too much work on the main thread to meet the frame timing window, slow and frozen frames are the result.

We call this behavior Jank. Jank can be extremely frustrating so it’s important to know how to avoid it.

Frame rates

The screen can be drawn many times per second. The amount of re-draws per second is called frame rate.

Historically, Android devices came with a refresh rate of 60 frames per second. That gives your app 1/60th of a second to perform work on the main thread before a frame will be delayed or eventually has to be dropped. More recently, the frame rates have increased to 90 and even 120 frames per second.

And devices can also switch between different frame rates depending on a user’s choice, the developer’s decision, or even the device’s power or thermal state.

Within our Modern Android Development guides, we recommend you optimize for a frame rate of at least 90 frames per second. This means all the work in between frames has to fit in a window of less than 11.1 milliseconds. And that’s very, very little time.

A great way to achieve a high frame rate is to keep as much work as possible off the main thread.

While you wait

In the next article we’ll introduce you to inspecting performance issues in detail.

Also, make sure to check out our full MAD Skills series on performance debugging to get an edge on how you can inspect what’s going on in your code.

Go and check out our improved developer documentation, which we have been updating with MAD guidance.

To get more hands on, check out the samples on GitHub.

Or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands on guidance through the topics.

Also, make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance.

Important Performance Metrics was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Performance spans every aspect of Android development, and as part of Modern Android Development we’re aiming to make it more approachable and user-friendly. We have also found direct correlations between improved app performance, user satisfaction and business metrics.

So, it’s time for another series of MAD Skills on Performance.

We are going to release episodes throughout August, ending with a live Q&A session on YouTube with Engineers working on Android Performance.

Read on and follow this series to learn about Modern Android Performance. Next to articles we’re also publishing videos, the first of which is available here.

Here’s what’s in the pipeline

In this series we’re going to introduce you to metrics that are important when working with performance. We’ll use these metrics and introduce you to tools, libraries and best practices that help you inspect, improve and monitor your app’s startup time and provide a smooth user experience.

We’ll share how to create and use Baseline Profiles.

This new technology has already helped several top partners improve their app startup time by an average of 30 percent. Using Baseline Profiles enables Ahead Of Time compilation of critical user journeys and provides improved runtime experience on top of startup speed improvements.

Baseline profiles are production ready and can help your code run faster as well.

Check out the Now in Android and Performance Samples to see how to set up a Baseline Profile. You can also follow the new Baseline Profiles Codelab to get a guided path to creating your own.

We will also cover new developments in Android Studio profilers, how the Jetpack Macrobenchmark library helps you to keep track of your app’s performance, and introduce you to more libraries and products that help you monitor your code’s performance during development and in production.

We’ll show you how to use Firebase Performance Monitoring and how Android Vitals helps you to stay on top of field metrics. And we’ll give you a sneak peek into gathering jank metrics with the new JankStats library.

Modern mental model for Performance

We made our guidance more approachable by introducing a new mental model for performance. All of our guidance is now aligned with three pillars:

• Inspect
• Improve
• Monitor

These pillars provide you with a structured approach to performance in a closed feedback loop.

Inspecting Performance helps you understand what’s going on in your app.

With that you can see what’s happening in your app and how that aligns with what you expect to happen.

The Improving Performance pillar consists of tools, libraries, and guidance to help your code gain a performance boost.

When Monitoring Performance, you’re able to verify whether implemented improvements are actually making performance metrics move in the right direction.

It can also give you more data for the next inspection cycle.

There’s more

Performance metrics can include more than just improving App Startup, and creating a smooth, jank free experience.

Reducing battery drain, being smart about data usage and caching, decreasing application size, and creating an overall crash free experience are also important when working with performance.

And while we won’t cover all of these areas in this MAD Skills series, you can find detailed information in our developer guides, which we update regularly.

Partner Success Stories

We have seen time and time again, working with key partners, that improving your app’s performance has a direct impact on user retention, better ratings, and improved business metrics.

Zomato has seen an average of 30 % startup speed improvement and found improving app performance to be a key business growth recipe.
Read the story here.

Google Maps has used Baseline Profiles to improve their app startup and runtime by up to 40 %, which in turn improved searches by over 2 %.
Here’s the full story.

While you wait

Make sure to check out our full MADSKills series on performance debugging to get an edge on how you can inspect what’s going on in your code.

Also, our improved developer documentation has been updated recently, so go and check it out.

Check out the samples on GitHub or take the Macrobenchmarking Codelab or Baseline Profiles Codelab for hands on guidance through the topics.

Also, make sure to ask your questions in the video comments or on Twitter, using #MADPerfQA to get answers directly from the Engineers working on Android Performance.

Introducing the MAD Skills series on Performance was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using WorkManager in multi-process apps

📝 The recent release of WorkManager 2.5.0 enables easier usage in a multi-process environment and provides several stability improvements.

So if you have an app that manages multiple processes, and you need a robust way to manage background work (no more initialization errors ️️⚠), then this is the release for you.

There are a few changes you’ll need to make to your code, so read on to find out more.

At the end of this article I’ll also list some other behavior changes and newest additions in this version of the WorkManager library.

Introducing: work-multiprocess

The new multiprocess artifact introduces performance gains by unifying job scheduling to a single process. To get started, add it to your app.

Implementation "androidx.work:work-multiprocess:2.5.0"

You can now choose the designated process that WorkManager uses to enqueue WorkRequests, and run its in-process scheduler.

A configuration using Configuration.Provider can look like this.

class MyApplication() : Application(), Configuration.Provider {  override fun getWorkManagerConfiguration() =
    Configuration.Builder()
      .setDefaultProcessName("com.example:remote")
      .build()
}

Note: The parameter on setProcessName requires you to pass the fully qualified process name, consisting of your app’s package name, followed by a colon and then the host’s process name, e.g. com.example:remote.

When using work-multiprocess you also want to use RemoteWorkManager instead of WorkManager to manage your work requests. RemoteWorkManager will always reach out to the designated process to enqueue work for you. This ensures that you don’t accidentally initialize a new WorkManager in the calling process. The In-process scheduler also runs in the same designated process.

Benefits

With WorkManager configured like this and using RemoteWorkManager to schedule your jobs, you can enjoy your work being managed faster and more reliably in your multi-process app. This is because SQLite contention can be vastly reduced (because we no longer rely on file based locks) and job reconciliation across processes won’t be necessary any longer since your app will only have a single WorkManager instance running in a process that you can designate.

Behavior changes 🔀

Job reconciliation

Previously, when ActivityManager couldn’t instantiate the JobService to start a job, that job would get dropped silently because of an underlying bug in the platform. WorkManager now ensures that there is a backing scheduler job for every single WorkRequest when an Application instance is created by reconciling WorkRequest objects with jobs.

Limit internal database growth

We saw that one of the causes of app crashes was that the device ran out of storage. This happened mainly on devices that had low storage in the first place. However, when apps scheduled a lot of work, WorkManager was partially responsible for the device running low on storage.

Completed jobs were recorded in an internal WorkManager database for 7 days by default. This time has been reduced to 1 day, which dramatically reduces the database size.

While we shortened the buffer duration, you can control how long your job should be remembered by using the keepResultsForAtLeast() API.

New testing API ✨

If you’re using ListenableFuture with WorkManager, then testing got easier — the TestListenableWorkerBuilder Kotlin extension now takes in any class extending ListenableWorker, providing you with more flexibility during testing.

Bug fixes 🐛

In addition to new features, this release also contains several bug fixes that improve the stability, reliability, and performance of WorkManager. You can read up on all changes as well as fixed bugs in the release notes.

What you can do to improve WorkManager

Contribute to WorkManager through GitHub 👩‍💻

WorkManager, as well as several other Jetpack libraries, can accept contributions via GitHub.

Alan Viverette wrote a comprehensive blog post about the entire process.

Let us know when something goes wrong 📝

Most of the bugs fixed in the 2.5.0 release came in through input from the public issue tracker.

The best way to create an issue we can fix is by creating an issue we can reproduce. To help us reproduce an issue, we recommend that you use the WorkManager sample or provide your own sample code with instructions in the issue description.

Now is the right time to get to work and manage updating that library version in your app.

WorkManager 2.5.0 stable released was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.