It's not every day that researchers sit down to watch a children's cartoon for science, but that's precisely…

26 Nov 2025 7:30am GMT

Look no further for all the latest Boba Story Lid Recipes. They are all right here!

25 Nov 2025 5:24pm GMT

Get the latest Dice Dreams free rolls links, updated daily! Complete with a guide on how to redeem the links.

25 Nov 2025 5:24pm GMT

Posted by Robbie McLachlan - Developer Marketing

In our latest #WeArePlay film, which celebrates the people behind apps and games on Google Play, we meet Chiharu - a co-founder of Delish Kitchen. She is on a mission to solve one of the most common daily frustrations: "What should I make for dinner?" Discover how this avid baker since her teens combined her passions for food and tech, building an app that delivers 55,000 professional recipes to over 13 million users across Japan.

You went from making websites in middle school to creating one of Japan's leading recipe apps. What inspired that leap and sparked the idea for Delish Kitchen?

I've loved the internet since I was a kid and always dreamed of creating my own online service. After working on mobile games, I discovered the huge potential for video content on mobile. That's when the spark for Delish Kitchen happened. I was working on new services related to food and saw that people were really struggling with deciding what to make every day. I felt this myself when I used to bake as it was difficult to understand recipes from only text and pictures. I wanted to solve that daily problem for people, and I knew video was the way to do it and make their lives happier.

What is the core mission behind Delish Kitchen and how does it make life easier for your users?

The biggest struggle for people who cook every day is deciding what to make. My mission is to solve that problem and make people happier every day. For beginners, we show them that cooking is easier than they thought. For experienced cooks, we make it easy to find what to make today. We have 55,000 recipes, and we also suggest the entire meal, or "KONDATE," so they don't have to think about pairing a main dish with a side.

How has Google Play helped you reach and grow with such a large audience?

We wanted our app to be accessible to as many people as possible, and distributing it on Google Play was very important for reaching the large number of Android users in Japan. To have over 5 million downloads, mostly just in Japan, shows how vital that is. Google Play has been a great partner in our growth because it provides the integrations and tools that help developers grow more efficiently. For us, that means checking all the user reviews to decide on new features, and it also includes feature campaigns that help us reach even more people.

What is next for Delish Kitchen?

We just launched an AI-powered cooking assistant for our premium users. It's designed to answer questions like, "What can I make from leftovers?" or "Can you give me a high-protein recipe under 500 calories?". We are also working on a new app, which will help people record their meals and manage their health and wellness. Beyond apps, we are reaching into offline services by building new partnerships with supermarkets to help people make better food choices in their everyday shopping.

Discover other inspiring app and game founders featured in #WeArePlay.

25 Nov 2025 5:00pm GMT

In a sea of thrillers, true crime, and post-apocalyptic dramas, sometimes you want something that lifts your spirits.…

25 Nov 2025 4:30pm GMT

Save on HONOR's 400 Pro, Magic 7 Pro and Magic V5, with flagship specs & big batteries

25 Nov 2025 3:39pm GMT

Expressive is Google's theme this year, and we've seen it loud and clear in their Material You design.…

25 Nov 2025 12:19pm GMT

OpenAI has quietly stepped back from one of its most ambitious projects: building a tool capable of reliably…

25 Nov 2025 7:30am GMT

Save up to $800 on these awesome Amazon deals before they disappear.

24 Nov 2025 5:03pm GMT

If you've ever lost an afternoon pulling together research for a report, a school project, or a market…

24 Nov 2025 4:30pm GMT

I was in the market for a home treadmill that could actually handle a proper run. My biggest…

24 Nov 2025 9:39am GMT

With electric cars zooming into the mainstream and AI like ChatGPT now part of everyday life, it was…

24 Nov 2025 7:30am GMT

Keep your phone from unexpected falls and have a charging option wrapped around your wrist.

23 Nov 2025 5:04pm GMT

Out of nowhere, a Brazilian crime drama has shot into Netflix's global top 10 - rubbing digital shoulders…

23 Nov 2025 4:30pm GMT

What a relief. No more using third-party apps to send files you can easily send from your phone.

23 Nov 2025 4:03pm GMT

Need to turn a PDF into a Word document without downloading anything or installing sketchy software? If you've…

23 Nov 2025 7:30am GMT

Is your phone always clinging to its last 5% by midday? You're not alone. From clunky cables to…

22 Nov 2025 4:30pm GMT

Posted by Ben Weiss, Senior Developer Relations Engineer and Sara Hamilton, Product Manager

We spent the past week diving deep into sharing best practices and guidance that helps to make Android apps faster, smaller, and more stable. From the foundational powers of the R8 optimizer and Profile Guided Optimizations, to performance improvements with Jetpack Compose, to a new guide on levelling up your app's performance, we've covered the low effort, high impact tools you need to build a performant app.

This post serves as your index and roadmap to revisit these resources whenever you need to optimize. Here are the five key takeaways from our journey together.

Use the R8 optimizer to speed up your app

The single most impactful, low-effort change you can make is fully enabling the R8 optimizer. It doesn't just reduce app size; it performs deep, whole-program optimizations to fundamentally rewrite your code for efficiency. Revisit your Keep Rules and get R8 back into your engineering tasks.

Our newly updated and expanded documentation on the R8 optimizer is here to help.

Reddit observed a 40% faster cold startup and 30% fewer ANR errors after enabling R8 full mode.

You can read the full case study on our blog.

Engineers at Disney+ invest in app performance and are optimizing the app's user experience. Sometimes even seemingly small changes can make a huge impact. While inspecting their R8 configuration, the team found that the -dontoptimize flag was being used. After enabling optimizations by removing this flag, the Disney+ team saw significant improvements in their app's performance.

So next time someone asks you what you could do to improve app performance, just link them to this post.

Read more in our Day 1 blog: Use R8 to shrink, optimize, and fast-track your app

Guiding you to better performance

Baseline Profiles effectively remove the need for Just in Time compilation, improving startup speed, scrolling, animation and overall rendering performance. Startup Profiles make app startup more even more lightweight by bringing an intelligent order to your app's classes.dex files.

And to learn more about just how important Baseline Profiles are for app performance, read Meta's engineering blog where they shared how Baseline Profiles improved various critical performance metrics by up to 40% across their apps.

We continue to make Jetpack Compose more performant for you in Jetpack Compose 1.10. Features like pausable composition and the customizable cache window are crucial for maintaining zero scroll jank when dealing with complex list items.Take a look at the latest episode of #TheAndroidShow where we explain this in more detail.

Read more in our Wednesday's blog: Deeper Performance Considerations

Measuring performance can be easy as 1, 2, 3

You can't manage what you don't measure. Our Performance Leveling Guide breaks down your measurement journey into five steps, starting with easily available data and building up to advanced local tooling.

Starting at level 1, we'll teach you how to use readily available data from Android Vitals, which provides you with field data on ANRs, crashes, and excessive battery usage.

We'll also teach you how to level up. For example, we'll demonstrate how to reach level 3 with local performance testing using Jetpack Macrobenchmark and the new UiAutomator 2.4 API to accurately measure and verify any change in your app's performance.

Read more in our Thursday's blog

Debugging performance just got an upgrade

Advanced optimization shouldn't mean unreadable crash reports. New features are designed to help you confidently debug R8 and background work:

Automatic Logcat Retrace

Starting in Android Studio Narwhal, stack traces can automatically be de-obfuscated in the Logcat window. This way you can immediately see and debug any crashes in a production-ready build.

Narrow Keep Rules

On Tuesday we demystified the Keep Rules needed to fix runtime crashes, emphasizing writing specific, member-level rules over overly-broad wildcards. And because it's an important topic, we made you a video as well.

And with the new lint check for wide Keep Rules, the Android Studio Otter 3 Feature Drop has you covered here as well.

We also released new guidance on testing and troubleshooting your R8 configuration to help you get the configuration right with confidence.

Read more in our Tuesday's blog: Configure and troubleshoot R8 Keep Rules

Background Work

We shared guidance on debugging common scenarios you may encounter when scheduling tasks with WorkManager.

Background Task Inspector gives you a visual representation and graph view of WorkManager tasks, helping debug why scheduled work is delayed or failed. And our refreshed Background Work documentation landing page highlights task-specific APIs that are optimized for particular use cases, helping you achieve more reliable execution.

Read more in our Wednesday's blog: Background work performance considerations

Performance optimization is an ongoing journey

If you successfully took our challenge to enable R8 full mode this week, your next step is to integrate performance into your product roadmap using the App Performance Score. This standardized framework helps you find the highest leverage action items for continuous improvement.

We capped off the week with the #AskAndroid Live Q&A session, where engineers answered your toughest questions on R8, Profile Guided Optimizations, and more. If you missed it, look for the replay!

Thank you for joining us! Now, get building and keep that momentum going.

21 Nov 2025 5:00pm GMT

Posted by Alice Yuan - Senior Developer Relations Engineer

Welcome to day 4 of Performance Spotlight Week. Now that you've learned about some of the awesome tools and best practices we've introduced recently such as the R8 Optimizer, and Profile Guided Optimization with Baseline Profiles and Startup Profiles, you might be wondering where to start your performance improvement journey.

We've come up with a step-by-step performance leveling guide to meet your mobile development team where you are-whether you're an app with a single developer looking to get started with performance, or you have an entire team dedicated to improving Android performance.

The performance leveling guide features 5 levels. We'll start with level 1, which introduces minimal adoption effort performance tooling, and we'll go up to level 5, ideal for apps that have the resourcing to maintain a bespoke performance framework.

Feel free to jump to the level that resonates most with you:

• Level 1: Use Play Console provided field monitoring

• Level 2: Follow the App Performance Score action items

• Level 3: Leverage local performance test frameworks

• Level 4: Use trace analysis tools like Perfetto

• Level 5: Build your own performance tracking framework

Level 1: Use Play Console provided field monitoring

We recommend first leveraging Android vitals within the Play Console for viewing automatically collected field monitoring data, giving you insights about your application with minimal effort.

Android vitals is Google's initiative to automatically collect and surface this field data for you.

Here's an explanation of how we deliver this data:

1. Collect Data: When a user opts-in, their Android device automatically logs key performance and stability events from all apps, including yours.

2. Aggregate Data: Google Play collects and anonymizes this data from your app's users.

3. Surface Insights: The data is presented to you in the Android vitals dashboard within your Google Play Console.

The Android vitals dashboard tracks many metrics, but a few are designated as Core Vitals. These are the most important because they can affect your app's visibility and ranking on the Google Play Store.

The Core Vitals

The core vitals include user-perceived crash rate, ANR rate, excessive battery usage and the newly introduced metric on excessive partial wake locks.

User-Perceived ANR Rate

You can use the Android Vitals ANR dashboard, to see stack traces of issues that occur in the field and get insights and recommendations on how to fix the issue.

You can drill down into a specific ANR that occurred, to see the stack trace as well as insights on what might be causing the issue.

Also, check out our ANR guidance to help you diagnose and fix the common scenarios where ANRs might occur.

User-Perceived Crash Rate

Use the Android vitals crflevelash dashboard to further debug crashes and view a sample of stack traces that occur within your app.

Our documentation also has guidance around troubleshooting specific crashes. For example, the Troubleshoot foreground services guide discusses ways to identify and fix common scenarios where crashes occur.

Excessive Battery Usage

To decrease watch face sessions with excessive battery usage on Wear OS, check out the Wear guide on how to improve and conserve battery.

[new] Excessive Partial Wake Locks

We recently announced that apps that exceed the excessive partial wake locks threshold may see additional treatment starting on March 1st 2026.

For mobile devices, the Android vitals metric applies to non-exempted wake locks acquired while the screen is off and the app is in the background or running a foreground service. Android vitals considers partial wake lock usage excessive if wake locks are held for at least two hours within a 24-hour period and it affects more than 5% of your app's sessions, averaged over 28 days.

To debug and fix excessive wake lock issues, check out our technical blog post.

Consult our Android vitals documentation and continue your journey to better leverage Android vitals.

Level 2: Follow the App Performance Score action items

Next, move onto using the App Performance Score to find the high leverage action items to uplevel your app performance.

The Android App Performance Score is a standardized framework to measure your app's technical performance. It gives you a score between 0 and 100, where a lower number indicates more room for improvement.

To get easy wins, you should first start with the Static Performance Score first. These are often configuration changes or tooling updates that provide significant performance boosts.

Step 1: Perform the Static Assessment

The static assessment evaluates your project's configuration and tooling adoption. These are often the quickest ways to improve performance.

Navigate to the Static Score section of the scoreboard page and do the following:

1. Assess Android Gradle Plugin (AGP) Version.

2. Adopt R8 Minification incrementally or ideally, use R8 in full mode to minify and optimize the app code.

3. Adopt Baseline Profiles which improves code execution speed from the first launch providing performance enhancements for every new app install and every app update.

4. Adopt Startup Profiles to improve Dex Layout. Startup Profiles are used by the build system to further optimize the classes and methods they contain by improving the layout of code in your APK's DEX files.

5. Upgrade to the newest version of Jetpack Compose

Step 2: Perform the Dynamic Assessment

Once you have applied the static easy wins, use the dynamic assessment to validate the improvements on a real device. You can first do this manually with a physical device and a stop watch.

Navigate to the Dynamic Score section of the scoreboard page and do the following:

1. Set up your test environment with a physical device. Consider using a lower-end device to exaggerate performance issues, making them easier to spot.

2. Measure startup time from the launcher. Cold start your app from the launcher icon and measure the time until it is interactive.

3. Measure app startup time from a notification, with the goal to reduce notification startup time to be below a couple seconds.

4. Measure rendering performance by scrolling through your core screens and animations.

Once you've completed these steps, you will receive a score between 1 - 100 for the static and dynamic scores, giving you an understanding of your app's performance and where to focus on.

Level 3: Leverage local performance test frameworks

Once you've started to assess dynamic performance, you may find it too tedious to measure performance manually. Consider automating your performance testing using performance test frameworks such as Macrobenchmarks and UiAutomator.

Macrobenchmark 💚 UiAutomator

Think of Macrobenchmark and UiAutomator as two tools that work together: Macrobenchmark is the measurement tool. It's like a stopwatch and a frame-rate counter that runs outside your app. It is responsible for starting your app, recording metrics (like startup time or dropped frames), and stopping the app. UiAutomator is the robot user. The library lets you write code to interact with the device's screen. It can find an icon, tap a button, scroll on a list and more.

How to write a test

When you write a test, you wrap your UiAutomator code inside a Macrobenchmark block.

1. Define the Test: Use the @MacrobenchmarkRule

2. Start Measuring: Call benchmarkRule.measureRepeated.

3. Drive the UI: Inside that block, use UiAutomator code to launch your app, find UI elements, and interact with them.

Here's an example code snippet of what it looks like to test a compose list for scrolling jank.

4. Review the results: Each test run provides you with precisely measured information to give you the best data on your app's performance.

Common use cases

Macrobenchmark provides several core metrics out of the box. StartupTimingMetric allows you to accurately measure app startup. The FrameTimingMetric enables you to understand an app's rendering performance during the test.

We have a detailed and complete guide to using Macrobenchmarks and UiAutomator alongside code samples available for you to continue learning.

Level 4: Use trace analysis tools like Perfetto

Trace analysis tools like Perfetto are used when you need to see beyond your own application code. Unlike standard debuggers or profilers that only see your process, Perfetto captures the entire device state-kernel scheduling, CPU frequency, other processes, and system services-giving you complete context for performance issues.

Check our Performance Debugging youtube playlist for video instructions on performance debugging using system traces, Android Studio Profiler and Perfetto.

How to use Perfetto to debug performance

The general workflow for debugging performance using trace analysis tools is to record, load and analyze the trace.

Step 1: Record a trace

You can record a system trace using several methods:

• Recording a trace manually on the device directly from the developer options.

• Using the Android Studio CPU Profiler

• Using the Perfetto UI

Step 2: Load the trace

Once you have the trace file, you need to load it into the analysis tool.

1. Open Chrome and navigate to ui.perfetto.dev.

2. Drag and drop your .perfetto-trace (or .pftrace) file directly into the browser window.

3. The UI will process the file and display the timeline.

Step 3: Analyze the trace

You can use Perfetto UI or Android Studio Profiler to investigate performance issues. Check out this episode of the MAD Skills series on Performance, where our performance engineer Carmen Jackson discusses the Perfetto traceviewer.

Scenarios for inspecting system traces using Perfetto

Perfetto is an expert tool and can provide information about everything that happened on the Android device while a trace was captured. This is particularly helpful when you cannot identify the root cause of a slowdown using standard logs or basic profilers.

Debugging Jank (Dropped Frames)

If your app stutters while scrolling, Perfetto can show you exactly why a specific frame missed its deadline.

If it's due to the app, you might see your main thread running for a long duration doing heavy parsing; this indicates scenarios where you should move the work into asynchronous processing.

If it's due to the system, you might see your main thread ready to run, but the CPU kernel scheduler gave priority to a different system service, leaving your app waiting (CPU contention). This indicates scenarios where you may need to optimize usage of platform APIs.

Analyzing Slow App Startup

Startup is complex, involving system init, process forking, and resource loading. Perfetto visualizes this timeline precisely.

You can see if you are waiting on Binder calls (inter-process communication). If your onCreate waits a long time for a response from the system PackageManager, Perfetto will show that blocked state clearly.

You can also see if your app is doing more work than necessary during the app startup. For example, if you are creating and laying out more views than the app needs to show, you can see these operations in the trace.

Investigating Battery Drain & CPU Usage

Because Perfetto sees the whole system, it's perfect for finding invisible power drains.

You can identify which processes are holding wake locks, preventing the device from sleeping under the "Device State" tracks. Learn more in our wake locks blog post. Also, use Perfetto to see if your background jobs are running too frequently or waking up the CPU unnecessarily.

Level 5: Build your own performance tracking framework

The final level is for apps that have teams with resourcing to maintain a performance tracking framework.

Building a custom performance tracking framework on Android involves leveraging several system APIs to capture data throughout the application lifecycle, from startup to exit, and during specific high-load scenarios.

By using ApplicationStartInfo, ProfilingManager, and ApplicationExitInfo, you can create a robust telemetry system that reports on how your app started, detailed info on what it did while running, and why it died.

ApplicationStartInfo: Tracking how the app started

Available from Android 15 (API 35), ApplicationStartInfo provides detailed metrics about app startup in the field. The data includes whether it was a cold, warm, or hot start, and the duration of different startup phases.

This helps you develop a baseline startup metric using production data to further optimize that might be hard to reproduce locally. You can use these metrics to run A/B tests optimizing the startup flow.

The goal is to accurately record launch metrics without manually instrumenting every initialization phase.

You can query this data lazily some time after application launch.

ProfilingManager: Capturing why it was slow

ProfilingManager (API 35) allows your app to programmatically trigger system traces on user devices. This is powerful for catching transient performance issues in the wild that you can't reproduce locally.

The goal is to automatically record a trace when a specific highly critical user journey is detected as running slowly or experiencing performance issues.

You can register a listener that triggers when specific conditions are met or trigger it manually when you detect a performance issue such as jank, excessive memory, or battery drain.

Check our documentation on how to capture a profile, retrieve and analyze profiling data and use debug commands.

ApplicationExitInfo: Tracking why the app died

ApplicationExitInfo (API 30) tells you why your previous process died. This is crucial for finding native crashes, ANRs, or system kills due to excessive memory usage (OOM). You'll also be able to get a detailed tombstone trace by using the API getTraceInputStream.

The goal of the API is to understand stability issues that don't trigger standard Java crash reporters (like Low Memory Kills).

You should trigger this API on the next app launch.

Next Steps

Improving Android performance is a step-by-step journey. We're so excited to see how you level up your performance using these tools!

Tune in tomorrow for Ask Android

You have shrunk your app with R8 and optimized your runtime with Profile Guided Optimization. And measure your app's performance.

Join us tomorrow for the live Ask Android session. Ask your questions now using #AskAndroid and get them answered by the experts.

20 Nov 2025 5:00pm GMT

Posted by Don Turner - Developer Relations Engineer

Jetpack Navigation 3 version 1.0 is stable 🎉. Go ahead and use it in your production apps today. JetBrains are already using it in their KotlinConf app.

Navigation 3 is a new navigation library built from the ground up to embrace Jetpack Compose state. It gives you full control over your back stack, helps you retain navigation state, and allows you to easily create adaptive layouts (like list-detail). There's even a cross-platform version from JetBrains.

Why a new library?

The original Jetpack Navigation library (now Nav2) was designed 7 years ago and, while it serves its original goals well and has been improved iteratively, the way apps are now built has fundamentally changed.

Reactive programming with a declarative UI is now the norm. Nav3 embraces this approach. For example, NavDisplay (the Nav3 UI component that displays your screens) simply observes a list of keys (each one representing a screen) backed by Compose state and updates its UI when that list changes.

Figure 1. NavDisplay observes changes to a list backed by Compose state.

Nav2 can also make it difficult to have a single source of truth for your navigation state because it has its own internal state. With Nav3, you supply your own state, which gives you complete control.

Lastly, you asked for more flexibility and customizability. Rather than having a single, monolithic API, Nav3 provides smaller, decoupled APIs (or "building blocks") that can be combined together to create complex functionality. Nav3 itself uses these building blocks to provide sensible defaults for well-defined navigation use cases.

This approach allows you to:

• Customize screen animations at both a global and individual level

• Display multiple panes at the same time, and create flexible layouts using the Scenes API

• Easily replace Nav3 components with your own implementations if you want custom behavior

Read more about its design and features in the launch blog.

Migrating from Navigation 2

If you're already using Nav2, specifically Navigation Compose, you should consider migrating to Nav3. To assist you with this, there is a migration guide. The key steps are:

1. Add the navigation 3 dependencies.

2. Update your navigation routes to implement NavKey. Your routes don't have to implement this interface to use Nav3, but if they do, you can take advantage of Nav3's rememberNavBackStack function to create a persistent back stack.

3. Create classes to hold and modify your navigation state - this is where your back stacks are held.

4. Replace NavController with these classes.

5. Move your destinations from NavHost's NavGraph into an entryProvider.

6. Replace NavHost with NavDisplay.

Experimenting with AI agent migration

You may want to experiment with using an AI agent to read the migration guide and perform the steps on your project. To try this with Gemini in Android Studio's Agent Mode:

• Save this markdown version of the guide into your project.

• Paste this prompt to the agent (but don't hit enter): "Migrate this project to Navigation 3 using ".

• Type @migration-guide.md - this will supply the guide as context to the agent.

As always, make sure you carefully review the changes made by the AI agent - it can make mistakes!

We'd love to hear how you or your agent performed, please send your feedback here.

Tasty navigation recipes for common scenarios

For common but nuanced use cases, we have a recipes repository. This shows how to combine the Nav3 APIs in a particular way, allowing you to choose or modify the recipe to your particular needs. If a recipe turns out to be popular, we'll consider "graduating" the non-nuanced parts of it into the core Nav3 library or add-on libraries.

Figure 2. Useful code recipes can graduate into a library.

There are currently 19 recipes, including for:

• Multiple back stacks

• Modularization and dependency injection

• Passing navigation arguments to ViewModels (including using Koin)

• Returning results from screens by events and by shared state

We're currently working on a deeplinks recipe, plus a Koin integration, and have plenty of others planned. An engineer from JetBrains has also published a Compose Multiplatform version of the recipes.

If you have a common use case that you'd like to see a recipe for, please file a recipe request.

Summary

To get started with Nav3, check out the docs and the recipes. Plus, keep an eye out for a whole week of technical content including:

• A deep dive video on the API covering modularization, animations and adaptive layouts.

• A live Ask Me Anything (AMA) with the engineers who built Nav3.

Nav3 Spotlight Week starts Dec 1st 2025.

As always, if you find any issues, please file them here.

19 Nov 2025 8:02pm GMT

Posted by Dom Elliott - Group Product Manager, Google Play and Eric Lynch - Senior Product Manager, Android Security

In the mobile ecosystem, abuse can threaten your revenue, growth, and user trust. To help developers thrive, Google Play offers a resilient threat detection service, Play Integrity API. Play Integrity API helps you verify that interactions and server requests are genuine-coming from your unmodified app on a certified Android device, installed by Google Play.

The impact is significant: apps using Play integrity features see 80% lower unauthorized usage on average compared to other apps. Today, leaders across diverse categories-including Uber, TikTok, Stripe, Kabam, Wooga, Radar.com, Zimperium, Paytm, and Remini-use it to help safeguard their businesses.

We're continuing to improve the Play Integrity API, making it easier to integrate, more resilient against sophisticated attacks, and better at recovering users who don't meet integrity standards or encounter errors with new Play in-app remediation prompts.

Detect threats to your business

The Play Integrity API offers verdicts designed to detect specific threats that impact your bottom line during critical interactions.

• Unauthorized access: The accountDetails verdict helps you determine whether the user installed or paid for your app or game on Google Play.

• Code tampering: The appIntegrity verdict helps you determine whether you're interacting with your unmodified binary that Google Play recognizes.

• Risky devices and emulated environments: The deviceIntegrity verdict helps you determine whether your app is running on a genuine Play Protect certified Android device or a genuine instance of Google Play Games for PC.

• Unpatched devices: For devices running Android 13 and higher, MEETS_STRONG_INTEGRITY response in the deviceIntegrity verdict helps you determine if a device has applied recent security updates. You can also opt in to deviceAttributes to include the attested Android SDK version in the response.

• Risky access by other apps: The appAccessRiskVerdict helps you determine whether apps are running that could be used to capture the screen, display overlays, or control the device (for example, by misusing the accessibility permission). This verdict automatically excludes apps that serve genuine accessibility purposes.

• Known malware: The playProtectVerdict helps you determine whether Google Play Protect is turned on and whether it has found risky or dangerous apps installed on the device.

• Hyperactivity: The recentDeviceActivity level helps you determine whether a device has made an anomalously high volume of integrity token requests recently, which could indicate automated traffic and could be a sign of attack.

• Repeat abuse and reused devices: deviceRecall (beta) helps you determine whether you're interacting with a device that you've previously flagged, even if your app was reinstalled or the device was reset. With device recall, you can customize the repeat actions you want to track.

The API can be used across Android form factors including phones, tablets, foldables, Android Auto, Android TV, Android XR, ChromeOS, Wear OS, and on Google Play Games for PC.

Make the most of Play Integrity API

Apps and games have found success with the Play Integrity API by following the security considerations and taking a phased approach to their anti-abuse strategy.

Step 1: Decide what you want to protect: Decide what actions and server requests in your apps and games are important to verify and protect. For example, you could perform integrity checks when a user is launching the app, signing in, joining a multiplayer game, generating AI content, or transferring money.

Step 2: Collect integrity verdict responses: Perform integrity checks at important moments to start collecting verdict data, without enforcement initially. That way you can analyze the responses for your install base and see how they correlate with your existing abuse signals and historical abuse data.

Step 4: Gradually rollout enforcement and support your users: Gradually roll out enforcement. Have a retry strategy when verdicts have issues or are unavailable and be prepared to support good users who have issues. The new Play in-app remediation prompts, described below, make it easier than ever to get users with issues back to a good state.

NEW: Let Play recover users with issues automatically

Deciding how to respond to different integrity signals can be complex, you need to handle various integrity responses and API error codes (like network issues or outdated Play services). We're simplifying this with new Play in-app remediation prompts. You can show a Google Play prompt to your users to automatically fix a wide range of issues directly within your app. This reduces integration complexity, ensures a consistent user interface, and helps get more users back to a good state.

GET_INTEGRITY automatically detects the issue

(in this example, a network error)

and resolves it.

You can trigger the GET_INTEGRITY dialog, available in Play Integrity API library version 1.5.0+, after a range of issues to automatically guide the user through the necessary fixes including:

• Unauthorized access: GET_INTEGRITY guides the user back to a Play licensed response in accountDetails.

• Code tampering: GET_INTEGRITY guides the user back to a Play recognized response in appIntegrity.

• Device integrity issues: GET_INTEGRITY guides the user on how to get back to the MEETS_DEVICE_INTEGRITY state in deviceIntegrity.

• Remediable error codes: GET_INTEGRITY resolves remediable API errors, such as prompting the user to fix network connectivity or update Google Play Services.

We also offer specialized dialogs including GET_STRONG_INTEGRITY (which works like GET_INTEGRITY while also getting the user back to the MEETS_STRONG_INTEGRITY state with no known malware issues in the playProtectVerdict), GET_LICENSED (which gets the user back to a Play licensed and Play recognized state), and CLOSE_UNKNOWN_ACCESS_RISK and CLOSE_ALL_ACCESS_RISK (which prompt the user to close potentially risky apps).

Choose modern integrity solutions

In addition to Play Integrity API, Google offers several other features to consider as part of your overall anti-abuse strategy. Both Play Integrity API and Play's automatic protection offer user experience and developer benefits for safeguarding app distribution. We encourage existing apps to migrate to these modern integrity solutions instead of using the legacy Play licensing library.

Automatic protection: Prevent unauthorized access with Google Play's automatic protection and ensure users continue getting your official app updates. Turn it on and Google Play will automatically add an installer check to your app's code, with no developer integration work required. If your protected app is redistributed or shared through another channel, then the user will be prompted to get your app from Google Play. Eligible Play developers also have access to Play's advanced anti-tamper protection, which uses obfuscation and runtime checks to make it harder and costlier for attackers to modify and redistribute protected apps.

Android platform key attestation: Play Integrity API is the recommended way to benefit from hardware-backed Android platform key attestation. Play Integrity API takes care of the underlying implementation across the device ecosystem, Play automatically mitigates key-related issues and outages, and you can use the API to detect other threats. Developers who directly implement key attestation instead of relying on Play Integrity API should prepare for the upcoming Android Platform root certificate rotation in February 2026 to avoid disruption (developers using Play Integrity API do not need to take any action).

19 Nov 2025 6:11pm GMT

Posted by Ben Weiss - Senior Developer Relations Engineer, Breana Tate - Developer Relations Engineer, Jossi Wolf - Software Engineer on Compose

Compose yourselves and let us guide you through more background on performance.

Welcome to day 3 of Performance Spotlight Week. Today we're continuing to share details and guidance on important areas of app performance. We're covering Profile Guided Optimization, Jetpack Compose performance improvements and considerations on working behind the scenes. Let's dive right in.

Profile Guided Optimization

Baseline Profiles and Startup Profiles are foundational to improve an Android app's startup and runtime performance. They are part of a group of performance optimizations called Profile Guided Optimization.

When an app is packaged, the d8 dexer takes classes and methods and populates your app's classes.dex files. When a user opens the app, these dex files are loaded, one after the other until the app can start. By providing a Startup Profile you let d8 know which classes and methods to pack in the first classes.dex files. This structure allows the app to load fewer files, which in turn improves startup speed.

Baseline Profiles effectively move the Just in Time (JIT) compilation steps away from user devices and onto developer machines. The generated Ahead Of Time (AOT) compiled code has proven to reduce startup time and rendering issues alike.

Trello and Baseline Profiles

We asked engineers on the Trello app how Baseline Profiles affected their app's performance. After applying Baseline Profiles to their main user journey, Trello saw a significant 25 % reduction in app startup time.

Trello was able to improve their app's startup time by 25 % by using baseline profiles.

Baseline Profiles at Meta

Also, engineers at Meta recently published an article on how they are accelerating their Android apps with Baseline Profiles.

Across Meta's apps the teams have seen various critical metrics improve by up to 40 % after applying Baseline Profiles.

Technical improvements like these help you improve user satisfaction and business success as well. Sharing this with your product owners, CTOs and decision makers can also help speed up your app's performance.

Get started with Baseline Profiles

To generate either a Baseline or Startup Profile, you write a macrobenchmark test that exercises the app. During the test profile data is collected which will be used during app compilation. The tests are written using the new UiAutomator API, which we'll cover tomorrow.

Writing a benchmark like this is straightforward and you can see the full sample on GitHub.

Considerations

Start by writing a macrobenchmark tests Baseline Profile and a Startup Profile for the path most traveled by your users. This means the main entry point that your users take into your app which usually is after they logged in. Then continue to write more test cases to capture a more complete picture only for Baseline Profiles. You do not need to cover everything with a Baseline Profile. Stick to the most used paths and measure performance in the field. More on that in tomorrow's post.

Get started with Profile Guided Optimization

To learn how Baseline Profiles work under the hood, watch this video from the Android Developers Summit:

And check out the Android Build Time episode on Profile Guided Optimization for another in-depth look:

We also have extensive guidance on Baseline Profiles and Startup Profiles available for further reading.

Jetpack Compose performance improvements

The UI framework for Android has seen the performance investment of the engineering team pay off. From version 1.9 of Jetpack Compose, scroll jank has dropped to 0.2 % during an internal long scrolling benchmark test.

These improvements were made possible because of several features packed into the most recent releases.

Customizable cache window

By default, lazy layouts only compose one item ahead of time in the direction of scrolling, and after something scrolls off screen it is discarded. You can now customize the amount of items to retain through a fraction of the viewport or dp size. This helps your app perform more work upfront, and after enabling pausable composition in between frames, using the available time more efficiently.

To start using customizable cache windows, instantiate a LazyLayoutCacheWindow and pass it to your lazy list or lazy grid. Measure your app's performance using different cache window sizes, for example 50% of the viewport. The optimal value will depend on your content's structure and item size.

Pausable composition

This feature allows compositions to be paused, and their work split up over several frames. The APIs landed in 1.9 and it is now used by default in 1.10 in lazy layout prefetch. You should see the most benefit with complex items with longer composition times.

More Compose performance optimizations

In the versions 1.9 and 1.10 of Compose the team also made several optimizations that are a bit less obvious.

Several APIs that use coroutines under the hood have been improved. For example, when using Draggable and Clickable, developers should see faster reaction times and improved allocation counts.

Optimizations in layout rectangle tracking have improved performance of Modifiers like onVisibilityChanged() and onLayoutRectChanged(). This speeds up the layout phase, even when not explicitly using these APIs.

Another performance improvement is using cached values when observing positions via onPlaced().

Prefetch text in the background

Starting with version 1.9, Compose adds the ability to prefetch text on a background thread. This enables you to pre-warm caches to enable faster text layout and is relevant for app rendering performance. During layout, text has to be passed into the Android framework where a word cache is populated. By default this runs on the Ui thread. Offloading prefetching and populating the word cache onto a background thread can speed up layout, especially for longer texts. To prefetch on a background thread you can pass a custom executor to any composable that's using BasicText under the hood by passing a LocalBackgroundTextMeasurementExecutor to a CompositionLocalProvider like so.

Depending on the text, this can provide a performance boost to your text rendering. To make sure that it improves your app's rendering performance, benchmark and compare the results.

Background work performance considerations

Background Work is an essential part of many apps. You may be using libraries like WorkManager or JobScheduler to perform tasks like:

• Periodically uploading analytical events

• Syncing data between a backend service and a database

• Processing media (i.e. resizing or compressing images)
  
  

A key challenge while executing these tasks is balancing performance and power efficiency. WorkManager allows you to achieve this balance. It's designed to be power-efficient, and allow work to be deferred to an optimal execution window influenced by a number of factors, including constraints you specify or constraints imposed by the system.

WorkManager is not a one-size-fits-all solution, though. Android also has a number of power-optimized APIs that are designed specifically with certain common Core User Journeys (CUJs) in mind.

Reference the Background Work landing page for a list of just a few of these, including updating a widget and getting location in the background.

Local Debugging tools for Background Work: Common Scenarios

To debug Background Work and understand why a task may have been delayed or failed, you need visibility into how the system has scheduled your tasks.

To help with this, WorkManager has several related tools to help you debug locally and optimize performance (some of these work for JobScheduler as well)! Here are some common scenarios you might encounter when using WorkManager, and an explanation of tools you can use to debug them.

Debugging why scheduled work is not executing

Scheduled work being delayed or not executing at all can be due to a number of factors, including specified constraints not being met or constraints having been imposed by the system.

The first step in investigating why scheduled work is not running is to confirm the work was successfully scheduled. After confirming the scheduling status, determine whether there are any unmet constraints or preconditions preventing the work from executing.

There are several tools for debugging this scenario.

Background Task Inspector

The Background Task Inspector is a powerful tool integrated directly into Android Studio. It provides a visual representation of all WorkManager tasks and their associated states (Running, Enqueued, Failed, Succeeded).

To debug why scheduled work is not executing with the Background Task Inspector, consult the listed Work status(es). An 'Enqueued' status indicates your Work was scheduled, but is still waiting to run.

Benefits: Aside from providing an easy way to view all tasks, this tool is especially useful if you have chained work. The Background Task inspector offers a graph view that can visualize if a previous task failing may have impacted the execution of the following task.

Background Task Inspector list view

Background Task Inspector graph view

adb shell dumpsys jobscheduler

This command returns a list of all active JobScheduler jobs (which includes WorkManager Workers) along with specified constraints, and system-imposed constraints. It also returns job history.

Use this if you want a different way to view your scheduled work and associated constraints. For WorkManager versions earlier than WorkManager 2.10.0, adb shell dumpsys jobscheduler will return a list of Workers with this name:

If your app has multiple workers, updating to WorkManager 2.10.0 will allow you to see Worker names and easily distinguish between workers:

Benefits: This command is useful for understanding if there were any system-imposed constraints, which you cannot determine with the Background Task Inspector. For example, this will return your app's standby bucket, which can affect the window in which scheduled work completes.

Enable Debug logging

You can enable custom logging to see verbose WorkManager logs, which will have WM- attached.

Benefits: This allows you to gain visibility into when work is scheduled, constraints are fulfilled, and lifecycle events, and you can consult these logs while developing your app.

WorkInfo.StopReason

If you notice unpredictable performance with a specific worker, you can programmatically observe the reason your worker was stopped on the previous run attempt with WorkInfo.getStopReason.

It's a good practice to configure your app to observe WorkInfo using getWorkInfoByIdFlow to identify if your work is being affected by background restrictions, constraints, frequent timeouts, or even stopped by the user.

Benefits: You can use WorkInfo.StopReason to collect field data about your workers' performance.

Debugging WorkManager-attributed high wake lock duration flagged by Android vitals

Android vitals features an excessive partial wake locks metric, which highlights wake locks contributing to battery drain. You may be surprised to know that WorkManager acquires wake locks to execute tasks, and if the wake locks exceed the threshold set by Google Play, can have impacts to your app's visibility. How can you debug why there is so much wake lock duration attributed to your work? You can use the following tools.

Android vitals dashboard

First confirm in the Android vitals excessive wake lock dashboard that the high wake lock duration is from WorkManager and not an alarm or other wake lock. You can use the Identify wake locks created by other APIs documentation to understand which wake locks are held due to WorkManager.

Perfetto

Perfetto is a tool for analyzing system traces. When using it for debugging WorkManager specifically, you can view the "Device State" section to see when your work started, how long it ran, and how it contributes to power consumption.

Under "Device State: Jobs" track, you can see any workers that have been executed and their associated wake locks.

Device State section in Perfetto, showing CleanupWorker and BlurWorker execution.

Resources

Consult the Debug WorkManager page for an overview of the available debugging methods for other scenarios you might encounter.

And to try some of these methods hands on and learn more about debugging WorkManager, check out the Advanced WorkManager and Testing codelab.

Next steps

Today we moved beyond code shrinking and explored how the Android Runtime and Jetpack Compose actually render your app. Whether it's pre-compiling critical paths with Baseline Profiles or smoothing out scroll states with the new Compose 1.9 and 1.10 features, these tools focus on the feel of your app. And we dove deep into best practices on debugging background work.

Ask Android

On Friday we're hosting a live AMA on performance. Ask your questions now using #AskAndroid and get them answered by the experts.

The challenge

We challenged you on Monday to enable R8. Today, we are asking you to generate one Baseline Profile for your app.

With Android Studio Otter, the Baseline Profile Generator module wizard makes this easier than ever. Pick your most critical user journey-even if it's just your app startup and login-and generate a profile.

Once you have it, run a Macrobenchmark to compare CompilationMode.None vs. CompilationMode.Partial.

Share your startup time improvements on social media using #optimizationEnabled.

Tune in tomorrow

You have shrunk your app with R8 and optimized your runtime with Profile Guided Optimization. But how do you prove these wins to your stakeholders? And how do you catch regressions before they hit production?

Join us tomorrow for Day 4: The Performance Leveling Guide, where we will map out exactly how to measure your success, from field data in Play Vitals to deep local tracing with Perfetto.

19 Nov 2025 5:00pm GMT

Posted by Niharika Arora - Senior Developer Relations Engineer at Google, Thomás Oliveira Horta - Android Engineer at Uber

Uber is the world's largest ridesharing company, getting millions of people from here to there while also supporting food delivery, healthcare transportation, and freight logistics. Simplicity of access is crucial to its success; when users switch to a new device, they expect a seamless transition without needing to log back into the Uber app or go through SMS-based one-time password authentication. This frequent device turnover presents a challenge, as well as an opportunity for strong user retention.

To maintain user continuity, Uber's engineers turned to the Restore Credentials feature, an essential tool for a time when 40% of people in the United States replace their smartphone every year. Following an assessment of user demand and code prototyping, they introduced Restore Credentials support in the Uber rider app. To validate that restoring credentials helps remove friction for re-logins, the Uber team ran a successful A/B experiment for a five-week period. The integration led to a reduction in manual logins that, when projected across Uber's massive user base, is estimated to eliminate 4 million manual logins annually.

Eliminating login friction with Restore Credentials

The Restore Credentials API eliminates the multi-step manual sign in process on new devices.

There were past attempts at account restoration on new devices using solutions like regular data backup and BlockStore, though both solutions required sharing authentication tokens directly, from source device to destination device. Since token information is highly sensitive, these solutions are only used to some extent, to pre-fill login fields on the destination device and reduce some friction during the sign-in flows. Passkeys are also used to provide a secure and fast login method, but their user-initiated nature limits their impact on seamless device transitions.

"Some users don't use the Uber app on a daily basis, but they expect it will just work when they need it," said Thomás Oliveira Horta, an Android engineer at Uber. "Finding out you're logged out just as you open the app to request a ride on your new Android phone can be an unpleasant, off-putting experience."

With Restore Credentials, the engineers were able to bridge this gap. The API generates a unique token on the old device, which is seamlessly and silently moved to the new device when the user restores their app data during the standard onboarding process. This process leverages Android OS's native backup and restore mechanism, ensuring the safe transfer of the restore key along with the app's data. The streamlined approach guarantees a simple and safe account transfer, meeting Uber's security requirements without any additional user input or development overhead.

"With the adoption of Restore Credentials on Uber's rider app, we started seeing consistent usage," Thomás said. "An average of 10,000 unique daily users have signed in with Restore Credentials in the current rollout stage, and they've enjoyed a seamless experience when opening the app for the first time on a new device. We expect that number to double once we expand the rollout to our whole userbase."

Implementation Considerations

"Integration was pretty easy with minor adjustments on the Android side by following the sample code and documentation," Thomás said. "Our app already used Credential Manager for passkeys, and the backend required just a couple of small tweaks. Therefore, we simply needed to update the Credential Manager dependency to its latest version to get access to the new Restore Credentials API. We created a restore key via the same passkey creation flow and when our app is launched on a new device, the app proactively checks for this key by attempting a silent passkey retrieval. If the restore key is found, it is immediately utilized to automatically sign the user in, bypassing any manual login."

Throughout the development process, Uber's engineers navigated a few challenges during implementation-from choosing the right entry point to managing the credential lifecycle on the backend.

Choosing the Restore Credentials entry point

The engineers carefully weighed the tradeoffs between a perfectly seamless user experience and implementation simplicity when selecting which Restore Credentials entry point to use for recovery. Ultimately, they prioritized a solution that offered an ideal balance.

"This can take place during App Launch or in the background during device restoration and setup, using BackupAgent," Thomás said. "The background login entry point is more seamless for the user, but it presented challenges with background operations and required usage of the BackupAgent API, which would have led to increased complexity in a codebase as large as Uber's." They decided to implement the feature during the first app launch, which was significantly faster than the manual login.

Addressing server-side challenges

A few server-side challenges arose during integration with the backend WebAuthn APIs, as their design assumed user verification would always be required, and that all credentials would be listed in a user's account settings; neither of these assumptions worked for the non-user-managed Restore Credential keys.

The Uber team resolved this by making minor changes to the WebAuthn services, creating new credential types to distinguish passkeys from Restore Credentials and process them appropriately.

Managing the Restore Credentials lifecycle

Uber's engineers faced several challenges in managing the credential keys on the backend, with specialized support from backend engineer Ryan O'Laughlin:

• Preventing orphaned keys: A significant challenge was defining a strategy for deleting registered Public Keys to prevent them from becoming "orphaned." For example, uninstalling the app deletes the local credential, but because this action doesn't signal the backend, it leaves an unused key on the server.

• Balancing key lifespan: Keys needed a "time to live" that was long enough to handle edge cases. For example, if a user goes through a backup and restore, then manually logs out from the old device, the key is deleted from that old device. However, the key must remain valid on the server so the new device can still use it.

• Supporting multiple devices: Since a user might have multiple devices (and could initiate a backup and restore from any of them), the backend needed to support multiple Restore Credentials per user (one for each device).

Uber's engineers addressed these challenges by establishing rules for server-side key deletion based on new credential registration and credential usage.

The feature went from design to delivery in a rapid two-month development and testing process. Afterward, a five-week A/B experiment (time to validate the feature with users) went smoothly and yielded undeniable results.

Preventing user drop-off with Restore Credentials

By eliminating manual logins on new devices, Uber retained users who might have otherwise abandoned the sign-in flow on a new device. This boost in customer ease was reflected in a wide array of improvements, and though they may seem slight at a glance, the impact is massive at the scale of Uber's user base:

• 3.4% decrease in manual logins (SMS OTP, passwords, social login).

• 1.2% reduction in expenses for logins requiring SMS OTP.

• 0.575% increase in Uber's access rate (% of devices that successfully reached the app home screen).

• 0.614% rise in devices with completed trips.
  
  

Today, Restore Credentials is well on its way to becoming a standard part of Uber's rider app, with over 95% of users in the trial group registered.

[UI flow]

During new device setup, users can restore app data and credentials from a backup. After selecting Uber for restoration and the background process finishes, the app will automatically sign the user in on the new device's first launch.

The invisible yet massive impact of Restore Credentials

In the coming months, Uber plans to expand the integration of Restore Credentials. Projecting from the trial's results, they estimate the change will eliminate 4 million manual logins annually. By simplifying app access and removing a key pain point, they are actively building a more satisfied and loyal customer base, one ride at a time.

"Integrating Google's RestoreCredentials allowed us to deliver the seamless 'it just works' experience our users expect on a new device," said Matt Mueller, Lead Product Manager (Core Identity) at Uber. "This directly translated to a measurable increase in revenue, proving that reducing login friction is key to user engagement and retention."

Ready to enhance your app's login experience?

Learn how to facilitate a seamless login experience when switching devices with Restore Credentials and read more in the blog post. In the latest canary of the Android Studio Otter you can validate your integration, as new features help mock the backup and restoring mechanisms.

If you are new to Credential Manager, you can refer to our official documentation, codelab and samples for help with integration.

18 Nov 2025 10:00pm GMT

Posted by Ajesh R Pai - Developer Relations Engineer & Ben Weiss - Senior Developer Relations Engineer

In modern Android development, shipping a small, fast, and secure application is a fundamental user expectation. The Android build system's primary tool for achieving this is the R8 optimizer, the compiler that handles dead code and resource removal for shrinking, code renaming or minification, and app optimization.

Enabling R8 is a critical step in preparing an app for release, but it requires developers to provide guidance in the form of "Keep Rules."

After reading this article, check out the Performance Spotlight Week video on enabling, debugging and troubleshooting the R8 optimizer on YouTube.

Why Keep Rules are needed

The need to write Keep Rules stems from a core conflict: R8 is a static analysis tool, but Android apps often rely on dynamic execution patterns like reflection or calls in and out of native code using the JNI (Java Native Interface).

R8 builds a graph of used code by analyzing direct calls. When code is accessed in a dynamic way, R8's static analysis cannot predict that and it will identify that code as unused and remove it, leading to runtime crashes.

A keep rule is an explicit instruction to the R8 compiler, stating: "This specific class, method, or field is an entry point that will be accessed dynamically at runtime. You must keep it, even if you cannot find a direct reference to it."

See the official guide for more details on Keep Rules.

Where to write Keep Rules

Custom Keep Rules for an application are written in text file. By convention, this file is named proguard-rules.pro and is located in the root of the app or library module. This file is then specified in your module's build.gradle.kts file's release build type.

Use the correct default file

The getDefaultProguardFile method imports a default set of rules provided by the Android SDK. When using the wrong file your app might not be optimized. Make sure to use proguard-android-optimize.txt. This file provides the default Keep Rules for standard Android components and enables R8's code optimizations. The outdated proguard-android.txt only provides the Keep Rules but does not enable R8's optimizations.

Since this is a serious performance problem, we are starting to warn developers about using the wrong file, starting in Android Studio Narwhal 3 Feature Drop. And starting with the Android Gradle Plugin Version 9.0 we're no longer supporting the outdated proguard-android.txt file. So make sure you upgrade to the optimized version.

How to write Keep Rules

A keep rule consists of three main parts:

1. An option like -keep or -keepclassmembers

2. Optional modifiers like allowshrinking

3. A class specification that defines the code to match

For the complete syntax and examples, refer to the guidance to add Keep Rules.

Keep Rule anti-patterns

It's important to know about best practices, but also about anti-patterns. These anti-patterns often arise from misunderstandings or troubleshooting shortcuts and can be catastrophic for a production build's performance.

Global options

These flags are global toggles that should never be used in a release build. They are only for temporary debugging to isolate a problem.

Using -dontotptimize effectively disables R8's performance optimizations leading to a slower app.

When using -dontobfuscate you disable all renaming and using -dontshrink turns off dead code removal. Both of these global rules increase app size.

Avoid using these global flags in a production environment wherever possible for a more performant app user experience.

Overly broad keep rules

The easiest way to nullify R8's benefits is to write overly-broad Keep Rules. Keep rules like the one below instruct the R8 optimizer to not shrink, not obfuscate, and not optimize any class in this package or any of its sub-packages. This completely removes R8's benefits for that entire package. Try to write narrow and specific Keep Rules instead.

The inversion operator (!)

The inversion operator (!) seems like a powerful way to exclude a package from a rule. But it's not that simple. Take this example:

You might think that this rule means "do not keep classes in com.example.package." But it actually means "keep every class, method and property in the entire application that is not in com.example.package." If that came as a surprise to you, best check for any negations in your R8 configuration.

Redundant rules for Android components

Another common mistake is to manually add Keep Rules for your app's Activities, Services, or BroadcastReceivers. This is unnecessary. The default proguard-android-optimize.txt file already includes the relevant rules for these standard Android components to work out of the box.

Also many libraries bring their own Keep Rules. So you should not have to write your own rules for these. In case there is a problem with Keep Rules from a library you're using, it is best to reach out to the library author to see what the problem is.

Keep Rule best practices

Now that you know what not to do, let's talk about best practices.

Write narrow Keep Rules

Good Keep Rules should be as narrow and specific as possible. They should preserve only what is necessary, allowing R8 to optimize everything else.

Use common ancestors

Instead of writing separate Keep Rules for multiple different data models, write one rule that targets a common base class or interface. The below rule tells R8 to keep any members of classes that implement this interface and is highly scalable.

Use Annotations to target multiple classes

Create a custom annotation (e.g., @Serialize) and use it to "tag" classes that need their fields preserved. This is another clean, declarative, and highly scalable pattern. You can create Keep Rules for already existing annotations from frameworks you're using as well.

Choose the right Keep Option

The Keep Option is the most critical part of the rule. Choosing the wrong one can needlessly disable optimization.

You can find more about the keep option in our documentation for Keep Options.

Allow optimization with Modifiers

Modifiers like allowshrinking and allowobfuscation relax a broad -keep rule, giving optimization power back to R8. For example, if a legacy library forces you to use -keep on an entire class, you might be able to reclaim some optimization by allowing shrinking and obfuscation:

Add global options for additional optimization

Beyond Keep Rules, you can add global flags to your R8 configuration file to encourage even more optimization.

-repackageclasses is a powerful option that instructs R8 to move all obfuscated classes into a single package. This saves significant space in the DEX file by removing redundant package name strings.

-allowaccessmodification allows R8 to widen access (e.g., private to public) to enable more aggressive inlining. This is now enabled by default when using proguard-android-optimize.txt.

Warning: Library authors must never add these global optimization flags to their consumer rules, as they would be forcibly applied to the entire app.

And to make it even more clear, in version 9.0 of the Android Gradle Plugin we're going to start ignoring global optimization flags from libraries altogether.

Best practices for libraries

Every Android app relies on libraries one way or another. So let's talk about best practices for libraries.

For library developers

If your library uses reflection or JNI, you have the responsibility to provide the necessary Keep Rules to its consumers. These rules are placed in a consumer-rules.pro file, which is then automatically bundled inside the library's AAR file.

For library consumers

Filter out problematic Keep Rules

If you must use a library that includes problematic Keep Rules, you can filter them out in your build.gradle.kts file starting with AGP 9.0 This tells R8 to ignore the rules coming from a specific dependency.

The best Keep Rule is no Keep Rule

The ultimate R8 configuration strategy is to remove the need to write Keep Rules altogether. For many apps can be achieved by choosing modern libraries that favor code generation over reflection. With code generation, the optimizer can more easily determine what code is actually used at runtime and what code can be removed. Also not using any dynamic reflection means no "hidden" entry points, and therefore, no Keep Rules are needed. When choosing a new library, always prefer a solution that uses code generation over reflection.

For more information about how to choose libraries, check choose library wisely.

Debugging and troubleshooting your R8 configuration

When R8 removes code it should have kept, or your APK is larger than expected, use these tools to diagnose the problem.

Find duplicate and global Keep Rules

Because R8 merges rules from dozens of sources, it can be hard to know what the "final" ruleset is. Adding this flag to your proguard-rules.pro file generates a complete report:

You can search this file to find redundant rules or trace a problematic rule (like -dontoptimize) back to the specific library that included it.

Ask R8: Why are you keeping this?

If a class you expected to be removed is still in your app, R8 can tell you why. Just add this rule:

During the build, R8 will print the exact chain of references that caused it to keep that class, allowing you to trace the reference and adjust your rules.

For a full guide, check out the troubleshoot R8 section.

Next steps

R8 is a powerful tool for enhancing Android app performance. Its effectiveness, depends on a correct understanding of its operation as a static analysis engine.

By writing specific, member-level rules, leveraging ancestors and annotations, and carefully choosing the right keep options, you can preserve exactly what is necessary. The most advanced practice is to eliminate the need for rules entirely by choosing modern, codegen-based libraries over their reflection-based predecessors.

As you're following along Performance Spotlight Week, make sure to check out today's Spotlight Week video on YouTube and continue with our R8 challenge. Use #optimizationEnabled for any questions on enabling or troubleshooting R8. We're here to help.

It's time to see the benefits for yourself.

We challenge you to enable R8 full mode for your app today.

1. Follow our developer guides to get started: Enable app optimization.

2. Check if you still use proguard-android.txt and replace it with proguard-android-optimize.txt.

3. Then, measure the impact. Don't just feel the difference, verify it. Measure your performance gains by adapting the code from our Macrobenchmark sample app on GitHub to measure your startup times before and after.

We're confident you'll see a meaningful improvement in your app's performance.

While you're at it, use the social tag #AskAndroid to bring your questions. Throughout the week our experts are monitoring and answering your questions.

Stay tuned for tomorrow, where we'll talk about Profile Guided Optimization with Baseline and Startup Profiles, share how Compose rendering performance improved over the past releases and share performance considerations for background work.

18 Nov 2025 5:00pm GMT

Posted by Tor Norbye - Senior Director of Engineering

18 Nov 2025 4:06pm GMT

Posted by Ben Weiss - Senior Developer Relations Engineer

In today's world of mobile applications, a seamless user experience is not just a feature-it's a necessity. Slow load times, unresponsive interfaces, and instability can be significant barriers to user engagement and retention. During their work with the Android Developer Relations team, the engineering team at Reddit used the App Performance Score to evaluate their app. After assessing their performance, they identified significant improvement potential and decided to take the steps to enable the full power of R8, the Android app optimizer. This focused initiative led to remarkable improvements in startup times, reductions in slow or frozen frames and ANRs, and an overall increase in Play Store ratings. This case study breaks down how Reddit achieved these impressive results.

How the R8 Optimizer helped Reddit

• Tree shaking is the most important step to reduce an app's size. Here, unused code from app dependencies and the app itself is removed.

• Method inlining replaces method calls with the actual code, making the app more performant.

• Class merging, and other strategies are applied to make the code more compact. At this point it's not about human readability of source code any more, but making compiled code work fast. So abstractions, such as interfaces or class hierarchies don't matter here and will be removed.

• Identifier minification changes the names of classes, fields, and methods to shorter, meaningless names. So instead of MyDataModel you might end up with a class called a.

• Resource shrinking removes unused resources such as xml files and drawables to further reduce app size.

Caption: Main stages of R8 Optimization

From hard data to user satisfaction: Identifying success in production

Reddit saw improved performance results immediately after a new version of the app was rolled out to users. By using Android Vitals and Crashlytics, Reddit was able to capture performance metrics on real devices with actual users, allowing them to compare the new release against previous versions.

Caption: How R8 improved Reddit's app performance

The team observed a 40% faster cold startup, a 30% reduction in "Application Not Responding" (ANR) errors, a 25% improvement in frame rendering, and a 14% reduction in app size.

These enhancements are crucial for user satisfaction. A faster startup means less waiting and quicker access to content. Fewer ANRs lead to a more stable and reliable app, reducing user frustration. Smoother frame rendering removes UI jank, making scrolling and animations feel fluid and responsive. This positive technical impact was also clearly visible in user sentiment.

User satisfaction indicators of the optimization's success were directly visible on the Google Play Store. Following the rollout of the R8-optimized version, the team saw a dramatic and positive shift in user sentiment and engagement.

Drew Heavner: "Enabling R8's full potential tool less than 2 weeks"

Most impressively, this was accomplished with a focused effort. Drew Heavner, the Staff Software Engineer at Reddit who worked on this initiative, noted that implementing the changes to enable R8's full potential took less than two weeks.

Confirming the gains: A deep dive with macrobenchmarks

After observing the significant real-world improvements, Reddit's engineering team and the Android Developer Relations team at Google conducted detailed benchmarks to scientifically confirm the gains and experiment with further optimizations. For this analysis, Reddit engineering provided two versions of their app: one without optimizations and another that applied R8 and two more foundational performance optimization tools: Baseline Profiles, and Startup Profiles.

Baseline Profiles effectively move the Just in Time (JIT) compilation steps away from user devices and onto developer machines. The generated Ahead Of Time (AOT) compiled code has proven to reduce startup time and rendering issues alike.

When an app is packaged, the d8 dexer takes classes and methods and constructs your app's classes.dex files. When a user opens the app, these dex files are loaded, one after the other until the app can start. By providing a Startup Profile you let d8 know which classes and methods to pack in the first classes.dex files. This structure allows the app to load fewer files, which in turn improves startup speed.

Jetpack Macrobenchmark was the core tool for this phase, allowing for precise measurement of user interactions in a controlled environment. To simulate a typical user journey, they used the UIAutomator API to create a test that opened the app, scrolled down three times, and then scrolled back up.

In the end all that was needed to write the benchmark was this:

The benchmark data confirmed the field observations and provided deeper insights. The fully optimized app started 55% faster and users could begin to browse 18% sooner. The optimized app also showed a two-thirds reduction in Just in Time (JIT) compilation occurrences and a one-third decrease in JIT compilation time. Frame rendering improved, resulting in 19% more frames being rendered over the benchmarked user journey. Finally, the app's size was reduced by over a third.

Caption: Reddit's overall performance improvements

You can measure the JIT compilation time with a custom Macrobenchmark trace section metric like this:

Enabling the technology behind the transformation: R8

To enable R8 in full mode, you configure your app/build.gradle.kts file by setting minifyEnabled and shrinkResources to true in the release build type.

This step has to be followed by holistic end to end testing, as performance optimizations can lead to unwanted behavior, which you better catch before your users do.

As shown earlier in this article, R8 performs extensive optimizations in order to maximize your performance benefits. R8 makes substantial modifications to the code including renaming, moving, and removing classes, fields and methods. If you observe that these modifications cause errors, you need to specify which parts of the code R8 shouldn't modify by declaring those in keep rules.

Follow Reddit's example in your app

Reddit's success with R8 serves as a powerful case study for any development team looking to make a significant, low-effort impact on their app's performance. The direct correlation between the technical improvements and the subsequent rise in user satisfaction underscores the value of performance optimization.

By following the blueprint laid out in this case study-using tools like the App Performance Score to identify opportunities, enabling R8's full optimization potential, monitoring real-world data, and using benchmarks to confirm and deepen understanding-other developers can achieve similar gains.

To get started with R8 in your own app, refer to the freshly updated official documentation and guidance on enabling, configuring and troubleshooting the R8 optimizer.

17 Nov 2025 6:01pm GMT

Posted by Ben Weiss - Senior Developer Relations Engineer

Welcome to day one of Android Performance Spotlight Week!

We're kicking things off with the single most impactful, low-effort change you can make to improve your app's performance: enabling the R8 optimizer in full mode.

You probably already know R8 as a tool to shrink your app's size. It does a fantastic job of removing unused code and resources, reducing your app's size. But its real power, the one it's really g-R8 at, is as an optimizer.

When you enable full mode and allow optimizations, R8 performs deep, whole-program optimizations, rewriting your code to be fundamentally more efficient. This isn't just a minor tweak.

After reading this article, check out the Performance Spotlight Week introduction to the R8 optimizer on YouTube.

How R8 makes your app more performant

Let's shine a spotlight on the largest steps that the R8 optimizer takes to improve app performance.

Tree shaking is the most important step to reduce app size. During this phase the R8 optimizer removes unused code from libraries that your app depends on as well as dead code from your own codebase.

Method inlining replaces a method call with the actual code, which improves runtime performance.

Class merging, and other strategies are applied to make the code more compact. All your beautiful abstractions, such as interfaces and class hierarchies don't matter at this point and are likely to be removed.

Code minification is used to change the names of classes, fields, and methods to shorter, meaningless ones. So instead of MyDataModel you might end up with a class called a. This is what causes the most confusion when reading stack traces from an R8 optimized app. (Note that we have improved this in AGP 9.0!)

Resource shrinking further reduces an app's size by removing unused resources such as xml files and drawables.

By applying these steps the R8 optimizer improves app startup times, enables smoother UI rendering, with fewer slow and frozen frames and improves overall on-device resource usage.

Case Study: Reddit's performance improvements with R8

As one example of the performance improvements that R8 can bring, let's take a look at an example from Reddit. After enabling R8 in full mode, the Reddit for Android app saw significant performance improvements in various areas.

Caption: How R8 improved Reddit's app performance

The team observed a 40% faster cold startup, a 30% reduction in "Application Not Responding" (ANR) errors, a 25% improvement in frame rendering, and a 14% reduction in app size .

These enhancements are crucial for user satisfaction. A faster startup means less waiting and quicker access to content. Fewer ANRs lead to a more stable and reliable app, reducing user frustration. Smoother frame rendering removes UI jank, making scrolling and animations feel fluid and responsive. This positive technical impact was also clearly visible in user sentiment.

You can read more about their improvements on our blog.

Non-technical side effects of using R8

During our work with partners we have seen that these technical improvements have a direct impact on user satisfaction and can be reflected in user retention, engagement and session length. User stickiness, which can be measured with daily, weekly or monthly active users, has also been positively affected by technical performance improvements. And we've seen app ratings on the Play Store rise in correlation with R8 adoption. Sharing this with your product owners, CTOs and decision makers can help speed up your app's performance.

So let's call it what it is: Deliberate performance optimization is a virtue.

Guiding you to a more performant app

We heard that our developer guidance for R8 needed to be improved. So we went to work. The developer guidance for the R8 optimizer now is much more actionable and provides comprehensive guidance to enable and debug R8.

The documentation guides you on the high-level strategy for adoption, emphasizing the importance of choosing optimization-friendly libraries and, crucially, adopting R8's features incrementally to ensure stability. This phased approach allows you to safely unlock the benefits of R8 while providing you with guidance on difficult-to-debug issues.

We have significantly expanded our guidance on Keep Rules, which are the primary mechanism for controlling the R8 optimizer. We now provide a section on what Keep Rules are, how to apply them and guide you with best practices for writing and maintaining them. We also provide practical and actionable use cases and examples, helping you understand how to correctly prevent R8 from removing code that is needed at runtime, such as code accessed via reflection or use of the JNI native interface.

The documentation now also covers essential follow-up steps and advanced scenarios. We added a section on testing and troubleshooting, so you can verify the performance gains and debug any potential issues that arise. The advanced configurations section explains how to target specific build variants, customize which resources are kept or removed, and offers special optimization instructions for library authors, ensuring you can provide an optimized and R8-friendly package for other developers to use.

Enable the R8 optimizer's full potential

The R8 optimizer defaults to using "full mode" since version 8.0 of the Android Gradle Plugin. If your project has been developed over many years, it might still include a legacy flag to disable it. Check your gradle.properties file for this line and remove it.

Now check whether you have enabled R8 in your app's build.gradle.kts file for the release variant. It's enabled by setting isMinifyEnabled and isShrinkResources to true. You can also pass default and custom configuration files at this step.

Case Study: Disney+ performance improvements

Engineers at Disney+ invest in app performance and are optimizing the app's user experience. Sometimes even seemingly small changes can make a huge impact. While inspecting their R8 configuration, the team found that the -dontoptimize flag was being used. It was brought in by a default configuration file, which is still used in many apps today.

After replacing proguard-android.txt with proguard-android-optimize.txt, the Disney+ team saw significant improvements in their app's performance.

After a new version of the app containing this change was rolled out to users, Disney+ saw 30% faster app startup and 25% fewer user-perceived ANRs.

Today many apps still use the proguard-android.txt file which contains the -dontoptimize flag. And that's where our tooling improvements come in.

Tooling support

Starting with Android Studio Narwhal 3 Feature Drop, you will see a lint warning when using proguard-android.txt

And from AGP 9.0 onwards we are entirely dropping support for the file. This means you will have to migrate to proguard-android-optimize.txt.

We've also invested in new Android Studio features to make debugging R8-optimized code easier than ever. Starting in AGP 9.0 you can now automatically de-obfuscate stack traces within Android Studio's logcat for R8-processed builds, helping you pinpoint the exact line of code causing an issue, even in a fully optimized app. This will be covered in more depth in tomorrow's blog post on this Android Performance Spotlight Week.

Next Steps

Check out the Performance Spotlight Week introduction to the R8 optimizer on YouTube.

📣 Take the Performance Challenge!

It's time to see the benefits for yourself.

We challenge you to enable R8 full mode for your app today.

1. Follow our developer guides to get started: Enable app optimization.

2. Check if you still use proguard-android.txt and replace it with proguard-android-optimize.txt.

3. Then, measure the impact. Don't just feel the difference, verify it. Measure your performance gains by adapting the code from our Macrobenchmark sample app on GitHub to measure your startup times before and after.

We're confident you'll see a meaningful improvement in your app's performance. Use #optimizationEnabled for any questions on enabling or troubleshooting R8. We're here to help.

Bring your questions for the Ask Android session on Friday

Use the social tag #AskAndroid to bring any performance questions. Throughout the week we are monitoring your questions and will answer several in the Ask Android session on performance on Friday, November 21. Stay tuned for tomorrow, where we'll dive even deeper into debugging and troubleshooting. But for now, get started with R8 and get your app on the fast track.

17 Nov 2025 5:00pm GMT

Posted by Ben Weiss - Senior Developer Relations Engineer, Performance Paladin

17 Nov 2025 5:00pm GMT

Posted by Scott Nien, Software Engineer

The CameraX team is thrilled to announce the release of version 1.5! This latest update focuses on bringing professional-grade capabilities to your fingertips while making the camera session easier to configure than ever before.

For video recording, users can now effortlessly capture stunning slow-motion or high-frame-rate videos. More importantly, the new Feature Group API allows you to confidently enable complex combinations like 10-bit HDR and 60 FPS, ensuring consistent results across supported devices.

On the image capture front, you gain maximum flexibility with support for capturing unprocessed, uncompressed DNG (RAW) files. Plus, you can now leverage Ultra HDR output even when using powerful Camera Extensions.

Underpinning these features is the new SessionConfig API, which streamlines camera setup and reconfiguration. Now, let's dive into the details of these exciting new features.

Powerful Video Recording: High-Speed and Feature Combinations

CameraX 1.5 significantly expands its video capabilities, enabling more creative and robust recording experiences.

Slow Motion & High Frame Rate Video

One of our most anticipated features, slow-motion video, is now available. You can now capture high-speed video (e.g., 120 or 240 fps) and encode it directly into a dramatic slow-motion video. Alternatively, you can record at the same high frame rate to produce exceptionally smooth video.

Implementing this is straightforward if you're familiar with the VideoCapture API.

1. Check for High-Speed Support: Use the new Recorder.getHighSpeedVideoCapabilities() method to query if the device supports this feature.

val cameraInfo = cameraProvider.getCameraInfo(cameraSelector)

val highSpeedCapabilities = Recorder.getHighSpeedVideoCapabilities(cameraInfo)

if (highSpeedCapabilities == null) {
    // This camera device does not support high-speed video.
    return
}

2. Configure and Bind the Use Case: Use the returned videoCapabilities (which contains supported video quality information) to build a HighSpeedVideoSessionConfig. You must then query the supported frame rate ranges via cameraInfo.getSupportedFrameRateRanges() and set the desired range. Invoke setSlowMotionEnabled(true) to record slow motion videos, otherwise it will record high-frame-rate videos. The final step is to use the regular Recorder.prepareRecording().start() to begin recording the video.

val preview = Preview.Builder().build()
val quality = highSpeedCapabilities
        .getSupportedQualities(DynamicRange.SDR).first()

val recorder = Recorder.Builder()
      .setQualitySelector(QualitySelector.from(quality)))
      .build()

val videoCapture = VideoCapture.withOutput(recorder)

val frameRateRange = cameraInfo.getSupportedFrameRateRanges(      
       HighSpeedVideoSessionConfig(videoCapture, preview)
).first()

val sessionConfig = HighSpeedVideoSessionConfig(
    videoCapture, 
    preview, 
    frameRateRange = frameRateRange, 
    // Set true for slow-motion playback, or false for high-frame-rate
    isSlowMotionEnabled = true
)

cameraProvider.bindToLifecycle(
     lifecycleOwner, cameraSelector, sessionConfig)

// Start recording slow motion videos. 
val recording = recorder.prepareRecording(context, outputOption)
      .start(executor, {})

Compatibility and Limitations

High-speed recording requires specific CameraConstrainedHighSpeedCaptureSession and CamcorderProfile support. Always perform the capability check, and enable high-speed recording only on supported devices to prevent bad user experience. Currently, this feature is supported on the rear cameras of almost all Pixel devices and select models from other manufacturers.

Check the blog post for more details.

Combine Features with Confidence: The Feature Group API

CameraX 1.5 introduces the Feature Group API, which eliminates the guesswork of feature compatibility. Based on Android 15's feature combination query API, you can now confidently enable multiple features together, guaranteeing a stable camera session. The Feature Group currently supports: HDR (HLG), 60 fps, Preview Stabilization, and Ultra HDR. For instance, you can enable HDR, 60 fps, and Preview Stabilization simultaneously on Pixel 10 and Galaxy S25 series. Future enhancements are planned to include 4K recording and ultra-wide zoom.

The feature group API enables two essential use cases:

Use Case 1: Prioritizing the Best Quality

If you want to capture using the best possible combination of features, you can provide a prioritized list. CameraX will attempt to enable them in order, selecting the first combination the device fully supports.

val sessionConfig = SessionConfig(
    useCases = listOf(preview, videoCapture),
    preferredFeatureGroup = listOf(
        GroupableFeature.HDR_HLG10,
        GroupableFeature.FPS_60,
        GroupableFeature.PREVIEW_STABILIZATION
    )
).apply {
    // (Optional) Get a callback with the enabled features to update your UI.
    setFeatureSelectionListener { selectedFeatures ->
        updateUiIndicators(selectedFeatures)
    }
}
processCameraProvider.bindToLifecycle(activity, cameraSelector, sessionConfig)

In this example, CameraX tries to enable features in this order:

1. HDR + 60 FPS + Preview Stabilization

2. HDR + 60 FPS

3. HDR + Preview Stabilization

4. HDR

5. 60 FPS + Preview Stabilization

6. 60 FPS

7. Preview Stabilization

8. None

Use Case 2: Building a User-Facing Settings UI

You can now accurately reflect which feature combinations are supported in your app's settings UI, disabling toggles for unsupported options like the picture below.

To determine whether to gray out a toggle, use the following codes to check for feature combination support. Initially, query the status of every individual feature. Once a feature is enabled, re-query the remaining features with the enabled features to see if their toggles must now be grayed out due to compatibility constraints.

fun disableFeatureIfNotSuported(
   enabledFeatures: Set<GroupableFeature>,     
   featureToCheck:GroupableFeature
) {
 val sessionConfig = SessionConfig(
     useCases = useCases,
     requiredFeatureGroup = enabledFeatures + featureToCheck
 )
 val isSupported = cameraInfo.isFeatureGroupSupported(sessionConfig)

 if (!isSupported) {
     // disable the toggle for featureToCheck
 }
}

Please refer to the Feature Group blog post for more information.

More Video Enhancements

• Concurrent Camera Improvements: With CameraX 1.5.1, you can now bind Preview + ImageCapture + VideoCapture use cases concurrently for each SingleCameraConfig in non-composition mode. Additionally, in composition mode (same use cases with CompositionSettings), you can now set the CameraEffect that is applied to the final composition result.

• Dynamic Muting: You can now start a recording in a muted state using PendingRecording.withAudioEnabled(boolean initialMuted) and allow the user to unmute later using Recording.mute(boolean muted).

• Improved Insufficient Storage Handling: CameraX now reliably dispatches the VideoRecordEvent.Finalize.ERROR_INSUFFICIENT_STORAGE error, allowing your app to gracefully handle low storage situations and inform the user.

• Low Light Boost: On supported devices (like the Pixel 10 series), you can enable CameraControl.enableLowLightBoostAsync to automatically brighten the preview and video streams in dark environments.

Professional-Grade Image Capture

CameraX 1.5 brings major upgrades to ImageCapture for developers who demand maximum quality and flexibility.

Unleash Creative Control with DNG (RAW) Capture

For complete control over post-processing, CameraX now supports DNG (RAW) capture. This gives you access to the unprocessed, uncompressed image data directly from the camera sensor, enabling professional-grade editing and color grading. The API supports capturing the DNG file alone, or capturing simultaneous JPEG and DNG outputs. See the sample code below for how to capture JPEG and DNG files simultaneously.

val capabilities = ImageCapture.getImageCaptureCapabilities(cameraInfo)
val imageCapture = ImageCapture.Builder().apply {
    if (capabilities.supportedOutputFormats
             .contains(OUTPUT_FORMAT_RAW_JPEG)) {
        // Capture both RAW and JPEG formats.
        setOutputFormat(OUTPUT_FORMAT_RAW_JPEG)
    }
}.build()
// ... bind imageCapture to lifecycle ...


// Provide separate output options for each format.
val outputOptionRaw = /* ... configure for image/x-adobe-dng ... */
val outputOptionJpeg = /* ... configure for image/jpeg ... */
imageCapture.takePicture(
    outputOptionRaw,
    outputOptionJpeg,
    executor,
    object : ImageCapture.OnImageSavedCallback {
        override fun onImageSaved(results: OutputFileResults) {
            // This callback is invoked twice: once for the RAW file
            // and once for the JPEG file.
        }

        override fun onError(exception: ImageCaptureException) {}
    }
)

Ultra HDR for Camera Extensions

Get the best of both worlds: the stunning computational photography of Camera Extensions (like Night Mode) combined with the brilliant color and dynamic range of Ultra HDR. This feature is now supported on many recent premium Android phones, such as the Pixel 9/10 series and Samsung S24/S25 series.

// Support UltraHDR when Extension is enabled. 

val extensionsEnabledCameraSelector = extensionsManager
     .getExtensionEnabledCameraSelector(
        CameraSelector.DEFAULT_BACK_CAMERA, ExtensionMode.NIGHT)

val imageCapabilities = ImageCapture.getImageCaptureCapabilities(
               cameraProvider.getCameraInfo(extensionsEnabledCameraSelector)

val imageCapture = ImageCapture.Builder()
     .apply {
       if (imageCapabilities.supportedOutputFormats
                .contains(OUTPUT_FORMAT_JPEG_ULTRA_HDR) {
           setOutputFormat(OUTPUT_FORMAT_JPEG_ULTRA_HDR)

       }

     }.build()

Core API and Usability Enhancements

A New Way to Configure: SessionConfig

As seen in the examples above, SessionConfig is a new concept in CameraX 1.5. It centralizes configuration and simplifies the API in two key ways:

1. No More Manual unbind() Calls: CameraX APIs are lifecycle-aware. It will implicitly "unbind" your use cases when the activity or other LifecycleOwner is destroyed. But updating use cases or switching cameras still requires you to call unbind() or unbindAll() before rebinding. Now with CameraX 1.5, when you bind a new SessionConfig, CameraX seamlessly updates the session for you, eliminating the need for unbind calls.

2. Deterministic Frame Rate Control: The new SessionConfig API introduces a deterministic way to manage the frame rate. Unlike the previous setTargetFrameRate, which was only a hint, this new method guarantees the specified frame rate range will be applied upon successful configuration. To ensure accuracy, you must query supported frame rates using CameraInfo.getSupportedFrameRateRanges(SessionConfig). By passing the full SessionConfig, CameraX can accurately determine the supported ranges based on stream configurations.

Camera-Compose is Now Stable

We know how much you enjoy Jetpack Compose, and we're excited to announce that the camera-compose library is now stable at version 1.5.1! This release includes critical bug fixes related to CameraXViewfinder usage with Compose features like moveableContentOf and Pager, as well as resolving a preview stretching issue. We will continue to add more features to camera-compose in future releases.

ImageAnalysis and CameraControl Improvements

• Torch Strength Adjustment: Gain fine-grained control over the device's torch with new APIs. You can query the maximum supported strength using CameraInfo.getMaxTorchStrengthLevel() and then set the desired level with CameraControl.setTorchStrengthLevel().

• NV21 Support in ImageAnalysis: You can now request the NV21 image format directly from ImageAnalysis, simplifying integration with other libraries and APIs. This is enabled by invoking ImageAnalysis.Builder.setOutputImageFormat(OUTPUT_IMAGE_FORMAT_NV21).

Get Started Today

Update your dependencies to CameraX 1.5 today and explore the exciting new features. We can't wait to see what you build.

To use CameraX 1.5, please add the following dependencies to your libs.versions.toml. (We recommend using 1.5.1 which contains many critical bug fixes and concurrent camera improvements.)

[versions]

camerax = "1.5.1"


[libraries]

..

androidx-camera-core = { module = "androidx.camera:camera-core", version.ref = "camerax" }

androidx-camera-compose = { module = "androidx.camera:camera-compose", version.ref = "camerax" }

androidx-camera-view = { module = "androidx.camera:camera-view", version.ref = "camerax" }

androidx-camera-lifecycle = { group = "androidx.camera", name = "camera-lifecycle", version.ref = "camerax" }

androidx-camera-camera2 = { module = "androidx.camera:camera-camera2", version.ref = "camerax" }

androidx-camera-extensions = { module = "androidx.camera:camera-extensions", version.ref = "camerax" }

And then add these to your module build.gradle.kts dependencies:

dependencies {

  ..

  implementation(libs.androidx.camera.core)
  implementation(libs.androidx.camera.lifecycle)

  implementation(libs.androidx.camera.camera2)

  implementation(libs.androidx.camera.view) // for PreviewView 
  implementation(libs.androidx.camera.compose) // for compose UI

  implementation(libs.androidx.camera.extensions) // For Extensions 

}

Have questions or want to connect with the CameraX team? Join the CameraX developer discussion group or file a bug report:

• CameraX developers discussion group

• File a bug

13 Nov 2025 5:00pm GMT

Posted by Robbie McLachlan, Developer Marketing

In our latest #WeArePlay stories, we meet the game creators who entertain, inspire and spark imagination in players around the world on Google Play. From delivering action-packed 3D kart racing to creating a calming, lofi world for plant lovers - here are a few of our favourites:

Ralf and Matt, co-founders of Vector Unit

San Rafael (CA), U.S.

With over 557 million downloads, Ralf and Matt's game, Beach Buggy Racing, brings the joy of classic, action-packed kart racing to gamers worldwide.

After meeting at a California game company back in the late '90s, Matt and Ralf went on to work at major studios. Years later, they reunited to form Vector Unit, a new company where they could finally have full creative freedom. They channeled their passion for classic kart-racers into Beach Buggy Racing, a vibrant 3D title that brought a console-quality feel to phones. The fan reception was immense, with players celebrating by baking cakes and dressing up for in-game events. Today, the team keeps Beach Buggy Racing 2 updated with global collaborations and is already working on a new prototype, all to fulfill their mission: sparking joy.

Camilla, founder of Clover-Fi Games

Batangas, Philippines

Camilla's game, Window Garden, lets players slow down by decorating and caring for digital plants.

While living with her mother during the pandemic, tech graduate Camilla made the leap from software engineer to self-taught game developer. Her mom's indoor plants sparked an idea: Window Garden. She created the lofi idle game to encourage players to slow down. In the game, players water flowers and fruits, and decorate cozy spaces in their own style. With over 1 million downloads to date, this simple loop has become a calming daily ritual since its launch. The game's success earned it a "Best of 2024" award from Google Play, and Camilla now hopes to expand her studio and collaborate with other creatives.

Rodrigo, founder of Kolb Apps

Curitiba, Brazil

Rodrigo's game, Real Drum, puts a complete, realistic-sounding virtual drum set in your pocket, making it easy for anyone to play.

Rodrigo started coding at just 12 years old, creating software for his family's businesses. This technical skill later combined with his hobby as an amateur musician. While pursuing a career in programming, he noticed a clear gap: there were no high-quality percussion apps. He united his two passions, technology and rhythm, to create Real Drum. The result is a realistic, easy-to-use virtual set that has amassed over 437 million downloads, letting people around the world play drums and cymbals without the noise. His game has made learning music accessible to many and inspired new artists. Now, Rodrigo's team plans to launch new apps for children to continue nurturing musical creativity.

Discover other inspiring app and game founders featured in #WeArePlay.

13 Nov 2025 5:00pm GMT

Posted by Matthew Forsythe Director - Product Management, Android App Safety

12 Nov 2025 11:47pm GMT

Posted by Karan Jhavar - Product Manager, Android Frameworks, Dan Brown - Product Manager, Google Play, and Eric Brenner - Software Engineer, Google Play

A great user experience is built on a foundation of strong technical performance. We are committed to helping you create stable, responsive, and efficient apps that users love. Excessive battery drain is top of mind for your users, and together, we are taking significant steps to help you build more power-efficient apps.

Earlier this year, we introduced a new beta metric in Android vitals, excessive partial wake locks, to help you identify and address sources of battery drain. This initial beta metric was co-developed in close collaboration with Samsung, combining their deep, real-world insights into user experience with battery consumption with Android's platform data.

We want to thank you for providing invaluable feedback during the beta period. Powered by your input and our continued collaboration with Samsung, we have further refined the algorithm to be even more accurate and representative. We are excited to announce that this refined metric is now generally available as a new core vitals metric to all developers in Android vitals.

We have defined a bad behavior threshold for excessive wake locks. Starting March 1, 2026, if your title does not meet this quality threshold, we may exclude the title from prominent discovery surfaces such as recommendations. In some cases, we may display a warning on your store listing to indicate to users that your app may cause excessive battery drain.

GOOGLE PLAY'S CORE TECHNICAL QUALITY METRICS To maximize visibility on Google Play, keep your app below the bad behavior thresholds for these metrics.
User-perceived crash rate	The percentage of daily active users who experienced at least one crash that is likely to have been noticeable
User-perceived ANR rate	The percentage of daily active users who experienced at least one ANR that is likely to have been noticeable
Excessive battery usage	The percentage of watch face sessions where battery usage exceeds 4.44% per hour
New: Excessive partial wake locks	The percentage of user sessions where cumulative, non-exempt wake lock usage exceeds 2 hours

Excessive partial wake locks newly join the technical quality bars that Play expects all titles to maintain for a great user experience

This is the first in a series of new metrics designed to provide deeper insight into your app's resource utilization, enabling you to improve the experience for your users across the entire Android ecosystem.

1. Aligning our definition of excessive wake locks with user expectations

Apps can hold wake locks to prevent the user's device from entering sleep mode, letting the apps perform background work while the screen is off.

We consider a user session excessive if it holds more than 2 cumulative hours of non-exempt wake locks in a 24 hour period. These excessive sessions are a heavy contributor to battery drain. A wake lock is exempted if it is a system held wake lock that offers clear user benefits that cannot be further optimized, such as audio playback or user-initiated data transfer.

The bad behaviour threshold is crossed when 5% of an app's user sessions over the last 28 days are excessive. If your app exceeds this threshold, you will be alerted directly on your Android vitals overview page. You can read more information about our definition on the Android Developer pages.

Android vitals will alert you to excessive wake lock issues and provide a table of wake lock tags to P90/ P99 duration to help you identify the source by wake lock name.

To help you understand your app's partial wake lock usage, we are enhancing the excessive partial wake locks page in Android vitals with a new wake lock names table. This table breaks down wake lock sessions by their specific tag names and durations, allowing you to easily identify long wake locks in your local development environment, like Android Studio, for easier debugging. You should investigate any wake locks with P90 or P99 durations above 60 minutes.

2. Excessive wake locks and their impact on Google Play visibility

If your title exceeds the bad behavior threshold for excessive wake locks, it may be ineligible for some discovery surfaces where users find new apps and games.

In some cases, we may also show a warning on your store listing to inform users that your app may cause their device's battery to drain faster.

Users may see a warning on your store listing if your app exceeds the bad behavior threshold. Note: The exact text and design are subject to change.

We know making technical changes to your app's code and how it works can be time consuming, so we are making the metric available for you to diagnose and fix potential issues now, with time before the Store visibility changes begin, starting from March 1, 2026.

3. What to do next

We encourage you to take the following steps to ensure your app delivers a great experience for users:

1. Visit Android vitals: Review your app's performance on the new excessive partial wake locks metric. The metric is now visible to all developers whose apps have wake lock sessions.

2. Discover excessive partial wake locks: Use the new wake lock names table to identify excessive partial wake locks.

3. Consult the documentation: For detailed guidance on best practices and fixing common issues, please check out our technical blog post, technical video and updated developer documentation on wake locks.

Thank you for your continued partnership in building high-quality, performant experiences that users can rely on every day.

10 Nov 2025 10:00pm GMT