Search
Clear search
Close search
Google apps
Main menu
true

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)

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

    At the top of the Overview page, choose the dimensions and time period you want to view.

    For each metric, review your app's percentage of sessions impacted for:

    • The current time period
    • The previous time period
    • The bad behavior threshold

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

    For additional details about a metric, select View details. On the next screen, 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 using the new data source. 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 using the new data source. 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.

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
Was this article helpful?
How can we improve it?