Android Vitals Before Production: What to Check First

Before you apply for production, open Android vitals in Play Console and look for four things: crashes, ANRs (app not responding), startup and rendering problems, and battery or permission issues. No single number guarantees approval. But a closed test is the cheapest time to find these problems, because the only people affected are your testers.

This post walks through what to look at, what to do when the data is thin, and how to decide whether you are ready to apply.

What Android vitals is (and isn't)

Android vitals is the technical quality section of Play Console. It collects data from real devices and groups it into metrics such as crash rate, ANR rate, startup time, slow rendering and battery usage. Google also uses these signals to decide whether your app behaves badly enough to affect its visibility on Play.

Two caveats up front:

• It is not the production access review. Production access is mostly about whether you ran your closed test properly. Vitals is about how your app behaves. Both matter, but they are separate things.
• The details change. Metric names, thresholds and dashboard layout are updated from time to time. For current definitions, check Play Console Help and the Android vitals overview on developer.android.com.

Step 1: Look at crashes and ANRs first

These two are the most important. A crash is the loudest way to lose a user, and an ANR is the quietest.

Crashes

• Open Quality > Android vitals > Crashes and ANRs (the menu wording may differ slightly in your console).
• Sort clusters by number of affected users, not by newest. Fix the top cluster before you look at anything else.
• Open each cluster and read the stack trace. Note the device model, Android version and app version.
• Check whether the crash happens on one device family or everywhere. A crash on every device is a code bug. A crash on one chipset or one Android version is often a compatibility issue.

If you want a process for triaging crash reports from testers, see our post on handling crashes reported during a closed test.

ANRs

ANRs usually mean you are doing too much on the main thread: disk reads, database queries, network calls, or heavy JSON parsing. Read the ANR traces and look for your own code near the top of the main thread stack. Move that work to a background thread or coroutine, then ship a new build.

Step 2: Check startup and rendering

An app that does not crash can still feel broken. Look at:

• Cold start time. Compare a mid-range phone with your own flagship. Most of your testers will not have a flagship.
• Slow frames and frozen frames. Scrolling lists, animations and image-heavy screens are the usual culprits.
• Heavy first-run work. Initialising several SDKs on launch is a common cause of slow starts. Defer what you can.

You can also profile locally with Android Studio's profiler on the cheapest device you own. Real numbers from a low-end phone are more useful than guesses.

Step 3: Check battery, wake locks and permissions

Android vitals also tracks behaviours that drain the battery or annoy users. Scan for:

• Excessive background wakeups or long-held wake locks.
• Background services that never stop.
• Permission prompts that appear at launch before the user knows why you need them.

If the permission prompts are a problem, ask for each permission in context. The camera permission, for example, should appear when the user taps a scan button, not on the splash screen.

Step 4: Read the Pre-launch report

Play Console can run your uploaded build on a set of devices automatically and produce a pre-launch report. It tends to catch crashes on startup, missing permissions declarations, accessibility issues and similar problems. Availability and device coverage can vary, so check the Testing section of your console. Treat the report as a free second opinion, not a replacement for real users.

What if you have very little vitals data?

This is the most common situation with a closed test. With about a dozen testers, the vitals charts may be empty or based on a handful of sessions. Android vitals also generally relies on data from users who have chosen to share usage and diagnostics, so even fewer sessions may show up.

When that happens, fill the gaps yourself:

1. Add your own crash reporting. A tool such as Firebase Crashlytics shows crashes in real time, rather than waiting for aggregated vitals.
2. Ask testers for specifics. "Which screen were you on, and what phone do you have?" is more useful than "it crashed".
3. Look at testing activity, not just errors. If nobody opened the app on day 6, a clean crash report doesn't mean much. Testers who use the app daily on their own phones produce better evidence than testers who installed it and left it.

TesterMob testers use your app for about 20 minutes a day on their own Android phones and send written feedback. The optional Android SDK (an .aar file) also shows daily tester activity in your dashboard, which helps you tell a quiet app from an unused one. It does not replace Crashlytics or Android vitals, and it is optional. Details are on the developer page.

A pre-application vitals checklist

Run through this in the last two or three days of your 14-day test:

1. Top crash cluster identified and fixed, or understood and documented.
2. No ANR traces pointing at your own main-thread code.
3. Cold start tested on a low-end or mid-range device.
4. No screens with obvious jank when scrolling.
5. Permissions requested in context, and each one actually needed.
6. Pre-launch report reviewed, with issues fixed or explained.
7. Latest build uploaded to the closed track, with testers updated.
8. Tester feedback read, with the recurring issues dealt with.

A note on updating during the test

Shipping a fix mid-test is normal. Upload the new build to the same closed track and keep your testers opted in. Testers who stay opted in should not affect your 12-tester, 14-day count, but check the current rules in Play Console Help if you are unsure. Our FAQ covers common questions about how testing works.

Should you wait or apply?

A rough rule: apply when you have completed the 14 days with at least 12 testers opted in, you have fixed anything repeating across devices, and you can honestly describe in the application what you tested and what you changed. A few rare crashes on unusual devices are normal. A crash on launch for half your testers is not something to apply over.

Nobody can promise that Google will approve your application, and that includes us. TesterMob is not affiliated with Google and cannot guarantee production approval. What you can control is arriving at the application with a stable build and a clear record of what you did during the test. If you need testers for the closed test itself, pricing is a single $9.99 per app, paid once in USDT, and you can see the details on the pricing page.

The short version

Fix crashes first, then ANRs, then slow starts and janky screens. Check battery and permission behaviour, read the pre-launch report, and add your own crash reporting if the vitals data is thin. Then apply with a build you would be comfortable putting in front of strangers, because that is what production is.