Who killed my process? An Android whodunit

The bug report is always the same. "I switched to the camera, came back, and the app had forgotten everything." No crash dialog, no stack trace, nothing in Crashlytics. The user swears they did nothing. They are telling the truth: somebody else ended the process while they were away, and Android quietly rebuilt the screen from notes so that the return would look seamless. This article is the investigation. Who has a motive, who has the means, what evidence each one leaves behind, and how to build an app that treats the whole affair as routine.

The map

Read this first when short on time. Every branch is a section below.

The crime scene: an app that came back with amnesia

Process death is the system ending an app's process while the user is elsewhere, then recreating the app's screens from saved notes when the user returns, so the app looks like it never left while every object in memory is gone.

The tell-tale symptoms are all in the shape of "the screen is right but the data is wrong". A detail screen shows with an empty title because the object it expected in a singleton is null. A lateinit property throws because the Application that set it up is a different Application instance now. A multi-step form is back on step three with steps one and two blank. A repository's in-memory cache is cold, so a screen that never fetched on its own has nothing to show. Nothing in a crash reporter, because nothing crashed: the process was killed with a signal, not an exception, and the recreated process is a fresh, healthy one.

sequenceDiagram
  autonumber
  participant U as User
  participant S as system_server
  participant P1 as Process, pid 4120
  participant P2 as Process, pid 9877
  U->>P1: presses Home
  P1->>S: onSaveInstanceState Bundle travels with onStop
  S->>P1: minutes later: SIGKILL (memory, swipe, policy)
  Note over P1: everything in memory is gone
  U->>S: taps the app in Recents
  S->>P2: fork from Zygote, bindApplication, Application.onCreate
  S->>P2: launch the top activity with the saved Bundle
  P2-->>U: the same screen, rebuilt from the Bundle

It is worth being precise about what this is not. A crash is the process ending from inside, with an exception; the user sees the app vanish or a dialog, and crash reporters record it. A configuration change, such as rotation, destroys and recreates the Activity inside the same process, so ViewModels, singletons and the Application all survive. Process death sits between them: nothing in your code went wrong, yet only what was written down survives.

Process death

The system killing an app's process while the user is not looking at it, followed by recreation of the task and top Activity from saved state when the user returns.

Saved instance state

The Bundle an Activity fills in onSaveInstanceState, kept by system_server and handed back to onCreate after recreation.

The suspects, at a glance

Every process death on Android has a recorded reason, and the list of reasons is the list of suspects: a memory daemon, two kinds of user action, a vendor's power manager, and half a dozen system policies.

Since Android 11 the system keeps a short history of why each of an app's processes ended, exposed as ApplicationExitInfo. Its reason codes are the cleanest catalogue of suspects there is, so this table is the whole cast; each row gets its own section below.

Two suspects in that list account for almost every "amnesia" report: the low memory killer and the user's own swipe. The rest matter because each one behaves slightly differently afterwards, and the differences decide whether your alarms still fire, whether push messages still arrive, and whether the next launch gets a saved Bundle at all.

Suspect one: lmkd and the memory market

The low memory killer is a user-space daemon that watches memory pressure and, when it rises, kills the process with the worst importance score, chosen from a ladder that ActivityManager maintains for every process on the device.

Android phones have no swap partition to speak of. Some compress pages into a zram block in RAM, but when memory runs out the only real lever is ending a process. Linux has its own OOM killer for that, but it fires only when allocation has already failed, which is far too late for a phone that must keep the foreground app smooth. Android therefore kills early and on purpose. Until Android 8 the killing was done inside the kernel by the lowmemorykiller driver, with a small daemon feeding it thresholds; since Android 9 that daemon, lmkd, does the killing itself, reading the kernel's pressure stall information (PSI) on Android 10 and later, and older vmpressure events before that. The kernel OOM killer remains as the last resort and uses the same scores.

The ladder

Every process has an oom_score_adj in /proc/pid/oom_score_adj, from -1000 (never kill) to 999 (kill first). ActivityManager recomputes each app's score whenever anything changes, sends it to lmkd over a socket, and lmkd writes it into /proc. The rungs are roughly these, and they shift a little between releases:

flowchart TD
  A["minus 1000 to minus 700<br/>native daemons, system_server, persistent apps"] --> B["0 foreground<br/>the activity the user sees, or its foreground service"]
  B --> C["100 visible<br/>an activity still partly on screen"]
  C --> D["200 perceptible<br/>music playback, a bound service the user notices"]
  D --> E["500 service<br/>a started service, no UI"]
  E --> F["600 home<br/>the launcher"]
  F --> G["700 previous<br/>the app the user was in just before this one"]
  G --> H["900 to 999 cached<br/>nothing running, kept only because RAM was free"]

Three rules make the ladder predictable:

1. A process is ranked by its best component. If it has a visible Activity it is at 100 even if it also has ten idle services. A bound service borrows its client's rank: while a foreground app is bound to your service, you sit near 0 too, which the IPC article describes from the other side.
2. Leaving the screen is a long fall. The moment the user presses Home your app goes from 0 to 700, and after the next app switch to the cached band at 900 or worse. Nothing you do in memory changes that; only holding a legitimate component does.
3. The cached band is an LRU list. The system keeps a bounded number of cached processes, ordered by when the user last used them, and their scores climb from 900 towards 999 as they age. Being cached is not being safe; it is being next.

When PSI reports that tasks are stalling on memory, lmkd picks the process with the highest score, kills it with SIGKILL, waits for the memory to come back, and repeats if the pressure has not eased. Thresholds come from the ro.lmk.* properties and are tuned per device: a phone with 4 GB kills far earlier than one with 12 GB, which is why the bug reproduces on the tester's old device and never on the developer's new one.

# The ladder as ActivityManager sees it: proc state, oom_adj, and why
adb shell dumpsys activity processes | grep -A3 "com.example.app"
#   Proc # 4: cch+5  T/ /CAC  trm: 0 4120:com.example.app/u0a231 (cch-act)
#   oom: max=1001 curRaw=920 setRaw=920 cur=920 set=920

# The kill itself, from the daemon
adb logcat -s lowmemorykiller
#   Kill 'com.example.app' (4120), uid 10231, oom_score_adj 920 to free 184372kB rss, ... reason: low watermark is breached

# And ActivityManager's own line for any kill it ordered
adb logcat -s ActivityManager | grep Killing
#   Killing 4120:com.example.app/u0a231 (adj 920): remove task

lmkd

The low memory killer daemon. Watches memory pressure and kills the process with the highest oom_score_adj until pressure eases.

oom_score_adj

A per-process integer from -1000 to 999 that both the kernel OOM killer and lmkd read to choose victims. ActivityManager sets it.

PSI

Pressure stall information: kernel counters of how long tasks waited for memory, CPU or IO. lmkd triggers on the memory one.

Cached process

A process with no active component, kept alive only in case the user comes back; the first to be killed.

The other suspects: users, vendors and the system itself

Everyone else who ends a process does so for a reason other than memory, and each leaves the app in a slightly different state afterwards, which is why the reason code matters more than the fact of the kill.

The user swipes the app away

Swiping a task out of Recents removes the task and, in stock Android, kills the process behind it unless that process is also running a foreground service. It is a polite kill: manifest receivers, alarms, scheduled jobs and push registrations all keep working, and Service.onTaskRemoved fires first so a service can tidy up. What the user loses is the task itself, so the next launch is a cold start with no saved Bundle: there is no screen to restore because the user said they did not want one.

The user presses Force stop

Force stop in Settings is the strong version. The process dies, the task goes, and the app is put in the stopped state: no manifest receiver fires, no alarm or job runs, no push message is delivered, until the user opens the app again by hand. Android treats it as "this app does nothing until I say so", and nothing in the app can undo it. This is also what many vendor power managers do to apps they judge idle, which is why a "battery saver" on one brand of phone can break alarms and messaging that work everywhere else.

The system's own reasons

• A permission changed. Revoking a runtime permission kills the process immediately, because a process that already checked the permission must not keep running with stale knowledge. Since Android 11 the system auto-resets permissions of apps unused for months, and that reset is a kill too.
• The package was updated. The old code is unmapped and the process ends. Afterwards the app receives ACTION_MY_PACKAGE_REPLACED, one of the few broadcasts that still reach a manifest receiver, so it can re-schedule what it needs.
• A dependency died. An app that holds a stable reference to a content provider, which an open Cursor does, is killed when the provider's process dies. The IPC article explains the stable and unstable references behind this.
• An ANR. In the foreground the user chooses to close the app; in the background the system kills it silently once the receiver or service timeout expires.
• The freezer. Since Android 11, and by default since Android 12, cached processes are frozen with the kernel's cgroup freezer: they keep their memory but get no CPU, so a leaked timer or a spinning thread in a background app costs nothing. The system thaws a process before delivering work to it. If someone makes a synchronous Binder call into a frozen process instead, the call cannot be answered, and the cleanest fix the system has is to kill the process.
• Excessive resource usage. Android 12 also limits phantom processes, the children an app forks with Runtime.exec or a native fork: at most 32 across the device, and any that burn CPU in the background are killed along with their parent.

stateDiagram-v2
  direction TB
  Foreground --> Cached: user leaves
  Cached --> Frozen: idle for a while
  Frozen --> Cached: work arrives, thawed first
  Cached --> Foreground: user returns
  Frozen --> Foreground: user returns
  Cached --> Killed: lmkd, swipe, policy
  Frozen --> Killed: lmkd, or a sync Binder call
  Killed --> Foreground: recreated from saved state

Stopped state

The condition after a force stop or a fresh install: the app receives no broadcasts, alarms or jobs until the user launches it explicitly.

Cached app freezer

The mechanism, default since Android 12, that puts cached processes into a cgroup freezer so they use no CPU; they are thawed before receiving work.

Phantom process

A process forked by an app outside the framework, such as a shell command; Android 12 caps them at 32 per device and kills the CPU-hungry ones.

What survives and what does not

After a kill the only things left are what was written somewhere outside the process: the system's own records about the app, and whatever the app put on disk.

flowchart TD
  A([Activity destroyed]) --> Q{Same process?}
  Q -- "Yes: rotation, locale, resize" --> R["New Activity in the old process"]
  R --> R1["ViewModel handed back<br/>singletons intact<br/>Bundle also delivered"]
  Q -- "No: the process was killed" --> D["New process, then a new Activity"]
  D --> D1["Application.onCreate again<br/>ViewModel rebuilt from scratch<br/>only the Bundle and disk remain"]

The middle rows of the table are where bugs live. A ViewModel feels permanent because it survives rotation, so teams put the shopping cart in it and never write it down. A Hilt or Koin singleton feels even more permanent, so a "session" object gets set at login and read everywhere; after a kill it is a fresh, empty singleton and the first screen that reads it crashes. Compose's remember is the same trap one level down: it is a cache for the current composition, not storage.

NonConfigurationInstances

An object the old Activity hands to the new one across a configuration change, inside the same process; the ViewModelStore travels in it.

SavedStateHandle

A key-value map given to a ViewModel whose contents are saved into the Activity's Bundle and restored after process death.

Saved state registry

The AndroidX mechanism that lets components register providers of saved state; rememberSaveable and Navigation both plug into it.

The system's own notebook: saved instance state

Saved instance state is a small Bundle the Activity fills when it leaves the screen, which system_server keeps alongside the task and hands back to the recreated Activity, so that the screen can be rebuilt without the process that drew it.

1. When it is written. onSaveInstanceState runs whenever the Activity may be destroyed and later restored. Since API 28 it runs right after onStop; on older releases it ran just before it. It does not run when the user finishes the Activity with Back, because there is nothing to come back to.
2. Where it goes. The Bundle is parcelled and sent to system_server with the stop transaction, where it sits in the ActivityRecord for that Activity. It is not written to disk: a reboot clears it, unless the Activity opted into persistableMode and used the PersistableBundle overload. The record of the task itself, with its root intent, is persisted so Recents survives a reboot.
3. How big it may be. It travels over Binder, so it draws on the same 1 MB budget as every other transaction; since Android 7 an oversize Bundle crashes the app with TransactionTooLargeException. The practical guideline is a few tens of kilobytes: ids, scroll positions, entered text, which tab. Never a list of items and never a bitmap.
4. How it comes back. After a kill, the user's return launches the top Activity of the task with the saved Bundle in onCreate(savedInstanceState) and again in onRestoreInstanceState after onStart. Activities lower in the back stack are not recreated yet; each one is instantiated with its own Bundle only when the user backs into it.

flowchart TD
  A1["Activity, pid 4120<br/>onSaveInstanceState"] -->|"sent with onStop"| B["ActivityRecord in system_server<br/>the Intent, plus the saved Bundle<br/>a few KB, held in RAM"]
  B -->|"onCreate(savedInstanceState), getIntent()"| A2["Activity, pid 9877<br/>a new process, same screen"]

Modern code rarely calls onSaveInstanceState directly. The AndroidX saved state registry routes the same Bundle to three places: SavedStateHandle for anything a ViewModel wants to keep, rememberSaveable for Compose state, and Navigation for the back stack. All three end up as keys in the Activity's Bundle and follow its rules and its size limit.

// A ViewModel that survives death: what the user typed lives in the handle, not in a field
@HiltViewModel
class CheckoutViewModel @Inject constructor(
    private val handle: SavedStateHandle,
    private val carts: CartRepository,
) : ViewModel() {
    // written into the Activity's Bundle on every change, restored on recreation
    val promoCode: StateFlow<String> = handle.getStateFlow("promo", "")
    fun onPromoChanged(code: String) { handle["promo"] = code }

    // the cart itself is data, so it is reloaded from disk, never saved into the Bundle
    val cart: StateFlow<Cart?> = carts.observe(handle.get<String>("cartId")!!)
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), null)
}

// Compose: the same idea one level down
@Composable
fun StepIndicator() {
    var step by rememberSaveable { mutableIntStateOf(1) }   // survives rotation and death
    var pulse by remember { mutableStateOf(false) }         // transient, survives neither
    // ...
}

ActivityRecord

system_server's object for one Activity in a task: its intent, its state, and the saved Bundle.

persistableMode

A manifest attribute that lets an Activity's task, and optionally a PersistableBundle of state, survive a reboot.

The evidence: reading the exit records

Since Android 11 the system remembers why each recent process of an app ended, and an app can read that history at its next start, so the question "who killed my process" has an exact answer instead of a guess.

getHistoricalProcessExitReasons on ActivityManager, given a package, a pid filter and a count, returns a list of ApplicationExitInfo, newest first. Each record carries the reason code from the suspects table, a free-text description written by whoever did the killing, the process's importance at the time (foreground, visible, service, cached), its PSS and RSS in bytes, the timestamp, and for an ANR a stream with the stack traces the system collected. It survives reboots. Reading it on startup and sending it to analytics turns "some users report lost state" into "0.8 percent of sessions on 4 GB devices end with REASON_LOW_MEMORY from the cached state".

// On the next launch: what happened to the last process, and what was it doing
class ExitReporter(private val context: Context) {
    fun report() {
        if (Build.VERSION.SDK_INT < 30) return
        val am = context.getSystemService(ActivityManager::class.java)
        val last = am.getHistoricalProcessExitReasons(null, 0, 1).firstOrNull() ?: return
        val note = last.processStateSummary?.toString(Charsets.UTF_8)   // our own last words, see below
        analytics.log("process_exit",
            "reason" to last.reason,               // REASON_LOW_MEMORY, REASON_USER_REQUESTED, ...
            "description" to last.description,     // "remove task", "stop com.example", ...
            "importance" to last.importance,        // IMPORTANCE_CACHED and friends
            "rssMb" to last.rss / 1_048_576,
            "screen" to note)
        if (last.reason == ApplicationExitInfo.REASON_ANR)
            last.traceInputStream?.use { uploadAnr(it) }
    }
}

// Anywhere: leave up to 128 bytes that will be attached to our death record
fun onScreenShown(route: String) {
    if (Build.VERSION.SDK_INT >= 30)
        context.getSystemService(ActivityManager::class.java)
            .setProcessStateSummary(route.toByteArray())
}

setProcessStateSummary is the underused half of the API. The app stores a short note, up to 128 bytes, and whatever kills the process, that note is attached to the record. Writing the current screen name into it on every navigation means the exit history says not just why the process died but where the user was, which is exactly the "steps to reproduce" a memory kill never comes with.

From the shell

# The same records, without writing code
adb shell dumpsys activity exit-info com.example.app
#   ApplicationExitInfo #0:
#     timestamp=2026-09-10 09:41:12.318 pid=4120 realUid=10231 ...
#     importance=400 reason=3 (LOW_MEMORY) subreason=0 (UNKNOWN) status=0
#     pss=71MB rss=142MB description=null state=checkout/3

# Every kill ActivityManager ordered, with the adj and the reason
adb logcat -b all -s ActivityManager:I | grep -E "Killing|Force stopping|has died"

# lmkd's own account, with the score and how much it freed
adb logcat -s lowmemorykiller

# Reproduce a memory kill on demand: background the app first, then
adb shell am kill com.example.app           # only kills processes that are safe to kill
adb shell am force-stop com.example.app     # the Force stop button, task and all

ApplicationExitInfo

A record of one process ending: reason, description, importance, memory, timestamp, optional ANR trace, and the app's own 128-byte summary.

Process state summary

A short byte array the app stores with setProcessStateSummary, attached to its next exit record.

Staying alive, honestly: the ranks you may hold

There is no way to opt out of being killed, but there are components the system ranks highly because they represent something the user can see or hear, and holding one while it is true is how an app legitimately stays up.

Everything else is folklore that stops working release by release: START_STICKY restart loops, a one-pixel "keep alive" Activity, playing silent audio, asking every user to disable battery optimisation. Each one either no longer works, gets the app flagged by the platform's resource police, or trains users to uninstall.

Foreground service type

A manifest declaration such as mediaPlayback, location or dataSync that says what a foreground service does; mandatory since Android 14 and tied to specific permissions.

Standby bucket

One of five bands, from active to restricted, that the system assigns each app from usage and that governs how often its jobs and alarms run.

Expedited work

WorkManager work that runs as soon as possible with foreground-like importance, subject to a quota.

Writing an app that shrugs it off

An app survives process death when every piece of state has a home outside the process or a way to be rebuilt, so that a fresh process starting on any screen can get back to a correct one without help.

Three tiers of state

1. UI state goes into saved state. What the user typed, which tab, which item is expanded, the scroll position, the ids of what is on screen. Small, per screen, via rememberSaveable, SavedStateHandle or Navigation arguments.
2. Data goes to disk. The cart, the draft, the session token, the last sync result. Room, DataStore or files, read through a repository that knows how to load on demand. Memory caches in front of it are fine as long as they are caches, empty on start and filled by a read.
3. Everything else is recomputed. Derived values, animation state, the connection to a service, an in-flight request. It is lost, and the screen must be able to say "loading" and fetch again.

Habits that follow

• No state in singletons without a load path. A SessionManager may hold the current user in memory, but its getter must fall back to disk. A lateinit in an Application subclass is a promise that onCreate ran, which it did; a lateinit set from a login screen is a promise that the login screen ran in this process, which after a kill it did not.
• Pass ids, not objects. Navigation arguments and intent extras should name things by id; the destination loads them. Passing the object works right up to the first restore, and a static "holder" for objects too big for the Bundle is the same bug with a different stack trace.
• Every screen can be the first screen. After a kill, the deep screen is created before anything above it, in a process where no earlier screen ran. If it depends on a result produced by a previous screen, that result must be on disk or in its arguments.
• Treat Application.onCreate as a fresh boot. It will run again, so initialisation must be cheap and idempotent, and anything that must be re-armed after a kill, such as an in-memory listener registration, belongs there and not in the login flow.
• Services too. A sticky service restarted by the system gets a null intent and an empty heap; it must reload what it was doing from disk or stop itself cleanly.

Testing it

Rotation tests the left branch of Figure 5 and proves nothing about the right one. "Don't keep activities" in developer options destroys the Activity on every leave but keeps the process, so ViewModels survive and the test is still the wrong one. Two things test the real path:

• The shell recipe: Home, adb shell am kill com.example.app, return through Recents. Do it on every screen, with the form half filled. Developer options also offer a "Background process limit" of "No background processes", which turns every Home press into a kill.
• In tests: Compose's StateRestorationTester saves and restores the composition through the registry, so a remember that should have been rememberSaveable fails the test. ActivityScenario.recreate() restarts the Activity with the saved Bundle but keeps the process, so it proves the Bundle path and not the singleton path.

@Test
fun promoCodeSurvivesRestoration() {
    val tester = StateRestorationTester(composeRule)
    tester.setContent { CheckoutScreen() }
    composeRule.onNodeWithTag("promo").performTextInput("SEPTEMBER")
    tester.emulateSavedInstanceStateRestore()               // save, tear down, restore from the Bundle
    composeRule.onNodeWithTag("promo").assertTextEquals("SEPTEMBER")
}

Mistakes that keep coming back

• Keeping the cart, the draft or the logged-in user only in a ViewModel or a singleton because "it survived rotation".
• Passing an object through a static holder to dodge the Bundle size limit, then reading null from it after a restore.
• A lateinit or a !! on something a previous screen was supposed to set.
• Saving a whole list or a bitmap into saved state and meeting TransactionTooLargeException on the tester's device only.
• Testing with rotation or "Don't keep activities" and concluding restoration works.
• Reading the swipe-from-Recents kill as a memory kill and the force-stop kill as a bug in the platform; the exit reason tells them apart.
• Holding a Cursor open across a screen's life and being killed when the provider crashes.
• Using a foreground service as a keep-alive for work the user cannot see; it fails review, gets killed anyway under pressure, and Android 14 asks you to name a type it does not fit.
• Not reading ApplicationExitInfo at startup, and therefore not knowing how often any of this happens to real users.

Recap