New insights into app quality issues and recommendations
For now, app compatibility issues, bad behaviors, and some UX recommendations are shown. We will continue to detect and surface more quality issues and provide more recommendations in the coming year.
Use Android vitals to help you understand and improve your app’s stability, performance, battery usage, and more.
Choose how to access your app's data
There are two ways for you to use Android vitals: through Play Console and Play Developer Reporting API.
The API provides programmatic access to Android vitals for developers who want to integrate Android vitals data with other datasets or build it into their workflows. To learn more about using an API to access Android vitals, go to the Google Play Developer Reporting API page.
To find and review your app's Android vitals data in Play Console:
- Open Play Console and go to the Android vitals overview page (Quality > Android Vitals > Overview).
- Choose the range of data that you’d like to see using the date range selector in the upper right.
Important: If no data is available, your app doesn't have enough data points within the specified filters to identify any issues.
Monitor your app's core vitals
At the top of the Android vitals overview page, you can see data on your app’s core vitals. These are the most important technical metrics and affect the discoverability of your app on Google Play. The core vitals include:
Google Play defines bad behavior thresholds on these metrics. If your app exceeds these thresholds, it’s likely to be less discoverable on Google Play. In some cases, a warning could be shown on your app's store listing to set user expectations.
You can use the "Critical issues" section to quickly identify areas where your app can improve. There are two types of critical issues:
- Bad behaviors: Metrics that exceed bad behavior thresholds
- Anomalies: Significant changes in data (for example, a sharp increase in the user-perceived ANR rate)
To receive email notifications, visit Setup > Notifications or click Manage notifications in the corner of the "Core vitals" section (Quality > Android vitals > Overview). Note that notifications are currently only available for anomalies.
Browse all vitalsNear the middle of the Android vitals overview page, you can view data on all vitals by aspect of quality.
In the table, you can review your metrics for the current and previous time periods. You can also see how your app compares to other apps on Google Play.
For additional details about a metric, select the View details () next to it. On the next screen, you can review:
- Bad behavior thresholds
- Category benchmarks
- Detailed benchmark comparisons
- Near the top of the page, in the peer comparison card, select Edit peer group to edit a custom peer group. After you create a custom peer group, you can see how your app compares with other apps on Google Play that you select.
- Metric trend over time
To help you organize, segment, and analyze your data, your metrics are broken down by a number of different dimensions. All metrics have the following breakdowns:
- Artifact: The version of your app on which the issue occurred
- Android version (SDK): Android OS version reported by the user's device
- Form factor: The type of device on which the app was run (for example, Phone, Tablet, TV, Wearable)
- Device model: A high-level description of the device, consisting of a unique brand and device identifier, for example, "Google oriole." A single device model may have variants with different Android versions, RAM, storage, or System on Chip (SoC).
- Country/region: The location reported by the user’s device at the time of the issue
Tip: For breakdowns by specific aspects of device hardware or software (for example, device model or Android version), you can click the symbol () next to the item in the table.
Some metrics have additional breakdowns:
- Wake lock name: Tags that were programmatically set when using the PowerManager API in your app
- Wake-up name: Tags that were programmatically set when using the AlarmManager API in your app
- ANR activity name: Fully qualified name of the activity class where the ANR occurred (if available)
- ANR type: When the ANR occurred (for example, while executing a service) (if available)
You can view more details when available (for example the crash or ANR clusters associated with that breakdown) by selecting View details () next to the item.
Tip: You can switch between metrics in a single category using the toggle at the top of the screen, and filter the page.
Data types and metrics
Android vitals data is available for the previous 90 days in Play Console and for three years in the Play Developer Reporting API.
Data is collected from users who have opted in to automatically share usage and diagnostics data from a subset of Android devices and OS versions. For more information about how Android users opt in to share data, go to the Accounts Help Center.
Android vitals is updated daily. Sometimes data for Android 10+ devices can arrive earlier than data for devices below Android 10. If this happens, you will see Android 10+ data available for days where only it is available.
Note: Android vitals metrics exclude technical issues that occur on uncertified device models, or on versions of your app that were not installed through Google Play.
Stability
ANR rate metricsANR rate metrics provide an overview of your app’s quality. These metrics are calculated by taking the number of users with ANRs you have and normalizing them based on your app usage. They are reported as a percentage of daily active users, where a daily active user is defined as a user using the app in a single day on a single device. If a user uses your app on more than one device in a single day, each device will contribute to the number of active users for that day. If multiple users use the same device in a single day, this is counted as one active user.
There are three ANR rate metrics:
- User-perceived ANR rate: The percentage of your daily active users who experienced at least one user-perceived ANR. A user-perceived ANR is an ANR that is likely to have been noticed by the user. Currently, only "input dispatching timed out" ANRs are counted. This metric will always be lower than your overall ANR rate, because it is normalized by daily usage, but doesn’t count all ANRs.
User-perceived ANR rate is a core vital, meaning that it affects the discoverability of your app on Google Play. It is important because the ANRs it counts always occur when the user is engaged with the app, causing the most disruption.
- ANR rate: The percentage of your daily users who experienced at least one ANR. This metric includes ANRs that are not classified as user-perceived, but we cannot guarantee that these ANRs are not affecting users.
- Multiple-ANR rate: The percentage of your daily users who experienced at least two ANRs. This metric helps highlight issue loops.
Fix an issue
The ANRs that contribute to your ANR rate metrics are reported on the Crashes and ANRs page. You can filter for user-perceived ANRs on this page.
The Android Developers site provides guidance on diagnosing and fixing ANRs.
Crash rate metrics provide an overview of your app’s quality. These metrics are calculated by taking the number of users with crashes you have and normalizing them based on your app usage. They are reported as a percentage of daily users, where a daily user is defined as a user using the app in a single day on a single device. If a user has more than one device, the user will be counted more than once. For example, if two users use the app for two days on one device each, it will produce four daily sessions.
There are three crash rate metrics:
- User-perceived crash rate: The percentage of your daily users who experienced at least one user-perceived crash. A user-perceived crash is a crash that is likely to have been noticed by the user. For example, crashes that happen when your app is displaying an activity or running as a foreground service. This metric will always be lower than your overall crash rate, because it is normalized by daily usage, but doesn’t count all crashes.
User-perceived crash rate is a core vital, meaning that it affects the discoverability of your app on Google Play. It is important because the crashes it counts always occur when the user is engaged with the app, causing the most disruption. This is why you should ensure that your app does not exceed the bad behavior threshold for this metric.
-
Crash rate: The percentage of your daily users who experienced at least one crash. This metric includes crashes that are not classified as user-perceived, but we cannot guarantee that these crashes are not affecting users.
-
Multiple-crash rate: The percentage of your daily users who experienced at least two crashes. This metric helps highlight issue loops.
Fix an issue
The Android Developers site provides guidance on diagnosing and fixing crashes.
Start-up and loading times
Start-up time (time to initial display)On the Start-up time page, you can see details about when your app starts slowly from cold, warm, and hot system states. Start-up time measures the time it takes from when a user launches your app, to when the first frames appear on the screen. This is also known as 'time to initial display'.
Your app may not be ready for the user to start interacting with it after this time, for example, if your app has additional loading screens.
Data collection details
- Start-up times are only recorded when a user triggers an activity.
- Example: For keyboard apps, the start-up time is equal to the startup time of the companion app.
- If an app starts multiple times on the same day from the same system state, the day’s maximum start-up time is recorded.
- Start-up times are tracked when the app’s first frame completely loads, even if it isn’t a screen that users interact with.
- Example: If an app starts with a splash screen, the startup time equals the time required to display the splash screen.
Vital details
- Impacted sessions: Percentage of sessions during which users experienced a slow start-up time for each respective system state:
- Slow cold start: 5 seconds or more
- Slow warm start: 2 seconds or more
- Slow hot start: 1 second or more
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 10%/1% of daily sessions where users experienced slow app start time for your app.
Fix an issue
If your app has a high number of slow app start-up times, go to the Android Developers site for recommended solutions.
Rendering
All rendering
Slow session rate (30 FPS or 20 FPS) [games only]Why this is important
Using slow sessions you can understand the frame rate performance of your game, which impacts how smooth and fluid your game feels to users.
Understand your app's data
On the Slow sessions page, you'll see details about the percentage of daily sessions where users experienced more than 25% of frames running slower than either 30 FPS or 20 FPS, depending on which benchmark you select. You can also see the distribution of sessions by frame rate for your game. (Session-level frame rate is measured at the 75th percentile, meaning that 75% of frames achieve at least this frame rate.)
Most games on Google Play should aim for 30 FPS or higher. This provides a reasonable experience for users, regardless of what type of game they're playing (though some users will prefer at least 60 FPS, especially on higher-end devices). Monitor the slow session rate (30 FPS) metric to ensure you're achieving this bar. Keep in mind that this metric only includes sessions where more than 25% of frames are missing 30 FPS so it has some tolerance for frame rate variability.
While 30 FPS provides a reasonable experience, there may be times or types of games where it makes sense to drop the frame rate below this, or users may want to play your game on phones that cannot support 30 FPS. In these scenarios, at least 75% of frames in a session should still achieve 20 FPS or higher. Monitor the slow session rate (20 FPS) metric to ensure you're meeting this bar.
Android vitals reports slow sessions (30 FPS) and slow sessions (20 FPS) for each device as well as across all devices and sessions. Use the overall metric to understand your overall user experience, but pay attention to per-device performance as well. In due course, Play will start steering users away from games that cannot achieve 20 FPS on their phones.
Vitals only begins monitoring frame rate after your game has been running for 1 minute.
Data collection details
The slow sessions metric is computed with data collected from SurfaceFlinger. More concretely, the frame rate of a session is estimated based on the time in between frames drawn on surfaces owned by the app, and it includes frames rendered by OpenGL, Vulkan, as well as Android UI toolkit. This metric is currently only available for games.
Frame rate data for Slow Sessions are collected for devices running Android 9 and later.
Dashboard display
- Representative frame rate: The frame rate performance of your game on devices with Android 9 or later, calculated at the 75th percentile. This means 75% of the sessions had this frame rate or faster 75% of the time.
- Slow session rate over time: A time series showing the percentage of sessions determined to be Slow sessions.
- Distribution of frame rate: Histogram showing the 75th percentile frame rate across sessions. This means that 75% of the frames in a session were faster than the frame rate used to bucket the session.
Fix an issue
If your app has a high number of Slow sessions, go to the Android developers site for recommended solutions.
Android UI toolkit rendering
Excessive slow frames [apps only]Understand your app's data
On the Excessive slow frames page, you'll see details about the percentage of daily sessions where users experienced more than 50% of frames missing the device’s drawing deadline. User interactions with your app should run at 60 frames per second without any dropped or delayed frames.
Data collection details
Google collects the render time of each frame rendered by your app when using the UI Toolkit framework. Frames rendered using OpenGL or Vulkan directly are not collected.
Dashboard display
When you select a row, you'll see the data broken down into percentiles.
- Impacted sessions: Percentage of daily sessions where users experienced more than 50% of frames with a render time greater than 16 ms. A daily session refers to a day during which your app was used. For example, if two users use the app for two days, it will produce four daily sessions.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 90%/99% of the total frames had a render time lower than the number shown. These numbers are based on all collected frames.
When you click an entry in the table, you'll see the 'Distribution of UI render time' chart. When reviewing the chart, you'll want to make sure that the majority of your app's frames are at or below 16 ms.
The data below the chart conveys the rendering performance of the app and may help you find the root cause of any issues with render time. For example, if your 'High input latency' percentage is high, you may want to look at your app's code that handles user input. For more information on these metrics, go to testing UI performance.
- Missed Vsyncs: For all frames rendered in more than 16 ms, number of missed Vsync events divided by the number of frames.
- High input latency: For all frames rendered in more than 16 ms, number of input events that took more than 24 ms divided by the number of frames.
- Slow UI thread: For all frames rendered in more than 16 ms, number of times that the UI thread took more than 8 ms to complete divided by the number of frames.
- Slow draw commands: For all the frames rendered in more than 16 ms, number of times when sending draw commands to the GPU took more than 12 ms divided by the number of frames.
- Slow bitmap uploads: For all the frames rendered in more than 16 ms, number of times when the bitmap took more than 3.2 ms to upload to the GPU divided by the number of frames.
Fix an issue
If your app has a high number of frames with a render time greater than 16 ms, go to the Android developers site for recommended solutions.
Understand your app's data
On the Excessive slow frames page, you'll see details about the percentage of daily sessions where users experienced more than 50% of frames missing the device’s drawing deadline. User interactions with your app should run at 60 frames per second without any dropped or delayed frames.
Data collection details
Google collects the render time of each frame rendered by your app when using the UI Toolkit framework. Frames rendered using OpenGL or Vulkan directly are not collected.
Dashboard display
When you select a row, you'll see the data broken down into percentiles.
- Impacted sessions: Percentage of daily sessions where users experienced more than 50% of frames with a render time greater than 16 ms. A daily session refers to a day during which your app was used. For example, if two users use the app for two days, it will produce four daily sessions.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 90%/99% of the total frames had a render time lower than the number shown. These numbers are based on all collected frames.
When you click an entry in the table, you'll see the 'Distribution of UI render time' chart. When reviewing the chart, you'll want to make sure that the majority of your app's frames are at or below 16 ms.
The data below the chart conveys the rendering performance of the app and may help you find the root cause of any issues with render time. For example, if your 'High input latency' percentage is high, you may want to look at your app's code that handles user input. For more information on these metrics, go to testing UI performance.
- Missed Vsyncs: For all frames rendered in more than 16 ms, number of missed Vsync events divided by the number of frames.
- High input latency: For all frames rendered in more than 16 ms, number of input events that took more than 24 ms divided by the number of frames.
- Slow UI thread: For all frames rendered in more than 16 ms, number of times that the UI thread took more than 8 ms to complete divided by the number of frames.
- Slow draw commands: For all the frames rendered in more than 16 ms, number of times when sending draw commands to the GPU took more than 12 ms divided by the number of frames.
- Slow bitmap uploads: For all the frames rendered in more than 16 ms, number of times when the bitmap took more than 3.2 ms to upload to the GPU divided by the number of frames.
Fix an issue
If your app has a high number of frames with a render time greater than 16 ms, go to the Android developers site for recommended solutions.
Battery usage
Stuck wake locks and stuck partial wake locks (background)The Stuck partial wake locks and Stuck partial wake locks (background) pages show partial wake locks acquired by your app through the PowerManager class. A partial wake lock ensures the CPU is running but the screen and keyboard backlight will be allowed to turn off.
Data collection details
- For privacy purposes, partial wake lock identification tags are anonymized.
- Data about partial wake locks is collected when the device is not charging and the screen is off.
- Stuck partial wake locks data (background) is only collected when the app is running in the background.
- Google computes the maximum partial wake lock duration per battery session to show how many sessions are impacted by a long wake lock. For example, if a user triggers two-hour-long wake locks, Google will use a maximum wake lock value of one hour.
- For apps that set the
sharedUserIdin the manifest file: You'll only see data if a maximum of one app with the samesharedUserIdis installed.
Vital details
- Impacted sessions: Percentage of battery sessions where users experienced at least one wake lock of more than one hour.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 10%/1% of daily sessions where users experienced partial wake lock durations greater than the number shown.
- Bad behavior threshold: If your app exhibits a rate of occurrence equal to or higher than the threshold shown, it's in the bottom 25% of the top 1,000 apps on Google Play (by number of installs).
Fix an issue
If your app has a high number of stuck partial wake locks, go to the Android Developers site for recommended solutions.
The Excessive wake-ups page shows the Alarm Manager wake-ups triggered by your app. You'll see wake-up data for the classes ELAPSED_REALTIME_WAKEUP or RTC_WAKEUP.
Data collection details
- For privacy purposes, wake-up identification tags are anonymized.
- Wake-ups are collected when the device is not charging.
- To provide a normalized metric, the number of wake-ups is compared to the time the device is on battery. Google computes the number of wake-ups per user per hour to show how many users are impacted by a high wake-up rate.
- For apps that set the
sharedUserIdin the manifest file: You'll only see data if a maximum of one app with the samesharedUserIdis installed.
Vital details
- Impacted sessions: Percentage of battery sessions where users experienced more than 10 wake-ups per hour. A battery session is the aggregation of all battery reports received within a given 24-hour period. In Android 10, a battery report refers to the interval between two battery charges either from below 20% to above 80 or from any value to 100%. In Android 11 and above, a battery report refers to a fixed 24-hour period. Google collects the data only when the device is off its charger.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 10%/1% of daily sessions where users experienced wake-ups per hour greater than the value shown.
- Bad behavior threshold: If your app exhibits a rate of occurrence equal to or higher than the threshold shown, it's in the bottom 25% of the top 1,000 apps on Google Play (by number of installs).
Fix an issue
If your app has frequent wake-ups, go to the Android Developers site for recommended solutions.
The Excessive Wi-Fi scans (background) page shows when Wi-Fi scans are resulting in high battery usage.
Data collection details
Data about Wi-Fi scanning is collected when the device is not charging and the app is in the background.
Vital details
- Impacted sessions: Percentage of battery sessions where users experienced more than 4 Wi-Fi scans per hour.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 10%/1% of daily sessions where users experienced more hourly Wi-Fi scans in the background than the number shown.
Fix an issue
If your app has a high number of background Wi-Fi scans, go to the Android Developers site for recommended solutions.
The Excessive network usage page shows when a large amount of network data is associated with a background service. When mobile network usage happens in the background, your users don't have easy access to controls to stop the data transfer.
Data collection details
Data about mobile network usage is collected when the device is not charging and the app is in the background.
Vital details
- Impacted sessions: Percentage of battery sessions where users experienced more than 50 MB of network usage in the background per day.
- Number of sessions: Approximate number of recorded sessions.
- 90th/99th percentile: 10%/1% of daily sessions where users experienced greater daily network usage in the background than the number shown.
Fix an issue
If your app has a high background network usage, go to the Android Developers site for recommended solutions.
Permissions
Permission denialsOn the Permission denials page, you can see details about the percentage of daily permission sessions during which users denied permissions. A daily permission session refers to a day during which your app requests at least one permission from its user.
Data collection details
Data about permission denials is collected when users respond to requests for permissions within your app.
Vital details
- Denials: Percentage of daily permission sessions during which users denied permissions.
- Never ask again: Percentage of daily permission sessions during which users denied permissions by selecting Never ask again.
- Total sessions: Approximate number of recorded sessions.
Fix an issue
If your app has a high number of permissions denials, go to the Android Developers site for recommended solutions.
Bad behavior thresholds for core vitals
Google Play has defined bad behavior thresholds on your app's core vitals.
If your app exceeds a bad behavior threshold, it’s likely to be less discoverable on Google Play. If your app has bad behavior on specific device models, Google Play will steer users on those devices away from these titles and towards others that are more suitable for them. In some cases, a warning may be displayed on your app's store listing to set user expectations and provide the option to seek out alternatives with higher technical quality.
Google Play will generally consider the last 28 days of data when evaluating your app's quality but may act sooner in the event of a spike.
Stability
User-perceived ANR rate thresholdsGoogle Play has defined bad behavior thresholds on user-perceived ANR rate:
-
Overall bad behavior: At least 0.47% of daily active users experience a user-perceived ANR across all device models.
-
Per-device bad behavior: At least 8% of daily active users experience a user-perceived ANR for a single-device model.
To improve your ANR rate, fix the underlying ANR clusters that are reported on the Crashes and ANRs page. The higher the number of affected users, the more that cluster contributes to your ANR rate.
If specific aspects of device hardware or software might be contributing to your ANR rate, Android vitals will notify you. You can also explore associations yourself on the Reach and devices overview page (Monitor and improve > Reach and devices > Overview).
Google Play has defined bad behavior thresholds on user-perceived crash rate:
-
Overall bad behavior: At least 1.09% of daily users experience a user-perceived crash, across all device models.
-
Per-device bad behavior: At least 8% of daily users experience a user-perceived crash, for a single device model.
To improve your crash rate, fix the underlying crash clusters that are reported on the Crashes and ANRs page. The higher the number of affected users, the more that cluster contributes to your crash rate.
If specific aspects of device hardware or software might be contributing to your crash rate, Android vitals will notify you. You can also explore associations for yourself on the Reach and devices overview page (Monitor and improve > Reach and devices > Overview).
Related content
Discover best practices for using Android vitals to improve your app's performance and stability.