How to Collect Device Info from Mobile Game Crashes

On mobile, a crash report without device information is almost worthless. The same build runs across thousands of device models, a dozen OS versions, and a huge range of memory and performance tiers, and crashes cluster along exactly those dimensions. Knowing what a crash was does not help until you know where it happened, on which device, which OS, with how much memory. This guide covers exactly which device fields to collect on Android and iOS, why each one earns its place, and where the privacy line is.

Why device info is the whole game on mobile

Mobile is the most fragmented platform in gaming. A crash that never appears on the flagship phone you develop on may be hitting a quarter of your players on a budget device with a third of the memory and a different GPU. Without device info, every crash looks the same and you cannot see these clusters, so you waste time on issues that affect few players and miss the ones that affect many.

Device info is what makes crash data actionable. Once each report carries the device context, triage becomes a filtering exercise: sort crashes by frequency, then break the top one down by device and OS. The pattern that emerges, a single chipset, a single OS version, a low-memory tier, usually points straight at the cause, which is invisible without the data.

The essential fields

Start with the fields that explain the most crashes. Device model and manufacturer identify the hardware. OS version and API level capture platform differences and deprecated behavior. Available memory and total memory are critical because many mobile crashes are really out-of-memory kills. The GPU and renderer matter for graphics crashes, which cluster hard by chipset.

Add free storage, because a device with no free space fails to write saves and cache in ways that look like random crashes, and screen size and orientation, because layout and rendering bugs are often orientation- or resolution-specific. Capture your own build version too, so you know whether the crash is already fixed in a newer release. Each of these fields earns its place by explaining a category of crashes you would otherwise chase blind.

Useful secondary fields

Beyond the essentials, a few more fields pay off. Locale and language catch localization-specific crashes and number-formatting bugs that only appear in certain regions. Battery state and thermal state can correlate with crashes on devices that throttle hard when hot. Network type can matter for crashes tied to connectivity, and the available CPU cores hint at performance-tier issues.

Capture whether the device is rooted or jailbroken only if it is relevant to your debugging, and capture the app install source if it helps distinguish official from repackaged builds. The principle is to collect fields that help you actually diagnose crashes, not to vacuum up everything possible, because every field has a cost in privacy and in noise.

Stay on the right side of privacy

Device info for crash diagnosis is legitimate, but it has a clear boundary: collect what helps you debug, never personal identifiers. Device model and OS version are fine. A persistent hardware identifier that tracks an individual across apps, precise location, contacts, or anything that identifies the person rather than the device crosses the line and may violate platform policies and privacy law.

Be transparent about what you collect in your privacy policy, and prefer ephemeral or aggregate data over anything that fingerprints a user. The goal is to understand the device a crash happened on, not to identify the human holding it. Done right, crash device collection is unobtrusive and privacy-respecting, and players have no reason to object to data that exists only to make their game more stable.

Setting it up with Bugnet

Bugnet captures the essential device fields automatically on iOS and Android, device model, OS version, memory, GPU, and more, so every crash report arrives ready to group by hardware without you wiring up each field by hand. You get the diagnostic context out of the box, focused on debugging rather than tracking.

Add custom fields for the secondary data your game cares about, like the current scene or quality preset, and group identical crashes into occurrence counts. From the dashboard you can filter a crash by device model or OS version in seconds and confirm whether a fix actually reduced the crash on the affected devices, closing the loop on the fragmentation problem.

Turn the fields into fixes

Collecting device info is only the start, the payoff is in the filtering. When your top crash concentrates on low-memory devices, you know to reduce your memory footprint or handle allocation failures gracefully. When it concentrates on one GPU family, you are looking at a shader or driver issue. The device fields turn an undifferentiated crash count into a diagnosis.

Track each crash across releases and across device dimensions so you can prove a fix worked on the hardware it targeted. On a platform you cannot fully test because you cannot own every device, this data-driven approach is how you keep a mobile game stable: your players collectively exercise the device matrix, and the device info you collect is how you read which parts of that matrix are breaking and confirm when you have fixed them.

On mobile, what crashed is half the answer. Where it crashed is the other half.