Short answer: pull the microSD card, or make sure the app saved to shared storage in the first place. Google's own USB instructions start with "Unlock your device" and then ask you to tap a notification on its screen — three of the four steps need the phone in your hands. A security camera is a phone you deliberately mounted, locked, and walked away from. The retrieval method everybody recommends assumes the one posture your camera phone is not in.
This guide covers the routes that actually work on a mounted phone, the folder that quietly makes retrieval impossible, and a three-minute test to run before you tape anything to a window.
How do I get the video off my old phone security camera?
There are four routes, and they are not equally available to a phone that is up on a shelf:
- Pull the microSD card and read it in a card reader. Works with the phone locked. Requires that the app was recording to the card.
- Use the phone's own file manager to share the clip to your laptop over the local network. Works only if the recording was published to shared storage.
- USB cable. Reliable, but needs the phone unlocked and physically handled.
- Cloud upload. Convenient, and the thing you were trying to avoid by using an old phone in the first place.
Routes 1 and 2 both depend on a decision the app made when it wrote the file — long before you wanted it back. That is the part nobody tells you.
The folder that decides everything
Android sorts app files into two very different places.
App-specific storage lives at Android/data/<package-name>/. It is private to the app. On Android 11 and higher, it is also fenced off from everything else on the device. Google's all-files-access documentation is blunt about the limit: even an app holding the MANAGE_EXTERNAL_STORAGE permission gets write access to internal storage "except /Android/data/, /sdcard/Android, and most subdirectories of /sdcard/Android." The same page adds that apps with the permission still cannot reach app-specific directories belonging to other apps, because those sit under Android/data/.
Read that as a user rather than a developer and it says something stark: if your recorder tucked last night's clip into its own Android/data folder, then no file manager you install can hand it to you — not even one you grant every permission Android offers.
Shared storage is the other option: Movies/, DCIM/, and friends, indexed by MediaStore. A file published here is visible to the system file manager, to the gallery, to a USB connection, and to any sharing target on the phone. There is one useful wrinkle in the same document — /sdcard/Android/media counts as shared storage, unlike its Android/data neighbour.
So the question to ask of any background recorder is not "does it save locally?" Almost all of them do. The question is "does it publish to shared storage, or bury the file in its own sandbox?" Our app writes finished recordings into Movies/ through MediaStore, which is why routes 1 and 2 stay open; the segment-rotation write-up walks through that write path in detail.
Why the app can't just fix this with a permission
The obvious developer answer — "we'll request all-files access" — is closed off, and not by the platform. Google Play restricts MANAGE_EXTERNAL_STORAGE to a specific list of app types: file managers, backup and restore, anti-virus, document management, on-device file search, disk encryption, and device-to-device migration.
A camera app is not on that list. Any recorder promising to reach into arbitrary folders for you is either not on Play, or is making a promise it will have trouble keeping at review time. The correct fix is architectural and happens at write time: publish to shared storage, and retrieval takes care of itself.
Route 1: the microSD card (best for a mounted phone)
If the phone has a card slot and the app records to the card, this is the only route that needs nothing from the phone's screen. Power down, eject the tray, read the card on a laptop.
Two practical notes. First, the same all-files documentation confirms that the SD card root and a USB OTG drive are reachable to a file-managing app, so an on-phone file manager can also move clips onto the card for you. Second, on a 24/7 recorder the card fills fast — a 1080p30 stream is roughly 108 GB a day, which is why retention settings matter more than card size. Copy what you need promptly; a rotation policy will overwrite it.
Budget handsets often have the card slot that flagship phones dropped. For once, the cheaper phone is the better camera.
Route 2: share it off the phone over your own network
If the clip is in shared storage, the phone's built-in file manager can send it straight to a laptop on the same Wi-Fi — no cable, no account, no cloud hop. This is the route that keeps a local-only setup local-only.
Worth being precise about one thing, because it is a common mix-up: a remote web console and file retrieval are different features. Our app's console lets you start and stop recording, switch cameras and check status from a browser over local Wi-Fi, behind a password — genuinely useful for a phone you cannot reach. It is a control surface. Getting the recorded files off the device is still routes 1, 2 or 3. If an app advertises browser-based control, check separately whether it also serves the recordings themselves; the two get marketed as one thing.
If you are opening anything to your LAN, the threat model for a phone-as-camera server is worth ten minutes.
Route 3: the USB cable, and what it costs you
Google's documented procedure is four steps: unlock the device, connect the cable, tap the "Charging this device via USB" notification, and choose File Transfer. It works well. It also means taking the camera down, waking it, unlocking it, and interrupting whatever it was recording.
Two failure modes worth knowing. Charge-only cables are extremely common and will connect without ever offering File Transfer — Google's own troubleshooting note is that not all USB cables can transfer files. And if the phone reboots while you are away, it comes back locked, which closes this route until you are physically present again; an unattended phone before first unlock is more limited than most people expect.
The three-minute test to run before you mount the phone
Do this while the phone is still on your desk:
- Record a 30-second clip with the app you intend to use.
- Open the phone's Files app and look in
Movies/orDCIM/. If the clip is there, you are fine — every route stays open. - If it is not there, look for an in-app export or "save to gallery" option and use it. If the only way to see your footage is inside that app's own player, treat that as the app's answer to this article.
- Lock the phone, then try your intended retrieval route once, exactly as you would at 7am on a Tuesday.
Step 4 is the one people skip. A route that works with the phone unlocked in your hand is not evidence about a route that has to work with the phone locked on a shelf.
What this does not tell you
Three honest limits.
The Android/data restriction is about what apps can reach. A computer connected over USB is a different path with its own rules, and behaviour there has varied by Android version and manufacturer — test yours rather than trusting a blanket claim, mine included.
I have described where our app writes and what its console does, and only what other apps publicly document about themselves. I have not inspected any competitor's storage code, and you should discount anyone who claims to have.
Finally, none of this addresses a phone that is stolen along with its card. Local-only storage means local-only loss. If footage matters, get a copy off the device on a schedule, not after an incident.
Background Camera RemoteStream records with the screen off and keeps everything on your device — no cloud uploads, no account, no subscription for local recording.
- Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
- More guides: https://superfunicular.com
Top comments (0)