14. Monitoring & Improving App Performance: Android Vitals

Written by Fuad Kamal

Understanding Android Vitals

The Vitals section of the Play Console contains a tremendous amount of information about the health of your app in the wild. While helpful, all that information might seem overwhelming at first. You might be tempted to put off examining this area or ignore it completely. But even if you ignore Vitals, Google doesn’t - and your app’s performance as reported by Vitals directly impacts how easy it is to search for and discover your app or game on the Play Store.

Vitals reports information like Application Not Responding (ANR), performance benchmarks, battery usage, stability and much more. It collects data from real devices used by your users. As such, you get metrics that you might not otherwise get from internal testing and CI/CD workflows. However, this means the data and the availability of information appearing in Vitals is also subject to certain external factors.

If your app is newly released or you don’t have many users, you may not see any data in Vitals. Also, users need to give permission on their devices for developers to collect data, or Vitals won’t get any data.

In addition to Vitals, you can also use the Pre Launch Report to get similar data from the Play Console’s analysis of your app running on test devices in Firebase Test Lab rather than from real-world devices and users.

However, once your data shows up in Vitals, it can be an excellent and powerful tool. For example, not only can you see how your app is performing, but you can directly see how your app performs compared to your peers and competitors.

Exploring the dashboard

On the Google Play Console, click the Dashboard navigation item on the left to see an overview of all the vital information about your app. Take note of the section on Android Vitals where you’ll see an overview of the most important metrics from Vitals:

Click View Android vitals to go to the vitals section of the Play Console.

As you can see, under All vitals, the number of metrics available in Android vitals is huge. To make it easier, Google identified four core vital metrics that have the most significant impact on user experience. You’ll find these listed under the top section titled Core vitals. They are:

1. ANR rate
2. Crash rate
3. Stuck partial wake locks (background)
4. Excessive wakeups

The first two metrics relate to your app’s stability, while the last two relate to its battery usage and performance. Each metric has a “Bad Behavior Threshold”, which is set by Google. If the core vital is over the bad behavior threshold, you get a prominent warning from Google Play, letting you know there’s an issue.

Click the warning for more detail.

As reported by the core vitals, your app’s performance can directly affect how easy it is to search for and discover your app on the Play Store. So if you perform poorly in these areas, users might not be able to discover your app. Therefore it’s critical to monitor these behaviors and make sure you stay under the bad behavior thresholds.

There are several filters you can use to drill down into the crash rate.

In the image above, you’ll see that you can filter the crash rate by Android version, app version, device type and device model. You’ll learn more about crash rate later. For now, take a look at the section named vs. peers.

Peer groups

Peer groups are a unique and powerful Android vitals feature. Here you can compare your app’s performance across key metrics with your peer and competitor apps.

This particular example shows Custom peer group, a custom group of apps that you define. However, there are various category presets you can compare against.

In this example, the app shown is in the telematics industry. These apps use GPS and other device sensors to report on driving behavior. The app’s developers might want to know how their app compares, for example, to other GPS mapping apps or apps in the Auto & vehicles categories as shown in the image below:

While your crash threshold might be under the bad behavior benchmark, you can see if it’s better or worse than your peer groups.

Vitals is still private: Google designed it carefully so that your competitors can’t discern specifics about your Vitals. Still, if you want, you can opt-out of this feature completely so they can’t see anything about your app. But then you also can’t use the feature anymore to compare yourself against your competitors.

The key is to monitor Android Vitals for any problems and address them early before they get much worse. For example, you can monitor Vitals by signing up for notifications from Android Vitals. With notifications, Google proactively informs you if there are any problems you need to address right away, rather than trying to spot issues yourself manually.

You sign up for Android Vitals notifications the same place you sign up for other notifications in the Play Console. From the Play Console, click All apps, then Setup -> Notifications. Or, from the Android vitals overview page, click Manage notifications:

Then make sure Android vitals is checked:

Crash analytics and reports

Suppose you had a crash rate above the bad behavior threshold. You might use Android vitals to answer questions like these:

1. How long has the crash been going on for?

• If it’s not from a recent release, does the crash have to do with a back end issue rather than an issue with the app itself?

2. Is the crash related to a recent version of Android OS?

• You can drill down in vitals to see which versions of Android the crash affected.
• If the crash is Android version-specific, that might give you a clue regarding the root cause of the issue. Perhaps something changed in the behavior of Android?

3. Is the crash related to a specific device or specific hardware issues?

• You can drill down in vitals by device.

4. Is the crash related to a particular app release?

• You can drill down in vitals by release version and pinpoint a particular APK or app bundle involved.

To confirm if a particular release is responsible for causing a crash, drill down in vitals by app version. Then filter on the penultimate version to confirm that version didn’t crash as much as the last release. Once you’ve confirmed that a particular app version is causing a spike in the crash rate, the next step is to view the real-time crash reports.

From the Play Console menu, go to Android vitals -> Crashes and ANRs.

In the example above, you see a single type of crash that causes most of the crashes for this release version. You can then click the arrow in the rightmost column to see the crash details, view the stack trace of the crash and proceed to debug the issue.

In the details view, note the Last occurred heading. Suppose you thought the crash was a server-side issue, and your back end team had resolved the supposed issue. If the last occurrence of the crash was after the supposed fix, you would know that the issue was, in fact, not resolved.

On this page, you’ll also see crash details, like the timeline and trends across app version, Android version and device. You can also find the Stack trace similar to the one you get on Firebase Crashlytics.

Reviewing pre-launch reports

The Pre-launch report, or PLR, is a valuable companion to Android vitals. You’ll find it in the release management section of the Play Console. Navigate to Release -> Testing -> Pre-launch report. A typical PLR looks like the one shown in the image below:

While Android vitals helps you monitor your app’s health after you launch, the pre-launch report helps you check things out before you launch a particular version of your app.

As you explored earlier in this book, you first submit your app to a test track. Even if your app is in production, if you don’t have any active test tracks, you may not see any data in the PLR.

Once your app is in a test track, Google runs your app on real devices in the Firebase test lab. Firebase automatically navigates through your app, captures screenshots, crash exceptions and device logs. Google can capture much more metadata in the PLR phase than in Android vitals.

Again, wherever there’s a problem, you can click it and get more details. For example, in the screenshot above, clicking the highlighted arrow for the crash shows this detailed stack trace, video and more:

But unlike Vitals, in PLR for the stack trace, you also get to see the exception message. This type of data is obscured from Vitals due to user privacy concerns. Obscured data includes information about user data, like logcat and credit card information.

Since PLR runs on devices in a test lab that real users don’t use there are no privacy restrictions. You can even download the full logcat for a given exception. You can also see a video of the entire test session and see exactly what was going on at the point of the crash. This can be useful even if there are no crashes. For example, you can see how your app renders on different devices your developers might not even have access to.

You can also see screenshots of your app running on different devices and locales.

In Play Console, navigate to Testing -> Pre-launch report -> Settings:

The PLR crawler is pretty smart when it comes to automatically crawling your app. However, sometimes it needs help to get past certain points. Google has provided four different ways to customize PLR to help it crawl past certain types of choke points:

1. Providing Test Credentials: If you have a login screen in your app, the crawler will need a set of test credentials to get past it.

2. Providing Deep Links: You can provide up to three different deep links to open your app at particular points and crawl those parts.

3. Demo Loops: These are particularly useful for games. You fire off an intent, com.google.intent.action.TEST_LOOP. The demo loop executes, and you can check what’s happening with key parts of a game or app.

4. Robo script: You can provide a custom Robo test script for PLR to execute. For more information on Robo, see https://firebase.google.com/docs/test-lab/android/robo-ux-test.

Using Android vitals to understand your app’s power consumption

Well-behaved apps optimize battery consumption by minimizing device radio and CPU usage. Android vitals lets you see the metrics for two common causes of battery drain: wakeups and wake locks.

Alarms performing time-based operations that prevent an idle device from sleeping cause wakeups.

Wake locks occur when the app has your device working so hard it won’t let the device sleep.

For better battery life, use job scheduling APIs to schedule asynchronous tasks and specify conditions to maximize efficiency. This method is suitable for small tasks like clearing a cache and large ones like syncing a database to the cloud.

Understanding your app’s performance

The speed at which your app renders impacts user perception of your app performance. Slow render time or frozen frames lead to bad reviews. Apps that have a render time of 16 milliseconds or reach 60 frames per second produce a silky smooth experience for your users. This is the rate at which users can perceive smooth motion within your app.

Android vitals lets you see what percentage of users experienced more than 50% of frames with a render time of greater than 16 milliseconds so you can provide a smooth experience across all devices.

Anything greater than a render time of 700 milliseconds is considered a frozen frame, and at this rate, users consider an app to be unresponsive. Avoid slow render times or frozen frames by using frame metrics APIs to measure per interaction frame render times for devices during production.

While the view is somewhat different in PLR, it also provides insight into your app’s performance:

Click the details for the Nokia handset above, and you’ll see a detailed performance report for that device:

Key points

• Android vitals includes two bad behavior metrics relating to stability, Application Not Responding errors, or ANRs, and crashes. ANRs occur when the app freezes and stops responding to user input for more than five seconds. They’re usually caused by deadlocks, slowness in UI threads or background processes.

• When your app crashes, it can be a frustrating experience, impacting retention and leading to bad reviews. The crash rate will show you the percentage of users experiencing crashes in your app.

• One way to address stability issues is to run pre-launch reports, which will test your alpha or beta app on physical devices so you can identify and fix issues before you launch.

• Android vitals provides two bad behavior metrics relating to battery usage: wake locks and excessive wakeups. Background tasks that could be better managed using APIs such as Work Manager cause excessive wakeups. Wake locks typically occur when your app attempts to do too much work at one time in the main thread.

• You can track many other metrics using Android vitals, but those four key metrics are highlighted for you. Use Pre-launch reports for your test track builds to get even more detailed information about your app performance and catch issues before launch.

Where to go from here?

Find out more about Android vitals key metrics and best practices at https://developer.android.com/distribute/best-practices/develop/android-vitals.html.

Learn how you can use WorkManager to schedule tasks in this tutorial on raywenderlich.com: https://www.raywenderlich.com/20689637-scheduling-tasks-with-android-workmanager.