A foreground service is the standard answer to "how do I keep an Android camera recording when nobody is looking at the screen?" It is our answer too. We have written it several times.
On a phone with 2 GB of RAM, that answer is incomplete in a way the usual explanations do not admit. A foreground service raises your priority. It does not make you immortal. Android publishes a ranked list of what it kills when memory runs out, and there is a tier above yours — several, in fact.
This matters most on exactly the devices people actually turn into cameras: the old handset in the drawer, the spare phone at the shop counter, the budget Android with a working lens and a cracked corner. Those phones are not underpowered flagships. They are running a memory manager making different decisions.
Here is what the platform documentation actually says, and the six things it does not.
Why does my phone camera app stop recording on a cheap Android phone?
Short answer: Because Android's low memory killer (LMK) terminates processes when RAM runs out, and a foreground service is not exempt from it. Google's own guidance states that a user-perceived LMK includes kills "that happen while your app is displaying an activity or running as a foreground service," and that these are "an immediate, non-graceful process exit." On a low-RAM phone, the fix is usually not a setting inside the camera app — it is reducing what else on the phone is competing for memory.
Can Android kill a foreground service that is recording video?
Short answer: Yes. A foreground service moves your process down the kill list, which means the system kills other things first — background apps, the previous app, even the launcher. But if memory pressure continues past those tiers, services are still killed, and they are killed before "perceptible apps" and before the foreground app. The service is a priority, not a guarantee.
Everything below is sourced to Google's published Android documentation. Where the documentation is silent, this article says so instead of guessing.
The premise that surprises people: free memory is wasted memory
Android's memory page opens with a sentence worth reading twice:
"The Android platform runs on the premise that free memory is wasted memory. It tries to use all of the available memory at all times."
This is not a bug and it is not the phone being old. The system deliberately keeps closed apps resident so users can switch back to them quickly. The documented consequence: "Android devices often run with very little free memory."
So when you check a budget phone and see almost no free RAM, you have learned nothing about whether your camera is safe. That number is supposed to look like that. What matters is what happens when the system needs memory and does not have it.
Two mechanisms handle that. First kswapd, the kernel swap daemon, reclaims memory: it deletes clean pages (pages backed by an unmodified file on storage, which can always be re-read) and it compresses dirty pages into zRAM — "a partition of RAM used for swap space. Everything is compressed when placed into zRAM, and then decompressed when copied out of zRAM."
That word decompressed is the part that costs a camera. zRAM is not free storage; it is a CPU trade, and on a phone already spending CPU on continuous video encoding it is additional thermal load — a separate failure mode covered in our guide to running a phone 24/7 without cooking the battery.
Android also does not swap to storage the way desktop Linux does, because "frequent writing can cause wear on this memory, and shorten the life of the storage medium." Compressed RAM is the only overflow valve, and it has a manufacturer-set ceiling.
When kswapd cannot free enough, the system calls onTrimMemory() to ask apps to release allocations. When that is not enough either: "the kernel starts killing processes to free up memory."
The kill order, in the platform's own words
The LMK daemon scores every process with an oom_adj_score. Processes with a high score die first. Google publishes the full ranking, highest-scoring (killed first) to lowest:
| # | Tier | What Google says it is |
|---|---|---|
| 1 | Background apps | "Apps that were run previously and are not currently active." Killed first. |
| 2 | Previous app | "The most recently-used background app." Ranked safer than other background apps because the user is likely to return to it. |
| 3 | Home app | "This is the launcher app. Killing this will make the wallpaper disappear." |
| 4 | Services | "Services are started by applications and may include syncing or uploading to the cloud." |
| 5 | Perceptible apps | "Non-foreground apps that are perceptible to the user in some way, such as running a search process that displays a small UI or listening to music." |
| 6 | Foreground app | "The app currently being used." |
| 7 | Persistent (services) | "Core services for the device, such as telephony and wifi." |
| 8 | System | "As these processes are killed, the phone may appear to reboot." |
| 9 | Native | "Very low-level processes used by the system (for example, kswapd)." |
Read tier 4 against tier 3. A recording service is safer than the launcher — the wallpaper goes before your camera does. That is genuinely reassuring, and it is why the foreground-service architecture is the right one. We explain the mechanics of it in why an Android camera stops recording when the screen turns off.
Now read tier 4 against tiers 5 and 6. Under enough pressure, your recording service is released before a music player that is merely audible, and before whatever the user happens to be looking at. On a 2 GB phone where someone occasionally picks up the camera-phone to check something, "whatever the user is looking at" is a real competitor.
And the last line of that documentation page removes any remaining universality: "Device manufacturers can change the behavior of LMK."
The kill is silent — which is the actual problem
Google describes what an LMK looks like from the user's side, for a normal app:
"Killing the foreground app looks like an application crash which might indicate to the user that something is going wrong with the device."
A background camera has no foreground app. There is nothing on screen to crash. The process exits — "an immediate, non-graceful process exit," per Android vitals — and the phone sits there looking exactly as it did a second earlier. Screen off. Charging light on. Recording nothing.
A non-graceful exit also does not get to finish writing the file. If you have ever pulled a video off a phone and found it unplayable, the moov atom explanation covers what is missing and how to recover it.
The restart assumption that low RAM breaks
If your power is unreliable, you are probably relying on the camera coming back by itself after the phone reboots. Android's Go edition guidance addresses that directly, and it is not encouraging:
"when a device restarts, there is a
BOOT_COMPLETEDbroadcast that might be a requirement from many services or apps running on a user's device. This persistent broadcast can lead to apps not launching, or having foreground tasks fail, due to low memory on a device."
Every app that wants to wake at boot wakes at the same moment, on the device with the least memory to absorb it. The worst moment for a low-RAM phone to start a camera service is the exact moment it is being asked to.
That is a different failure from the ones in what happens during a power cut versus an internet outage — there, the phone survives because it has its own battery. Here the phone survives and the restart fails. Test it deliberately: reboot, walk away ten minutes, then check whether the stream is actually back.
The inversion: the most useful fix is not in the camera app
The standard advice for camera reliability is a list of toggles inside the camera app. On a low-RAM device the platform documentation points somewhere else entirely:
"All apps on a user's device directly impact memory availability. If these apps initiate broadcasts or services, then it becomes mandatory for Android (Go edition) apps to query post-boot system memory availability."
Your camera's survival is decided by a budget it does not control. Every social app, shopping app, delivery app and preinstalled utility with a background service is spending from the same pool. So on a dedicated camera phone, the highest-leverage move is subtraction:
- Uninstall, do not just close. A closed app is a cached process the system is deliberately keeping resident. Uninstalled is uninstalled.
- Sign out of accounts you do not need on that device. Sync is a documented example of what services do.
- Turn off auto-updates for everything else on that phone. An update is a process doing work at a moment you did not choose.
- Do not use the camera phone as a phone. Every app you open there is a tier-6 competitor.
- Test after a reboot, not after a fresh install. Post-boot is the constrained state; a freshly-started phone with everything else already loaded is the honest test.
There is a design point buried in this: an app with no login, no analytics uploader and no third-party libraries has fewer processes to keep resident and fewer reasons to wake. Local-only architecture is usually argued on privacy grounds. On a 2 GB device it is also a memory argument. We collect the local-only options in our no-subscription roundup.
How to find out whether this is what happened to you
Android provides a way to stop guessing. ApplicationExitInfo "returns the reason why the previous game run was killed by the Android system," and it exposes REASON_LOW_MEMORY specifically. If a developer has wired it up, the app can tell you that the last session ended in a memory kill rather than a crash, a thermal shutdown, or the OS taking the camera away — which is its own distinct failure mode.
Two notes for developers. Android vitals tracks a User-perceived LMK rate — "the percentage of your daily active users who experienced at least one user-perceived LMK" — and Google's threshold is that a rate "above 1% indicates a critical need for immediate action." A low rate is not proof of health, though: it "might mean that the LMK daemon is frequently killing processes while they are in the background."
And most memory trim callbacks are gone. Android deprecated all of ComponentCallbacks2's trim constants other than TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND, stating plainly that "Trim callbacks haven't been helpful at preventing low-memory kills." A legacy trim signal is a notification that no longer arrives.
What the documentation does not tell you
Six things these pages do not state, listed so nobody fills them in from imagination:
- Where a foreground service lands in the ranking. The tier list has "Services." It never says whether a foreground service scores the same as an ordinary one, or how much better.
- The RAM threshold that triggers killing. The text says the system starts killing "if the amount of free memory falls below a certain threshold." No figure, no units, no per-device formula.
- How far manufacturers deviate. "Device manufacturers can change the behavior of LMK" is stated with no bound on the change.
- The maximum size of zRAM. "Device manufacturers can set the maximum size" — no default, no typical range.
- A memory budget for a video app. Go-edition guidance covers bitmaps, GIFs and PNG compression. It offers no target for an app holding a continuous encoder pipeline.
- What happens to a file mid-write when the kill lands. "Immediate, non-graceful process exit" is the whole description. Whether the last seconds of video survive is not addressed anywhere in these pages.
This piece also makes no claim about how any other camera app behaves under memory pressure. Nobody publishes that, and process behaviour is not observable from a store listing.
The honest summary
A foreground service is the right architecture and it is not a promise. On a phone with plenty of RAM the distinction rarely surfaces. On the 2 GB handset that is the whole point of reusing an old phone, it surfaces as an empty recording nobody noticed for three days.
The mitigation is unglamorous: fewer apps on the camera phone, a real post-reboot test, and a camera app that keeps its resident footprint small — no cloud uploader, no account session, no ad libraries. The same design decision keeps showing up as both a privacy answer and a performance answer.
Background Camera RemoteStream records with the screen off, streams to your own browser over your own network through a built-in web server, and keeps files on the device. No account, no cloud, no subscription.
- Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
- Website: https://superfunicular.com
Sources
- Memory allocation among processes — Android Developers
- Low memory killers — Android Developers
- Develop for Android (Go edition) — Android Developers
- Optimize app memory — Android Developers
Top comments (0)