Monitor your app's technical performance with Android vitals

Using the Play Console, you can view data to help you understand and improve your app's battery usage, stability, and render time.

The following 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.

Collapse All Expand All

Data types 

Battery usage
  • Stuck wake locks
  • Stuck wake locks (background)
  • Excessive wakeups
  • Excessive Wi-Fi scans (background)
  • Excessive network usage (background)
Stability
  • ANR rate
  • Multi-ANR rate
  • Crash rate
  • Multi-crash rate
Render time
  • Slow rendering (16ms)
  • Frozen UI frames (700ms)
App startup time
  • Slow cold start
  • Slow warm start
  • Slow hot start
Permissions
  • Permission denials

Find & review your app's data

The date range listed on your Android vitals page includes all available data for your app and can't be customized. Android vitals data is based on Pacific Time (PT).

Important: If no data is available, your app doesn't have enough data points within the specified filters to identify any issues with your app. 

To find and review your app's Android vitals data:

  1. Sign in to your Play Console.
  2. Select an app.
  3. On the left menu, click Android vitals > Overview.
  4. Choose how you want to view your app's data.
Review the overview dashboard and detailed metric pages

Core vitals

At the top of the Overview page, you can see data on your app’s core vitals, which are performance metrics that can affect your app’s visibility and ranking on Google Play. Core vitals include:

  • Stuck partial wake locks (background)
  • Excessive wakeups
  • ANR rate
  • Crash rate

If your app has any critical performance issues that need your attention, including metrics that exceed bad behavior thresholds and major changes in performance data (known as anomalies), you can use this page to quickly identify areas where your app can improve.

Important: For the best user experience, all apps should identify and fix issues to remain below bad behavior thresholds.

Browse all vitals

Near the middle of the Overview page, you can view data on all vitals by data type. To filter the table, choose the dimensions and time period you want to view.

For each metric, you can review your app's percentage of sessions impacted for the current time period and previous time period. You can also review how your app’s data compares to top apps, known as a benchmark comparison.

View detailed metrics

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

  • Anomalies found in performance data (core vitals only)
  • Bad behavior thresholds (core vitals only)
  • Detailed benchmark comparisons
  • Metrics by APK, device, or Android version
    • To view more details, you can expand each row in the tables by selecting the down arrow on the right side.
Filter by bad behaviors

At the top of the Overview page, some metrics may be marked with a red error icon . This means the number shown is high compared to other apps—known as a bad behavior.

Select the card with the icon to see which of your app's APKs includes the bad behavior.

Metric details

Stuck wake locks & stuck wake locks (background)

The Stuck wake locks and Stuck wake locks (background) pages shows 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 background wake locks data 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.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

Fix an issue

If your app has a high number of wakelocks, go to the Android Developers site for recommended solutions.

Excessive wakeups

The Excessive wakeups page shows the Alarm Manager wakeups triggered by your app. You'll see wakeup data for the classes ELAPSED_REALTIME_WAKEUP or RTC_WAKEUP.

Data collection details

  • For privacy purposes, wakeup identification tags are anonymized.
  • Wakeups are collected when the device is not charging.
  • To provide a normalized metric, the number of wakeups is compared to the time the device is on battery. Google computes the number of wakeups 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 wakeups per hour. A battery session is the period between two full charges of a device. Google collects the data only when the device is off charger.
  • Number of sessions: Approximate number of recorded sessions.
  • 90th / 99th percentile: 10% / 1% of daily sessions where users experienced wakeups per hour greater than the value shown.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

Fix an issue

If your app has frequent wakeups, go to the Android Developers site for recommended solutions.

Excessive Wi-Fi scans (background)

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 scan 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.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

Fix an issue

If your app has a high number of background Wi-Fi scans, go to the Android Developers site for recommended solutions. 

Excessive network usage (background)

The Excessive network usage (background) 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 50MB 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.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

Fix an issue

If your app has a high background network usage, go to the Android Developers site for recommended solutions.

ANR rate & multi-ANR rate

Understand your app's data

On the ANR rate and Multi-ANR rate pages, you'll see data similar to what's shown on your app's ANRs & Crashes page. On the Android vitals page, ANR data is combined with usage data to create a normalized metric.

ANR rate details

  • Impacted sessions: Percentage of daily sessions where users experienced at least one ANR. 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.
  • ANR-free sessions: Percentage of daily sessions where users didn't experience any ANRs. A daily session refers to a day during which your app was used.
  • Number of sessions: Approximate number of recorded sessions.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 
  • Related ANRs: To view real-time ANR details, select the ANRs link. You will be taken to the ANRs & Crashes page within your Play Console.

Multi-ANR rate details

  • Impacted sessions: Percentage of daily sessions where users experienced at least two ANRs. 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.
  • Unimpacted sessions: Percentage of daily sessions where users experienced one ANR or fewer. A daily session refers to a day during which your app was used.
  • Number of sessions: Approximate number of recorded sessions.
  • Related ANRs: To view real-time ANR details, select the ANRs link. You will be taken to the ANRs & Crashes page within your Play Console.

Fix an issue

If your app has a high number of ANRs, go to the Android Developers site for recommended solutions.

Crash rate & multi-crash rate

Understand your app's data

On the Crash rate and Multi-crash rate pages, you'll see data similar what's shown on your app's ANRs & Crashes page. On the Android vitals page, crash data is combined with usage data to create a normalized metric.

Crash rate details

  • Impacted sessions: Percentage of daily sessions where users experienced at least one crash. 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.
  • Crash-free sessions: Percentage of daily sessions where users didn't experience any crashes. A daily session refers to a day during which your app was used.
  • Number of sessions: Approximate number of recorded sessions.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 
  • Related Crashes: To view real-time crash details, select the Crashes link. You will be taken to the ANRs & Crashes page within your Play Console.

Multi-crash rate details

  • Impacted sessions: Percentage of daily sessions where users experienced at least two crashes. 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.
  • Unimpacted sessions: Percentage of daily sessions where users experienced one crash or fewer. A daily session refers to a day during which your app was used.
  • Number of sessions: Approximate number of recorded sessions.
  • Related Crashes: To view real-time crash details, select the Crashes link. You will be taken to the ANRs & Crashes page within your Play Console.

Fix an issue

If your app has a high number of crashes, go to the Android Developers site for recommended solutions.

Slow rendering

Understand your app's data

On the Slow rendering page, you'll see details about the percentage of daily sessions where users experienced more than 50% of frames with a render time greater than 16ms. 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, not when using OpenGL directly.

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 16ms. 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.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

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 the majority of your app's frames are below 16ms.

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 Vsync: For all frames rendered in more than 16ms, number of missed Vsync events divided by number of frames.
  • High input latency: For all frames rendered in more than 16ms, number of input events that took more than 24ms divided by number of frames.
  • Slow UI thread: For all frames rendered in more than 16ms, number of times the UI thread took more than 8ms to complete divided by number of frames.
  • Slow draw commands: For all the frames rendered in more than 16ms, number of times when sending draw commands to the GPU took more than 12ms divided by the number of frames.
  • Slow bitmap uploads: For all the frames rendered in more than 16ms, number of times when the bitmap took more than 3.2ms 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 16ms, go to the Android Developers site for recommended solutions.

Frozen frames

On the Frozen frames page, you'll see details about the percentage of daily sessions where users experienced more than 0.1% of frames with a render time greater than 700ms. 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, not when using OpenGL directly.

Dashboard display

When you expand a dimension row, you'll see the data broken down into percentiles.

  • Impacted sessions: Percentage of daily sessions where users experienced more than 0.1% of frames with a render time greater than 700ms. 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.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs). 

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 the majority of your app's frames are below 700ms.

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 Vsync: For all frames rendered in more than 16ms, number of missed Vsync events divided by number of frames.
  • High input latency: For all frames rendered in more than 16ms, number of input events that took more than 24ms divided by number of frames.
  • Slow UI thread: For all frames rendered in more than 16ms, number of times the UI thread took more than 8ms to complete divided by number of frames.
  • Slow draw commands: For all the frames rendered in more than 16ms, number of times when sending draw commands to the GPU took more than 12ms divided by the number of frames.
  • Slow bitmap uploads: For all the frames rendered in more than 16ms, number of times when the bitmap took more than 3.2ms 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 700ms, go to the Android Developers site for recommended solutions.

App startup time

On the App startup time page, you can see details about when your app starts slowly from cold, warm, and hot system states.

Data collection details

  • Startup times are only recorded when a user triggers an activity.
    • Example: For keyboard apps, the startup 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 startup time is recorded.
  • Startup 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 startup 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.
  • Bottom quartile: 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 slow app startup times, go to the Android Developers site for recommended solutions.

Permission denials

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 requested at least 1 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 requests: Approximate number of recorded sessions.
  • Bottom quartile: 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 1000 apps on Google Play (by number of installs).

Fix an issue

If your app has a high number of permissions denials, go to the Android Developers site for recommended solutions.

Analyze your data with dimensions

To help you organize, segment, and analyze your data, all of your app's data is broken down by the following dimensions.

  • App Version: Version of your app
  • Android Version: Android OS version reported from the user's device
  • Device: Users' device Marketing Name and Device Name (e.g. Google Nexus 7/Flo)
  • Wake lock tag: Tags that were programmatically set when using the PowerManager API in your app
  • Wakeup tag: 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 occured (if available)
  • ANR type: When the ANR occurred (e.g. while executing a service) (if available)

Related content

Discover best practices for using Android vitals to improve your app's performance and stability.

Was this article helpful?
How can we improve it?