Tag Archives: Background work

Boost app performance and battery life: New Android Vitals Metrics are here

Posted by Karan Jhavar - Product Manager, Android Frameworks, and Dan Brown - Product Manager, Google Play

Android has long championed performance, continuously evolving to deliver exceptional user experiences. Building upon years of refinement, we're now focusing on pinpointing resource-intensive use cases and developing platform-level solutions that benefit all users, across the vast Android ecosystem.

Since the launch of Android vitals in Play Console in 2017, Play has been investing in providing fleet-wide visibility into performance issues, making it easier to identify and fix problems as they occur. Today, Android and Google Play are taking a significant step forward in partnership with top OEMs, like Samsung, leveraging their real-world insights into excessive resource consumption. Our shared goal is to make Android development more streamlined and consistent by providing a standardized definition of what good and great looks like when it comes to technical quality.

"Samsung is excited to collaborate with Android and Google Play on these new performance metrics. By sharing our user experience insights, we aim to help developers build truly optimized apps that deliver exceptional performance and battery life across the ecosystem. We believe this collaboration will lead to a more consistent and positive experience for all Android users."
Samsung

We're embarking on a multi-year plan to empower you with the tools and data you need to understand, diagnose, and improve your app's resource consumption, resulting in happier and more engaged users, both for your app, and Android as a whole.

Today, we're launching the first of these new metrics in beta: excessive wake locks. This metric directly addresses one of the most significant frustrations for Android users – excessive battery drain. By optimizing your app's wake lock behavior, you can significantly enhance battery life and user satisfaction.

The Android vitals beta metric reports partial wake lock use as excessive when all of the partial wake locks, added together, run for more than 3 hours in a 24-hour period. The current iteration of excessive wake lock metrics tracks time only if the wake lock is held when the app is in the background and does not have a foreground service.

These new metrics will provide comprehensive, fleet-wide visibility into performance and battery life, equipping developers with the data needed to diagnose and resolve performance bottlenecks. We have also revamped our wake lock documentation which shares effective wake lock implementation strategies and best practices.

In addition, we are also launching the excessive wake lock metric documentation to provide clear guidance on interpreting the metrics. We highly encourage developers to check out this page and provide feedback with their use case on this new metric. Your input is invaluable in refining these metrics before their general availability. In this beta phase, we're actively seeking feedback on the metric definition and how it aligns with your app's use cases. Once we reach general availability, we will explore Play Store treatments to help users choose apps that meet their needs.

Later this year, we may introduce additional metrics in Android vitals highlighting additional critical performance issues.

Thank you for your ongoing commitment to delivering delightful, fast, and high-performance experiences to users across the entire Android ecosystem.

Google Maps improved download reliability by 10% using user initiated data transfer API

Posted by Alice Yuan – Developer Relations Engineer, in collaboration with Software Engineers – Matthew Valgenti and Emma Li – at Google

What is user initiated data transfer?

In Android 14 we introduced user-initiated data transfer jobs, or UIDT. You can use the new API setUserInitiated in JobScheduler to specify that the job is a user-initiated data transfer job. This API is helpful for use cases that require long-duration (>10 minutes), user-initiated transfer of data over network. UIDT is also an alternative API to using a dataSync foreground service, which has new timeout behavior for apps that target Android 15.

UIDT is intended to support user initiated use cases such as downloading files from a remote server, uploading files to a remote server or transferring data between two devices via Wi-Fi transport. Since the release of Android 14, the new API has been adopted by a growing number of Android apps running on hundreds of millions of user devices.


What are the benefits if I adopt user-initiated data transfer?

The Android team’s extensive analysis found gaps in foreground services and WorkManager for long duration, user initiated data transfers. Although WorkManager could support retries and constraints, it could not support long duration work which are often necessary for data transfer operations. Developers also found it challenging to use foreground service, which did not provide an ideal user experience during interruption of network connectivity.

JobScheduler’s user initiated data transfer API helps solve for these gaps by offering developers the following benefits:

    • Long duration, immediate background work execution that is not impacted by existing job quotas based on app standby buckets.
    • Helps improve consistency in API behavior across all devices, and the behavior is enforced through Compatibility Test Suite (CTS).
    • Improved reliability of data transfer compared to using a foreground service as indicated by Google Maps own benchmarks.
    • Support for execution when certain constraints are met, such as running only on Wi-Fi or only when the device is charging.
    • Gracefully manages job timeouts and retries.
    • Reduced memory usage and reduced notification clutter when the app is waiting for constraints to be met.

If you’re looking to do short or interruptible background work, WorkManager is still the recommended solution. Check out data transfer background task options to learn more.

“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!”- Matthew Valgenti, Software Engineer at Google

Google Maps successfully launched UIDT and saw improvement in download reliability!

Google Maps decided to use UIDT for their offline maps download use case. This use case ensures that users are able to download offline maps so they have map data even when they lose network connectivity.

What was Google Maps’ main motivation for adopting UIDT?

Google Maps decided to adopt UIDT to ensure that the download service works with the latest Android releases and continues to be reliable and efficient.

“We implemented several features and optimizations, such as resumable downloads so that if a user's internet connection is interrupted or they exit the app before the download is complete, the download resumes from where it left off when the user returns to the app or their connection is restored.” - Emma Li, Software Engineer at Google

What is the trigger point to start UIDT in Google Maps?

The UIDT is triggered when a user decides to download a map region to have that data offline. When a user hits download, the UIDT is triggered immediately and processing of the region begins as soon as possible.

What were Google Maps’ adoption results?

Google Maps rolled out the project using experiment flags to understand metrics impact after each ramp stage.

“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!- Matthew Valgenti, Software Engineer at Google

How do I get started implementing user initiated data transfer API?

In order to adopt user initiated data transfer, you will need to integrate with the JobScheduler platform API and gate the change to Android 14 or higher.

Check out the following developer documentation to get started with user initiated data transfer:


This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15, which will be updated throughout the week.

Google Maps improved download reliability by 10% using user initiated data transfer API

Posted by Alice Yuan – Developer Relations Engineer, in collaboration with Software Engineers – Matthew Valgenti and Emma Li – at Google

What is user initiated data transfer?

In Android 14 we introduced user-initiated data transfer jobs, or UIDT. You can use the new API setUserInitiated in JobScheduler to specify that the job is a user-initiated data transfer job. This API is helpful for use cases that require long-duration (>10 minutes), user-initiated transfer of data over network. UIDT is also an alternative API to using a dataSync foreground service, which has new timeout behavior for apps that target Android 15.

UIDT is intended to support user initiated use cases such as downloading files from a remote server, uploading files to a remote server or transferring data between two devices via Wi-Fi transport. Since the release of Android 14, the new API has been adopted by a growing number of Android apps running on hundreds of millions of user devices.


What are the benefits if I adopt user-initiated data transfer?

The Android team’s extensive analysis found gaps in foreground services and WorkManager for long duration, user initiated data transfers. Although WorkManager could support retries and constraints, it could not support long duration work which are often necessary for data transfer operations. Developers also found it challenging to use foreground service, which did not provide an ideal user experience during interruption of network connectivity.

JobScheduler’s user initiated data transfer API helps solve for these gaps by offering developers the following benefits:

    • Long duration, immediate background work execution that is not impacted by existing job quotas based on app standby buckets.
    • Helps improve consistency in API behavior across all devices, and the behavior is enforced through Compatibility Test Suite (CTS).
    • Improved reliability of data transfer compared to using a foreground service as indicated by Google Maps own benchmarks.
    • Support for execution when certain constraints are met, such as running only on Wi-Fi or only when the device is charging.
    • Gracefully manages job timeouts and retries.
    • Reduced memory usage and reduced notification clutter when the app is waiting for constraints to be met.

If you’re looking to do short or interruptible background work, WorkManager is still the recommended solution. Check out data transfer background task options to learn more.

“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!”- Matthew Valgenti, Software Engineer at Google

Google Maps successfully launched UIDT and saw improvement in download reliability!

Google Maps decided to use UIDT for their offline maps download use case. This use case ensures that users are able to download offline maps so they have map data even when they lose network connectivity.

What was Google Maps’ main motivation for adopting UIDT?

Google Maps decided to adopt UIDT to ensure that the download service works with the latest Android releases and continues to be reliable and efficient.

“We implemented several features and optimizations, such as resumable downloads so that if a user's internet connection is interrupted or they exit the app before the download is complete, the download resumes from where it left off when the user returns to the app or their connection is restored.” - Emma Li, Software Engineer at Google

What is the trigger point to start UIDT in Google Maps?

The UIDT is triggered when a user decides to download a map region to have that data offline. When a user hits download, the UIDT is triggered immediately and processing of the region begins as soon as possible.

What were Google Maps’ adoption results?

Google Maps rolled out the project using experiment flags to understand metrics impact after each ramp stage.

“We successfully launched UIDT on Android 14 in early 2024 migrating from our foreground service implementation. After a retroactive analysis on Android 14 vs Android 13 implementation, we now see a 10%+ improvement in download failure rate of offline downloads!- Matthew Valgenti, Software Engineer at Google

How do I get started implementing user initiated data transfer API?

In order to adopt user initiated data transfer, you will need to integrate with the JobScheduler platform API and gate the change to Android 14 or higher.

Check out the following developer documentation to get started with user initiated data transfer:


This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15, which will be updated throughout the week.

Improving Consistency of Background Work on Android

Posted by Sanat Kamal Bahl, Product Manager, Android Frameworks

Since its inception, Android has been designed to be the world’s first open and innovative platform for mobile devices.

Today, Android powers a rich and open ecosystem of devices serving billions of users around the world. The openness of the Android platform enables innovation in new mobile form factors like foldable phones. This openness also enables smart features in cars, watches, and televisions. While this openness unlocks great opportunities, with so many unique devices, it can make your life harder as a developer. One such challenge we have heard from the community involves restrictions on foreground services and background work that make it harder for you to create apps that work across different device models.

Looking to solve these consistency challenges, we are announcing deeper partnerships with Android hardware manufacturers to help ensure APIs for background work are supported predictably and consistently across the ecosystem. We are excited to announce that Samsung, representing one of Android’s longest partnerships, is our first partner on this journey:

“To strengthen the Android platform, our collaboration with Google has resulted in a unified policy that we expect will create a more consistent and reliable user experience for Galaxy users. Since One UI 6.0, foreground services of apps targeting Android 14 will be guaranteed to work as intended so long as they are developed according to Android's new foreground service API policy.” - Samsung

As mentioned in the Android 14 Developer Preview 1 blog post, we have:

We believe our expanding partnerships with hardware manufacturers and these changes will make it easier for developers to create apps that work consistently across different Android devices.

We encourage you to try the new Android 14 APIs and let us know what you think using the Android 14 Issue Tracker. We welcome you to contribute to CTS-D tests to help catch consistency issues. Lastly, If you see behavior differences across Android devices, be sure to file a ticket using goo.gle/devicespecificissue to bring it to our attention.