Docs

Android Wake Lock & Low-Memory-Kill Tracking

Excessive partial wake locks now hurt Play Store visibility and a new low-memory-kill metric counts like a crash — what to instrument before it does.

Performance

Android Vitals added a low-memory-kill (LMK) metric this year, tracking how often the OS force-kills an app because a device is critically short on memory. Google treats it the way users experience it: as a crash. The app didn’t throw an exception or hang, but from the user’s side it closed without warning mid-task, and that’s exactly the impression an unexplained crash leaves. Alongside it, the existing “excessive partial wake locks” beta metric has teeth now — Play Console flags any app whose combined partial wake locks run for more than three hours across a rolling 24-hour period, and since 1 March 2026 that flag can affect Store visibility, not just show up as a quality warning in a dashboard nobody checks.

Both metrics catch a category of failure that traditional crash reporting misses entirely. A wake lock that never releases — held by a background sync job, a location listener that outlives its screen, a media session that doesn’t tear down — doesn’t crash anything. It drains battery, and now it can also suppress how often Google Play surfaces the app to new users, entirely independent of any code exception. Teams that only track crash-free session rate have no visibility into either failure mode: LMK events don’t appear in a crash reporter unless it’s specifically wired to catch them, and wake lock duration is invisible unless someone is deliberately summing lock-held time per session rather than just logging acquire/release calls as isolated events.

Data Points to Track

  • LMK events per session, logged as their own category distinct from crashes and ANRs, so “app was killed without user action” is measurable even when no exception was thrown
  • Cumulative partial wake lock duration per 24-hour rolling window, summed across all wake lock sources in the app, not just logged as individual acquire/release pairs that never get aggregated
  • Wake lock source attribution, identifying which feature, service, or background job is holding a lock, since the three-hour threshold is an app-wide total and a single leaking component can push the whole app over it
  • Memory pressure state at time of LMK, captured from the OS-reported memory level leading up to the kill, to distinguish devices that are chronically low-memory from a genuine leak in your app’s own memory usage
  • Store visibility and organic install trend for apps flagged on the wake lock metric, tracked from the point a flag appears in Play Console, to confirm whether the enforcement is actually suppressing discovery for that specific app

Setup Steps

  1. Add explicit LMK detection using the platform’s low-memory callback and app-exit-reason APIs, and log it as a distinct event type rather than letting it fall through to “unknown termination.”
  2. Wrap wake lock acquire/release calls in a lightweight tracking layer that sums held duration per source and per rolling 24-hour window, instead of relying on isolated start/stop logs that require manual reconstruction to analyse.
  3. Tag every wake lock acquisition with its owning feature or service name at the point of acquisition, so a threshold breach can be traced to a specific component within minutes, not discovered through a manual audit.
  4. Pull the Android Vitals wake-lock and LMK dashboards into your regular release-quality review, not just crash-free rate, since both can degrade without moving the crash number at all.
  5. Set an internal alert threshold below Google’s three-hour enforcement line — for example, two hours — so a leaking wake lock gets caught and fixed before it actually affects Store visibility.

Actionable Insights

A rising LMK rate that doesn’t show up in your existing crash dashboard means your crash-free session rate is overstating stability — treat LMK as a first-class reliability metric, not a footnote, since users experience it identically to a crash. If wake lock duration is concentrated in one or two sources rather than spread evenly across the app, that’s a targeted fix, not a broad audit — go straight to the flagged component. And if Store visibility or organic installs dip for an app that Play Console has flagged on wake locks, that’s strong evidence the enforcement is live and biting for that app specifically, which changes the fix from “optimise for battery” to “ship a wake-lock fix now, this is costing discoverability.”

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert