Firebase Crashlytics Splits System Kills From Memory Errors
On Android 17 and up, Crashlytics now gives Low Memory Kills and OutOfMemoryErrors their own separate issues instead of one shared bucket.

Firebase Crashlytics now separates the two most common ways an Android app dies of memory pressure, instead of folding both into one issue. Per the Firebase Android SDK Release Notes, devices running Android 17 or later get distinct Crashlytics issues for Low Memory Kills and OutOfMemoryError exceptions, shipped as part of the July 2026 Android BoM update (firebase-bom:34.16.0).
Two different deaths, one bucket
A Low Memory Kill and an OutOfMemoryError look identical from the outside (the app is gone), but they come from opposite ends of the stack. An LMK is Android’s low-memory killer deciding a process is using too much RAM system-wide and terminating it directly, with no exception and no stack trace for the app to catch. An OutOfMemoryError is the app’s own allocator giving up on one specific request, which does throw a catchable (if rarely actually caught) exception with a trace pointing at the failing allocation.
Crashlytics has reported both for years, but it grouped memory-related terminations together in a way that blurred which one was actually hitting a given device population. A developer staring at a memory issue in the dashboard couldn’t easily tell whether users were being killed by the OS under system-wide pressure or hitting a hard ceiling at one specific line of code, two problems that call for different fixes.
Why the split matters for triage
The distinction changes where you look first. A Low Memory Kill spike usually means an app’s overall footprint is too large for the devices it’s running on (a leak, an oversized image cache, too many background services), and the fix is architectural. An OutOfMemoryError spike more often points at a single allocation site: one bitmap decode, or one buffer that grows without bound. Lumped together, both symptoms produced the same vague signal. Split apart, each becomes an issue a team can actually triage and assign.
The July update touched more than Crashlytics: the same Android BoM revision also bumped the Crashlytics NDK, Firebase AI Logic, App Check, Authentication, Cloud Firestore, Cloud Messaging, Installations, Performance Monitoring and SQL Connect SDKs, per the Firebase Release Notes. The memory-grouping change itself is scoped to devices on Android 17 and above. Apps still running on older Android versions will keep seeing memory terminations grouped as before.
Key Takeaways
- Crashlytics now creates separate issues for Low Memory Kills and
OutOfMemoryErrorexceptions on Android 17+, per the Firebase Android SDK Release Notes. - The two failure modes are mechanically different: an LMK is an OS-level kill with no exception, an OOM is an app-level allocation failure that throws one.
- The split ships in the July 2026 Android BoM (
firebase-bom:34.16.0), alongside routine updates to Crashlytics NDK, Auth, Firestore, Cloud Messaging and other Android SDKs. - Devices on Android 16 and earlier still see memory terminations grouped together; the new behavior only applies to Android 17 and up.
What to do
Update to the current Firebase Android BoM to pick up the change. There’s no new API to call and no configuration flag to set. Once you’re on it, revisit any Crashlytics issue you’d previously tagged as “memory” on Android 17 devices: it may now be split into an LMK issue and a separate OOM issue, each with its own occurrence count and device list worth triaging on its own.


