Android vitals

Android vitals is an initiative by Google to improve the technical quality of Google Play apps on Android devices. When an opted-in user runs your app, their Android device logs information about aspects of quality including stability metrics, performance metrics, battery usage, and permission denials. This data is aggregated by Google Play and can be accessed in two ways: through the Google Play Console in the Android vitals dashboard, and through the Google Play Developer Reporting API.

Developers should monitor all vitals to ensure they aren't having a negative effect on user experience. In particular, developers should prioritize the two core vitals: user-perceived crash rate, and user-perceived ANR rate.

Core vitals and bad behaviors

Your app's core vitals affect your app's visibility on Google Play. Each core vital has an overall bad behavior threshold and a per-device bad behavior threshold. These are documented below and also shown in Android vitals.

FAQs

What are core vitals?

Core vitals are the most important metrics in Android vitals, and affect the visibility of your app on Google Play. The core vitals are user-perceived crash rate and user-perceived ANR rate.

What are the bad behavior thresholds?

Each core vital has two bad behavior thresholds: an overall bad behavior threshold that takes into account all sessions on all devices, and a bad behavior threshold that is evaluated per device (phone only). The thresholds are shown in Android vitals.

BAD BEHAVIOR THRESHOLD
To maximize your title's visibility on Google Play, please keep it below these thresholds.
Overall (average across devices) Per phone model
User-perceived crash rate 1.09% 8%
User-perceived ANR rate 0.47% 8%

How do core vitals affect my title's visibility on Play?

If your app or game exceeds the overall bad behavior threshold on any core vital, then Play may reduce the visibility of your title for users on all device models. If your app or game exceeds the per-device bad behavior threshold on any core vital, for a given device model, then Play may reduce the visibility of your app or game for users on that device model. Play may also show a warning on your store listing to indicate to users that your app may not work properly on their device.

Is it possible to have both per-device and overall bad behaviors? Or one but not the other? What do I do if so?

Yes, all combinations are possible. To improve your overall quality, you should aim to fix the crash and ANR clusters that affect the most users overall. To improve per-device quality, you should fix the largest crash and ANR clusters on that device. If you have both, we recommend that you start by focusing on the largest crash and ANR clusters overall. Doing this is likely to improve quality on the most important individual device models as well.

I need help to fix my technical issues. Where do I start?

We have compiled a number of resources to help you get started diagnosing and fixing technical issues in your app or game.

Core vitals:

User-perceived ANR rate
User-perceived crash rate

All other vitals:

Excessive wakeups
Stuck partial wake locks
Excessive background Wi-Fi scans
Excessive background network usage
App startup time
Slow rendering
Permission denials

I don't want to be surprised by bad behaviors or store listing warnings. How can I get ahead of this?

Play will generally look at the last 28 days of data when evaluating your quality. Android vitals will warn you of any bad behaviors over 28 days.

  • Check the UI regularly or consider using the reporting API to incorporate data directly into your workflows.
  • [Coming soon] Configure email alerts in Play Console for bad behaviors.
  • [Coming soon] Android vitals will report 'emerging issues', defined as devices that miss the per-device bad behavior threshold over 7 days. This gives you up to 21 days to get ahead of the problem.

I have a lot of devices with bad behaviors. How do I make sense of the list?

Sometimes, specific aspects of device hardware or software can contribute to your issue rates. To help you catch and resolve those issues, a new feature in Android vitals will notify you if we find any potential associations between high issue rates and key device attributes like RAM, Android version and system on chip, amongst others. You can also explore associations yourself in Reach and devices in Play Console.

Within Android vitals you can also get one-click access to consolidated device information, including install base, revenue, ratings and reviews. This information is displayed in a side panel so you don't have to leave the page that you're on.

If I fix an issue on a device, how long before warnings stop showing?

Play evaluates your core vitals daily on a 28-day rolling average basis. As soon as the rolling average falls back below thresholds, Android vitals will stop showing warnings. Store listing warnings may be removed even sooner than this, if Play algorithms detect that your technical quality is already headed in the right direction.

What if I can't fix the issue, or I don't want to do so?

Ensure that you have considered both the cost and the opportunity of persistent poor experiences when deciding how to proceed. Bad behaviors affect existing users, and they reduce your ability to acquire prospective users. When fixing per-device bad behavior is not feasible, you may want to review your device targeting and exclusion logic.

Why don't Android vitals issue counts and rates match the issue counts and rates I see from my own or other third-party solutions?

Android vitals is Google Play’s source of truth for evaluating technical quality. Android vitals issue counts and rates may not match those from other sources for several reasons:

  • Android vitals information comes from the Android platform, and captures some events that cannot be seen by SDKs, including:
    • Crashes on launch, which happen before SDK initialization
    • ANRs prior to Android 12
  • Android vitals only counts issues if they are reported on certified devices, and on apps that were installed from Google Play. Other data sources may not apply these constraints.
  • Android vitals only collects data from users that have opted in to share usage and diagnostics information. Other tools may not require user opt-in. Even if they do, it's unlikely that they collect data from the exact same set of users that are opted-in on Android.
  • To protect user privacy, we show metrics in the dashboard only if we have been able to collect enough data to generate anonymized reports.
  • Issue rates may be calculated differently. Android vitals issue rates count the number of issues (crashes, ANRs, etc) per daily active user. Crashlytics counts the number of issues per app session. So if, for example, a user played a game three times in one day and experienced one crash, Android vitals would show a crash rate of 100% while Crashlytics would show a crash rate of 33%.

For more information on how the data is collected, see the Play Console Help Center.