If you run an old phone as a camera on a prepaid SIM, you will meet Data Saver sooner or later. Someone turns it on to save data, or the phone suggests it when the data pack is running low. And then the question: will the camera still stream over mobile data with the screen off, or will Android quietly cut it off?
We answered this question once before and got part of it wrong. This is the corrected answer. It comes from Android's own source code, not from a guess about what "background" means.
Does Android's Data Saver block a screen-off camera stream on mobile data?
Short answer: it depends on how the app keeps running, not on whether the screen is on.
- Android decides who gets data under Data Saver by process state. In the current Android Open Source Project (AOSP) source, any app at or above the "bound foreground service" state counts as foreground and keeps its network access on metered networks.
- An app that runs a proper foreground service (the kind that shows a notification that cannot be swiped away) sits above that line. Data Saver alone should not cut its stream.
- An app that is only "the screen on top", with no foreground service, drops to a state called top sleeping when the screen turns off. AOSP treats that as background. Under Data Saver, on mobile data, it loses network access.
Two warnings before anyone relies on this. Phone makers can and do add their own data and battery rules on top of Android's. And Data Saver is only one of the switches that can stop mobile data. So the honest advice is still: allow the camera app Unrestricted data, and test it once with the screen off.
The correction
In Live View Stopped, Recording Did Not we wrote that a camera app streaming with the screen off "is, as far as the system is concerned, exactly the sort of background data usage Data Saver exists to block."
That sentence is too broad. In the same article we also listed, under "what the documentation does not tell you", that nothing in the Data Saver documentation addresses a foreground service that streams continuously. That gap was real. The documentation does not cover it. The source code does.
The practical advice in that article (add the camera app to Data Saver's unrestricted list) still stands. The reason we gave for it was wrong for apps that use a foreground service.
What the documentation says
Google's developer page for Data Saver describes the behaviour like this:
"When a user enables Data Saver in Settings and the device is on a metered network, the system blocks background data usage and signals apps to use less data in the foreground wherever possible."
The Pixel help page puts it in plainer words:
"This mode lets most apps and services get background data only via Wi-Fi. Currently active apps and services can use mobile data."
Neither page defines "background" or "currently active". For a phone lying face-down on a shelf with the screen off, that definition is the whole question.
What the source code checks
The decision lives in NetworkPolicyManager.java in AOSP frameworks/base. On the current main branch the method that decides whether an app may use the network while Data Saver is on reads:
public static boolean isProcStateAllowedWhileOnRestrictBackground(int procState,
@ProcessCapability int capabilities) {
if (procState == PROCESS_STATE_UNKNOWN) {
return false;
}
return procState <= FOREGROUND_THRESHOLD_STATE
// This is meant to be a user-initiated job, and therefore gets similar network
// access to FGS.
|| (procState <= ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND
&& (capabilities
& ActivityManager.PROCESS_CAPABILITY_USER_RESTRICTED_NETWORK) != 0);
}
And the threshold is defined a few hundred lines earlier in the same file:
public static final int FOREGROUND_THRESHOLD_STATE =
ActivityManager.PROCESS_STATE_BOUND_FOREGROUND_SERVICE;
The comment in the code even uses the abbreviation: user-initiated jobs get "similar network access to FGS". FGS means foreground service. The code treats a foreground service as allowed under Data Saver.
This is not new. The Android 9 version of the same file already had a FOREGROUND_THRESHOLD_STATE set to PROCESS_STATE_BOUND_FOREGROUND_SERVICE and a Data Saver check of procState <= FOREGROUND_THRESHOLD_STATE. The numbering of the states has changed between versions, so do not carry exact numbers from one Android release to another.
Where screen-off apps land
Process states are an ordered list. Lower numbers mean "more important to the user". In the current list (ProcessStateEnum.aidl, as mirrored from AOSP):
| State | Value | Under Data Saver, on a metered network |
|---|---|---|
TOP (the app you are looking at) |
2 | Allowed |
BOUND_TOP |
3 | Allowed |
FOREGROUND_SERVICE |
4 | Allowed |
BOUND_FOREGROUND_SERVICE |
5 | Allowed (this is the line) |
IMPORTANT_FOREGROUND |
6 | Blocked, unless the user-initiated-job capability applies |
SERVICE (ordinary background service) |
10 | Blocked |
TOP_SLEEPING |
12 | Blocked |
The comment on TOP_SLEEPING in that file reads: "Same as PROCESS_STATE_TOP but while device is sleeping." And current AOSP defines another constant right next to the foreground threshold:
public static final int BACKGROUND_THRESHOLD_STATE = ActivityManager.PROCESS_STATE_TOP_SLEEPING;
So Android itself draws the line in the place you would hope. The app on screen is foreground. The same app, once the screen goes dark, is not, unless something else holds it up. A foreground service is that something.
This is the difference that matters for anyone using an old phone as a camera:
-
An app that keeps the screen on to keep recording: while the screen is on it is
TOP, and fine. If the screen times out, it becomesTOP_SLEEPING. Under Data Saver on mobile data, its stream stops. - An app that records through a foreground service: it stays at the foreground service level with the screen off. Data Saver's process-state check lets it through.
What can still stop a stream on mobile data
Data Saver was never the only switch. Even an app that passes the check above can lose mobile data for other reasons:
- A data limit. On a Pixel, Settings → Network & internet → Internet → your operator → Data warning and limit. Google's help page is clear about what happens when the limit is reached: mobile data turns off, and "Some features won't work when mobile data is turned off." No process state survives that. We covered how to set a safe limit for a camera SIM in Should You Leave the SIM Card in an Old Phone Security Camera?
- The data pack running out. The operator cuts you off, not Android.
- The phone maker's own rules. Many Android skins add battery and data restrictions that Google does not document. The source code above is AOSP. Your phone's build may differ.
- The network changing underneath the app. Android can move an app to a different default network at any time. That is Reason 1 in the Live View Stopped article.
- The connection dropping for a while. What YouTube Live does with a stream that goes quiet is a separate question, with its own timers, covered in What Happens to a Phone's YouTube Live Stream When Mobile Data Drops?
Also remember the other half of the documentation sentence: Data Saver "signals apps to use less data in the foreground wherever possible." That is a signal, not a limit. Whether an app lowers its video quality when it sees it is up to the app.
Watching on your own Wi-Fi? Data Saver may not matter at all
Data Saver applies "on a metered network". If the camera phone is on your home or shop Wi-Fi, and that Wi-Fi is not marked as metered, the Data Saver check is not involved. Live view on your own network uses no mobile data at all, which is why we recommend it as the default setup for households and shops on prepaid plans.
One catch: a Wi-Fi network can be marked as metered, and phone hotspots often are. If your camera phone connects to another phone's hotspot, treat it as mobile data for this purpose. The hotspot setup is in How to Use an Old Phone as a Security Camera Without a Wi-Fi Router.
Why we still say "turn on Unrestricted data"
If a foreground service already passes the check, why bother? Two reasons:
- It costs nothing. It does not make the app use more data. It only removes one way the app can be blocked.
- Your phone may not be running plain AOSP rules. Unrestricted data is the user's own, documented choice, and it is the setting a phone maker's changes are most likely to leave alone.
On a Pixel: Settings → Network & internet → Data Saver → Unrestricted data, then turn on your camera app. Other phones put it in a different menu. Search Settings for "Data Saver" or "Unrestricted".
A ten-minute test for your own phone
Do this once, before you rely on the camera:
- On the camera phone, turn Wi-Fi off and Data Saver on.
- Do not add the camera app to Unrestricted data yet.
- Start recording and start a YouTube Live stream (or whatever remote view uses mobile data in your app).
- Turn the screen off. Leave the phone alone for ten minutes.
- Watch the stream from another device the whole time.
- Then add the app to Unrestricted data and repeat.
If the stream survives step 4, your phone and app pass. If it only survives step 6, keep Unrestricted data on and you are fine. If it fails both, the cause is something else on the list above.
For developers: checking it from code
You do not have to guess at runtime. ConnectivityManager.getRestrictBackgroundStatus() returns DISABLED, ENABLED, or WHITELISTED for your app. A small check before going live:
val cm = getSystemService(ConnectivityManager::class.java)
val warnUser = cm.isActiveNetworkMetered &&
cm.restrictBackgroundStatus == ConnectivityManager.RESTRICT_BACKGROUND_STATUS_ENABLED
if (warnUser) {
// Offer to open this app's data settings so the user can choose.
startActivity(
Intent(
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS,
Uri.parse("package:$packageName")
)
)
}
Things worth knowing from the docs:
- To hear about changes, register for
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGEDwithContext.registerReceiver(). The docs say apps that register for it in the manifest "will not receive them." - The AOSP Data Saver page asks apps not to "Ask to be whitelisted unless background data is truly part of core functionality." For a remote camera that streams, it is. For most other apps, it is not. Ask once, explain why, and let the user decide.
- To test without burning a data pack:
adb shell cmd netpolicy set restrict-background trueturns Data Saver on,adb shell cmd netpolicy set metered-network <WIFI_SSID> truemakes a Wi-Fi network count as metered, andadb shell dumpsys netpolicyshows the current rules and the apps allowed to bypass them. - Do not treat a foreground service as permission to use more data. The same AOSP page asks apps to "Use lower bitrate video" when Data Saver is on.
What this does not tell you
- The source above is AOSP's main branch. It is not a promise about any specific phone's firmware.
- We did not run this test on a phone for this article. The ten-minute test above is how to settle it on yours.
- The Data Saver developer page was last updated in January 2024. The source code is newer than the documentation, and the two may drift again.
- Nothing here says how any other camera app keeps itself running. We cannot see inside other people's apps.
About Background Camera RemoteStream
Background Camera RemoteStream turns an Android phone into a camera that records with the screen off, using a foreground service. Recordings stay on the phone. You can watch live from any browser on the same Wi-Fi, served by a small web server on the phone itself, with no cloud account and no subscription. When you need to watch from outside the house or shop, you can stream to YouTube Live instead.
It is free on Google Play. More guides are at superfunicular.com.
Sources (fetched 18 October 2026):
- Android Developers, Optimize network data usage (last updated 2024-01-03)
- AOSP, Data Saver mode
- Pixel Phone Help, Use less mobile data with Data Saver and Reduce and manage mobile data usage
- AOSP
frameworks/base, NetworkPolicyManager.java (main) - Android 9 NetworkPolicyManager.java (code.yawk.at mirror)
- ProcessStateEnum.aidl (AICP mirror of AOSP frameworks/base)
Top comments (0)