Monitor your app's technical quality with Android vitals

For additional details about a metric, select the View details () next to it. On the next screen, you can review:

• Bad behaviour 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

ANR rate metrics provide an overview of your app’s quality. These metrics are calculated by taking the number of users with ANRs that you have and normalising 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 normalised 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 that 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 that you have and normalising 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 normalised 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 that 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 behaviour 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.

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 start-up 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 start-up 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.

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 that you're achieving this bar. Bear 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 that 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 one 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 that 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.

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.

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 that 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 anonymised.
• 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 sharedUserId in the manifest file: you'll only see data if a maximum of one app with the same sharedUserId is 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 behaviour 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 anonymised.
• Wake ups are collected when the device is not charging.
• To provide a normalised metric, the number of wake ups is compared to the time that 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 sharedUserId in the manifest file: you'll only see data if a maximum of one app with the same sharedUserId is 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 behaviour 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 four 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.

On 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.

Google Play has defined bad behaviour thresholds on user-perceived ANR rate:

• Overall bad behaviour: At least 0.47% of daily active users experience a user-perceived ANR across all device models.

• Per-device bad behaviour: 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 (Release > Reach and devices > Overview).

Google Play has defined bad behaviour thresholds on user-perceived crash rate:

• Overall bad behaviour: At least 1.09% of daily users experience a user-perceived crash, across all device models.

• Per-device bad behaviour: 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 ANRspage. 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 (Release > Reach and devices > Overview).