The Camera Phone Is the Most Backup-Eligible Device You Own: What Android Auto Backup Actually Uploads From a "Local-Only" Camera

A phone running as a security camera is supposed to be the boring device in the house. It sits on a shelf, it points at a door, it writes video to its own storage, and nothing leaves the building. That is the whole pitch for the local-only approach, and it is the reason people choose it over a cloud camera.

Here is the part that took me a while to say out loud, and that I have written imprecisely myself in the past: the video files are not the only data on that phone, and Android has a documented, on-by-default system for uploading the rest of it to Google Drive.

It is called Auto Backup. It is not malware, it is not a dark pattern, and it is not something a camera app switches on. It is a platform service that every app targeting Android 6.0 or higher is enrolled in unless the developer opts out. And once you look at the conditions it requires in order to run, you discover something genuinely uncomfortable: a phone mounted as a camera satisfies every one of them, every night, more reliably than the phone in your pocket does.

This is a deep-dive into what that system actually copies, what it provably does not, and how to check the state of it on your own camera phone. Everything below is from Google's published documentation, quoted and linked.

Are my phone security camera recordings backed up to Google Drive?

Short answer: Almost certainly not — video files are far too large for the mechanism. Auto Backup gives each app "up to 25 MB of backup data per app user." A single night of recording is orders of magnitude past that. What can be uploaded is the app's settings data: shared preferences, databases, and internal files. The footage stays where it is. The configuration is the part that travels.

Does a local-only Android security camera app upload anything to the cloud?

Short answer: The app may upload nothing at all. Android, separately and underneath it, may still upload the app's stored settings to your Google Drive as part of a device-wide backup you enabled once and forgot. "Local-only" describes what the app does with your video. It does not describe what the operating system does with the app's data directory. Those are two different questions, and only the first one is answered by a store listing.

The mechanism, in Google's own words

The Auto Backup documentation is unusually direct. "Android preserves app data by uploading it to the user's Google Drive, where it's protected by the user's Google Account credentials."

Enrolment is automatic and the default is on:

"Apps that target Android 6.0 (API level 23) or higher automatically participate in Auto Backup... The default value is true."

What gets included by default is broader than most people assume. Google lists shared preferences files, files in internal storage via getFilesDir() or getDir(), files under getDatabasePath() — "which also includes files created with the SQLiteOpenHelper class" — and, notably, "files on external storage in the directory returned by getExternalFilesDir(String)."

That last one matters for camera apps, and I will come back to it.

Three directories are permanently out of scope: those returned by getCacheDir(), getCodeCacheDir(), and getNoBackupFilesDir(). The docs are emphatic that this is not negotiable — they "are always excluded even if you try to include them."

Storage behaviour is worth knowing precisely. Backup data lives "in a private folder in the user's Google Drive account, limited to 25 MB per app," it "does not count toward the user's personal Google Drive quota," and "only the most recent backup is stored. When a backup is made, any previous backup is deleted." Google also states the data "can't be read by the user or other apps on the device" — which means you cannot open it up and inspect what your camera app put there.

Why a mounted camera is the ideal backup candidate

This is the observation that made me want to write the piece. Auto Backup does not run whenever it likes. It runs when four conditions are all true:

"The user has enabled backup on the device... At least 24 hours have elapsed since the last backup. The device is idle. The device is connected to a Wi-Fi network (if the device user hasn't opted in to mobile-data backups)."

Now read that list as a description of a phone screwed to a wall pointing at a hallway.

It is on Wi-Fi permanently, because a LAN camera is useless otherwise. It is plugged in permanently. And it is idle in the system's sense — nobody picks it up, nobody scrolls on it, nobody has touched the screen since the day it was mounted. It is arguably the most consistently idle, most consistently connected device in the building.

Google's own caveat underlines the contrast: "In practice, these conditions occur roughly every night, but a device might never back up (for example, if it never connects to a network)." A phone that lives in a pocket, drops off Wi-Fi, and gets handled all evening is the one that might go days without qualifying. The camera phone qualifies nightly, without fail.

There is one brake: "To conserve network bandwidth, the upload takes place only if the app data has changed." A camera app whose settings are stable has little to send. But "the app data" includes anything the app writes into a backed-up directory — and a recorder is, by nature, an app that writes things continuously.

The lock screen is doing more work than you think

Here is the second inversion, and it is a security one.

Google's backup security recommendations draw a line that is easy to skim past:

"The Standard Android Backup system always encrypts backup data in transit and at rest. This encryption is applied regardless of the Android version in use and of whether your device has a lock screen. Starting from Android 9, if the device has a lock screen set, then the backup data is not only encrypted, but encrypted with a key not known to Google (the lock screen secret protects the encryption key, thus enabling end-to-end encryption)."

Read it twice. Encryption is unconditional. End-to-end encryption is conditional on a lock screen. The Auto Backup page says the same thing from the other side: the backup "is end-to-end encrypted on devices running Android 9 or higher using the device's PIN, pattern, or password."

Now consider what people actually do to a phone they are turning into a camera. They remove the PIN. It is the rational thing to do: you want to glance at the screen without unlocking, you want it to come back cleanly after a power cut without a human standing there to type a code, and the device is bolted somewhere only you go.

That decision is a reasonable convenience trade-off, and almost nobody making it knows it is also a decision about who holds the key to their cloud backup. The device most likely to have no lock screen is the device best positioned to back up every night. The two choices compound, silently, in opposite directions.

If you keep a lock screen on the camera phone, this whole section is moot and your backup is end-to-end encrypted. That is the fix, and it costs nothing but convenience. It pairs naturally with the Private Space walkthrough we published for phones mounted in shared rooms.

The quota trap nobody warns you about

Return to getExternalFilesDir(String) being backed up by default.

Suppose a camera app stores clips in its app-specific external directory rather than in shared media storage. Those files are, by default, in scope for backup. They are also wildly over the limit. Google documents the consequence:

"If the amount of data is over 25 MB, the system calls onQuotaExceeded() and doesn't back up data to the cloud. The system periodically checks whether the amount of data later falls under the 25 MB threshold and continues Auto Backup when it does."

So the failure is not "your video gets uploaded." The failure is that the backup silently stops happening at all. Your settings, your camera configuration, the thing you would actually want restored on a new phone — none of it is saved, because the recordings crowded it out. And there is no user-visible signal either way.

Both outcomes here are invisible. That is the honest summary of this entire subject: whichever way it goes, nothing on screen tells you.

Turning it off is less binary than it sounds

The obvious response is android:allowBackup="false". It works, with a caveat that Google flags specifically for modern apps:

"For apps targeting Android 12 (API level 31) or higher, this behavior varies. On devices from some device manufacturers, specifying android:allowBackup="false" disables cloud-based backup and restore... but doesn't disable device-to-device transfers for the app."

Cloud off does not mean data still. Device-to-device migration — the flow you use when you set up a new phone from an old one — is governed separately, through dataExtractionRules on Android 12+ (and fullBackupContent on Android 11 and lower; an app supporting both needs both files). And the default when you say nothing is permissive:

"If there are no rules for a particular backup mode, such as if the <device-transfer> section is missing, that mode is fully enabled for all content except for no-backup and cache directories."

There is also a flag built precisely for the lock-screen problem above: disableIfNoEncryptionCapabilities, which makes "the backup happen only if it can be encrypted, such as when the user has a lock screen." It is the correct setting for anything sensitive, and it is opt-in.

What the documentation does not tell you

Six gaps I could not close from the published pages:

1. No inventory. Because backup data "can't be read by the user or other apps," there is no supported way to see which files a given app actually uploaded. You can see that an app was backed up, not what was in it.
2. No retention number. Obsolete backup datasets are "automatically deleted after a period of inactivity." The period is never specified.
3. No quota signal to the user. onQuotaExceeded() is delivered to the app. Nothing surfaces to the person relying on the backup.
4. The OEM set is unnamed. "Some device manufacturers" ignore allowBackup="false" for D2D. Which ones is not published, which matters most on the budget devices this use case runs on.
5. "Idle" is undefined here. The scheduling section gives no threshold for what counts as an idle device.
6. Page staleness. The Auto Backup page carries Last updated 2026-02-26; the backup security page carries Last updated 2024-10-25. The two are not versioned together.

How to check your own camera phone

Nothing here requires a developer. Five minutes, in order:

1. Settings → Google → Backup. See whether device backup is on at all. If it is off, none of this applies to you.
2. Check the account. Whichever Google account is signed in is the destination. On a repurposed phone that is often somebody's old personal account, still there because nobody made a decision. Our piece on what stays signed in on a camera phone covers the wider version of this problem.
3. Set a lock screen. This is the single highest-value action on the list. It is the difference between encrypted and end-to-end encrypted.
4. Look at the backed-up app list in the Google One / Drive backup view. It will not show you contents, but it will show you participation.
5. Decide deliberately. Backup on with a lock screen is a defensible setup. Backup off is a defensible setup. Backup on with no lock screen, unexamined, is the one nobody chose on purpose.

Correcting something we wrote

In an earlier article on the most privacy-respecting way to run an old phone as a camera, we wrote of the recordings: "There is no copy on a server. There is no copy in a backup."

For the video files, that holds, and the 25 MB quota is the reason it holds. But the sentence was doing more work than it should have. App data is a different object from app recordings, and Android's backup system treats them differently. The precise claim is: your footage stays on the device; your app's configuration may not, depending on a system setting that has nothing to do with the camera app. We should have drawn that line the first time.

This is the same distinction as our LAN threat model piece: local-only is a statement about a data path, not a blanket privacy guarantee. Every architecture has edges. The useful thing is to name them.

Where this leaves the local-only case

Stronger, not weaker — but only when stated accurately.

A cloud camera uploads your video by design. That is the product. No setting removes it, because removing it removes the feature. What we are discussing here is an optional, user-controlled, encrypted, 25 MB copy of configuration data, which you can inspect the setting for in under a minute and turn off with one toggle. Those are not the same class of exposure, and pretending they are would be as sloppy as ignoring the issue.

The difference that matters is that this one is yours to decide. The video from a phone-as-camera setup is written to the phone and served from the phone. Background Camera RemoteStream records with the screen off and serves the live view from a web server running on the device itself, over your own network — there is no upload path in the architecture for the footage to take. What Android does with an app's settings directory is a platform decision, and now you know where the switch is.

That is the honest version. It is a better argument than the tidy one.

---

Background Camera RemoteStream turns an Android phone into a screen-off camera with local recording and a built-in web server for remote viewing on your own network. Google Play · superfunicular.com

Sources: Back up user data with Auto Backup (Android Developers, last updated 2026-02-26) · Security recommendations for backups (Android Developers, last updated 2024-10-25)