Android Vitals Thresholds for Production Approval: Fix Crashes & ANRs

When you submit an application for closed testing, Google Play is not only tracking whether your 12 testers keep the app installed for 14 continuous days. Behind the scenes, the Play Console continuously analyzes Android Vitals telemetry collected across all active test devices.

If your application breaches Google's strict "bad behavior thresholds" during closed testing, human reviewers and automated evaluation algorithms will flag your build as unstable, resulting in an automatic denial of production track access.

1. Understanding Google's Bad Behavior Thresholds

Google defines core metrics that directly influence store discoverability, user satisfaction, and production track review approval:

2. Diagnosing and Eliminating Crashes During Closed Beta

A "user-perceived crash" occurs whenever an unhandled exception terminates the application while it is active in the foreground. Here is the triage framework used by top engineering teams:

A. Upload Deobfuscation and Native Debug Symbols

If you use R8, ProGuard, or native C/C++ libraries (common in game engines like Unity or Godot), Google Play Console cannot render human-readable stack traces unless you upload symbol files:

• ProGuard/R8 Mapping: Upload the mapping.txt file generated during the release build under app/build/outputs/mapping/release/.
• Native Debug Symbols: Upload the native-debug-symbols.zip for apps utilizing the Android NDK to resolve memory fault addresses (such as SIGSEGV or SIGABRT).

B. Null Safety & Asynchronous Race Conditions

Over 60% of closed testing crashes in Kotlin and cross-platform frameworks (Flutter/React Native) stem from uncaught asynchronous failures when an Activity or component is destroyed before a network request resolves. Always tie coroutines or subscriptions to lifecycle scopes (e.g. lifecycleScope.launch or React's useEffect cleanup).

3. How to Eliminate Application Not Responding (ANR) Errors

An ANR occurs when the main UI thread is blocked for more than 5 seconds while responding to an input event or broadcast receiver. On low-end Android devices with 2GB or 3GB of RAM, operations that take 200ms on your development flagship can take 6 seconds, triggering an immediate ANR.

Common ANR Culprits and Fixes:

1. Synchronous Disk I/O on the Main Thread: Reading large SharedPreferences, SQLite databases (Room), or reading JSON files directly on the UI thread. Use Dispatchers.IO in Kotlin or asynchronous storage in React Native.
2. Heavy Initialization in Application.onCreate(): Initializing heavy third-party SDKs (AdMob, Firebase, Analytics, Supabase) synchronously inside Application.onCreate() delays the first frame. Use Android's App Startup library or initialize non-critical SDKs lazily in a background coroutine.
3. Lock Contention & Deadlocks: Multiple threads competing for synchronized objects where the main thread is waiting on a background worker thread.

4. Managing Wakelocks, Alarms, and Battery Consumption

Android 14 and Android 15 strictly restrict foreground services and background execution. If your app attempts to run long-running background tasks without declaring appropriate Foreground Service Types (such as dataSync, location, or mediaPlayback), Android will terminate the process and log a vital failure.

5. How Android Vitals Affect Your 14-Day Production Review

When your 14-day closed testing period concludes and you submit the Production Access Questionnaire, Google's review system generates an automated health scorecard. If your vital metrics exceed the bad behavior threshold across your test cohort:

• The automated reviewer flags the application as not ready for public release.
• You receive a rejection email stating: "We found issues during closed testing that prevent production access. Please resolve technical defects and test with users for an additional period."