Search
Clear search
Close search
Google apps
Main menu

Monitor your app's stability, battery usage & render time

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

You'll see the following data collected from Android devices whose users have opted in to automatically share usage and diagnostics data.

  • Stability: ANR rate & crash rate
  • Render time: examples of slow rendering (16ms) and frozen UI frames (700ms)
  • Battery usage: stuck wake locks and excessive wakeups

Note: Android vitals data is based on Pacific Time (PT).

Find & review your app's data

  1. Sign in to your Play Console.
  2. Select an app.
  3. On the left menu, click Android vitals > Overview.
  4. At the top of the page, choose the type of data you want to view.
    • Some tabs may be marked with a red error icon . This means the number shown is high compared to other apps.
    • The date range listed on your Android vitals page includes all available data for your app and can't be customized.
    • For more information about a metric, select the matching header in the "Data types" section below.

Data types

ANR rate

Understand your app's data

On the "ANR rate" tab, 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.

The data is broken down into:

  • 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.
  • Related ANRs: To view real-time ANR details, select the Related 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

Understand your app's data

On the "Crash rate" tab, 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.

The data is broken down into:

  • 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.
  • Related Crashes: To view real-time crash details, select the Related 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" tab, 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.

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" tab, 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.

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.

Stuck wake locks

The "Stuck wake locks" tab 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.
  • 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.

Dashboard display

On the "Stuck wake locks" tab, you'll see details about:

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

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" tab 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.

Dashboard display

On the "Excessive wakeups" tab, you'll see details about:

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

Fix an issue

If your app has frequent wakeups, 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?