Crash Analytics for Unity Mobile Games on Android

Android is the most fragmented platform you will ever ship to. Tens of thousands of device models, a dozen Android versions in active use, and a handful of very different GPU families all run your Unity game, and a crash that never appears on your test device may be hitting a quarter of your players on a chipset you have never touched. Without crash analytics that capture the hardware context, you are debugging blind against a hardware matrix you cannot possibly own.

Fragmentation is the whole problem

The defining challenge of Unity on Android is that the same build behaves differently across hardware. A shader that compiles fine on an Adreno GPU may crash on a Mali, a feature that works on Android 14 may be missing on Android 9, and a memory budget that is comfortable on a flagship is fatal on a budget device with a fraction of the RAM.

This means a single crash report is rarely enough. You need many reports grouped by device characteristics so the pattern emerges. When you see that ninety percent of a particular crash comes from one GPU family or one Android version, you have your root cause, and that pattern is invisible without capturing the hardware context on every crash.

Capture the device context that matters

For every crash, capture the device model and manufacturer, the Android OS version and API level, the GPU and renderer, the total and available memory, and your build version including whether it is a development or release build. These are the dimensions along which Android crashes cluster.

Available memory deserves special attention. Many Android crashes are really out-of-memory kills, where the OS terminates your app for using too much RAM on a constrained device. Recording memory at crash time, and ideally your peak usage, lets you separate genuine code crashes from memory pressure, which need completely different fixes.

Managed exceptions versus IL2CPP native crashes

Unity Android builds use IL2CPP, which compiles your C# to native code, so crashes come in two flavors. Managed exceptions are your familiar C# stack traces and are straightforward to capture and read. Native crashes, including those inside the engine, plugins, or the IL2CPP runtime, produce native stack traces that are far harder to interpret.

A complete crash analytics setup captures both. Managed exceptions are caught and reported with their stack trace directly. Native crashes require capturing the signal and the native backtrace, which then needs symbolication against your build symbols to become readable. Make sure your pipeline handles the native case, because some of the worst Android crashes never surface as a clean C# exception.

ANRs and the Play Console gap

Application Not Responding errors, where your game freezes the main thread long enough that Android offers to close it, are a distinct failure that hurts your Play Store standing. The Play Console reports ANRs and some native crashes, but its data is delayed, sampled, and lacks the in-game context you need to actually fix the issue.

Your own crash analytics fill that gap with real-time, fully contextual reports. Where the Play Console tells you that something is wrong somewhere, your own capture tells you exactly which scene, which device, and what the game was doing. Use both: the Play Console for store-health metrics and your own pipeline for the detail that leads to fixes.

Setting it up with Bugnet

Bugnet provides a Unity SDK that captures managed exceptions automatically with the full device context, and queues reports to upload on the next launch when the crash takes the app down. Device model, OS, GPU, and memory are attached without extra work, so your crashes arrive ready to group by hardware.

Add custom fields for the data specific to your game, such as the current scene, quality settings, and whether the device is in a low-memory state. With everything in one dashboard you can filter a crash by GPU family or Android version in seconds and confirm whether a fix actually moved the needle on the affected devices.

Turn clusters into fixes

The payoff of capturing hardware context is that triage becomes a filtering exercise instead of a guessing game. Sort crashes by frequency, then break the top crash down by device and GPU. If it concentrates on one chipset, you are looking at a driver or shader issue. If it concentrates on low-memory devices, you are looking at an out-of-memory problem. The data tells you which engineering effort to spend.

Track each crash signature over time and across releases so you can see whether your fix landed. On a platform as fragmented as Android, you cannot test on every device, so your players collectively become your test lab. Crash analytics is how you read the results of that experiment and keep your game stable across hardware you will never hold in your hands.

On Android, your players are your test lab. Crash analytics is how you read the results.