Use Android vitals to improve your app's performance and stability
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, and jank. Tracking these metrics allows you to identify and fix bad app behaviors, introduced in new releases of your app, that directly affect the user experience. 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.
- 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, in order to do work for an app.
- 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.
- 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:minSdkVersionattribute 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:maxSdkVersionattribute 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 in order 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.
- Use Pre-launch reports to test your app on real devices and identify and fix issues before you publish your update.