Use Android vitals to improve your app's performance and stability

  • Test
  • Develop
  • Analytics

Performance and stability are directly linked to good ratings on Google Play. Fixing issues and preventing bad behaviors can lead to a better user experience, higher ratings, and more retained installers.

Why it works

Android vitals includes app performance metrics for stability, power, jank, startup times and permission denials. Tracking these metrics allows you to identify and fix bad app behaviors that directly affect the user experience. You'll also see when there's a sudden change in core vitals that indicates anomalies you should investigate, and benchmarks, so that you can compare your app's performance to that of similar apps. Apps whose metrics are higher have greater promotability, which raises their ranking in Google Play Store searches. They also are more likely to be eligible for the New & Updated and Editor's Choice collections on Google Play, and nominated in the Google Play Awards.

Key metrics

  • Stability | ANR-free users: The percentage of users who experienced at least one application not responding (ANR) event when the app was in the foreground on a given day. ANRs are typically caused by deadlocks or slowness in UI thread and background processes (broadcast receivers).
  • Stability | Crash-free users: The percentage of users who experienced at least one crash when the app was in the foreground on a given day. Crashes are often caused by unhandled exceptions, resource exhaustion, failed assertions, or other unexpected states.
  • Render time | 16ms (60fps): The percentage of users who experienced more than 15% of frames with a render time of greater than 16ms in a day. Apps that take too long to render each frame before it is drawn will begin to exhibit stutter. Occasional and small increases in render time are unlikely to be noticed, but render times of 150ms cause a perceptible stutter.
  • Render time | 700ms: The percentage of users who experienced more than 1 in a 1000 frames with a render time of greater than 700ms in a day. As above, long render times degrade user experience by causing your app to feel less smooth. Frames that take 700ms or longer to render are likely to cause your app to appear frozen to the user.
  • Battery | Partial wake locks: The percentage of users who experienced at least one wake lock of more than one hour on a given day. Stuck partial wake locks prevent an idle device from sleeping and saving battery.
  • Battery | Wakeups: The percentage of users who experienced more than 60 wakeups per hour since the device was fully charged. Frequent wakeups caused by alarms performing time-based operations outside the lifetime of your app will prevent an idle device from sleeping.
  • Startup time: The percentage of sessions during which users experienced slow cold, warm, or hot startup times. Slow startups can be caused by a range of issues but usually indicate the execution of heavy workloads or complex logic when initializing the app.
  • Permission denials: The percentage of daily permission sessions during which users deny permissions or select Never ask again. Permission denials may indicate that people are unclear why a permission is being requested or view the request as unnecessary or unreasonable.

Best practices

  • Think about bad behaviors and eradicate them: During the development of your app, think about how it would behave in different environments. For instance, if you are developing your app and testing its performance on a high-end, full-featured device, think about how it would perform on a low-end device with limited power, memory, bandwidth, and CPU/GPU capability. Use Pre-Launch Reports to broaden the set of devices your app is tested on before each release.
  • Check Android vitals after releasing a new app version: After you've published your app, Android vitals will provide metrics on the performance of your on production devices in the real world. This allows you to identify issues and bad behaviors that are affecting users on specific devices and Android versions.
  • Identify problem devices: Your app may only exhibit bad behaviors on a specific device or set of devices. Depending on the severity of the impact to user experience and the number of devices and users affected, you can choose to update your app's Device Targeting to exclude those devices until a fix is available.
  • Identify problem Android versions: Your app may only exhibit bad behaviors on specific Android versions. For older Android versions representing a small number of users, either update your app to eliminate the bad behavior or update the android:minSdkVersion attribute of the <uses-sdk> element in your app's Manifest to an API level where your app doesn't exhibit any bad behaviors. For new Android versions, always update your app to fix the bad behaviors rather than setting the android:maxSdkVersion attribute of the <uses-sdk> element to exclude newer Android versions.
  • Use crash reporting tools to identify and trace crashes and ANRs: Use crash reporting tools, such as Firebase Crash Reporting or Crashlytics, and Android Studio debugging to identify and trace as many scenarios as possible that lead to crashes and ANRs.
  • Use JobScheduling APIs to avoid wake locks and wakeups: Use JobScheduling APIs such as JobScheduler to intelligently schedule background processes and tasks. Doing so allows the platform to better manage its idle state to save battery life.
  • Use FrameMetrics APIs to identify slow render times: Use FrameMetrics to measure high granularity, per-interaction frame render times for devices in production. This allows you to identify specific interactions or events that are causing jank on production devices, rather than relying on test devices connected via USB.
  • Follow the best practices for permission requests: Educate the user before requesting a permission and ensure users benefit from allowing a permission immediately. Then help users undo permission denials. Also make sure that users have the right settings enabled for your app to work, and when you need location, construct a Location Settings Request to make sure that the appropriate device settings are turned on.
  • Use Pre-launch reports to test your app on real devices and identify and fix issues before you publish your update.

Examples