Your Offline Security Camera Is Guessing What Time It Is — How to Check It Before You Need the Footage

There is a moment every person running a phone as a security camera eventually reaches. Something happened. You open the folder, you find the clip, and you look at the time on it.

And then you have to decide whether you believe it.

We spend a lot of words on whether the footage exists, whether it is private, whether it survived the night. We spend almost none on whether the phone knew what time it was when it wrote the file. If you are running the camera the way this blog usually recommends — an old Android, no SIM card, local-only storage, no cloud account — there is a good chance it did not.

Here is why, how to check it in about two minutes, and what to do about it.

Both of Android's default automatic time sources need a network

Start with the setting everybody trusts: Settings → System → Date & time → Set time automatically.

That switch does not mean "the phone works out the time by itself." It means "the phone asks something else." AOSP's Time source priority page lists what it asks. Under The following sources are configured for use by default, there are exactly two entries:

• Telephony (NITZ) — Network Identity and Time Zone, a signal sent by a mobile carrier.
• Network (NTP) — the Network Time Protocol, over the internet.

Read that list again with an offline camera phone in mind. One of them needs a working SIM on a carrier network. The other needs the internet. In the default configuration there is no third option that works with neither.

The priority between them flipped at Android 12. The same page states it plainly: "By default in Android 12 or higher, the framework prioritizes NTP as the time source over NITZ because NTP is more accurate and reliable than NITZ. In situations where NTP isn't available, the framework falls back on NITZ." And for older hardware — which is most camera-duty hardware — "By default in Android 11 and lower, the framework prioritizes NITZ over NTP."

So a pre-Android-12 phone prefers the carrier signal it does not have, and falls back to the internet it also does not have. Newer Android reverses the order. Both orderings end in the same place on a phone with no SIM and no internet: nothing suggests a time, so nothing corrects the clock.

Android 12 did add GNSS as a possible time origin, but it is not one of the two sources that page lists as configured by default, and it needs a view of the sky — which is not where most indoor cameras live.

What the clock does when nobody is correcting it

Left alone, the phone keeps counting on its own oscillator. It does not stop and it does not announce a problem. It simply accumulates error, quietly, in one direction, for as long as you leave it.

You do not have to take my word for how seriously this is treated. AOSP's Network time detection page says it directly: "Overall system clock accuracy is also affected by the Android device's ability to track elapsed time accurately after a time signal is obtained. This is a concern with all timekeeping on Android, not just network time detection, which is why the time_detector service disregards old time suggestions."

That is the platform's own documentation saying the device's ability to hold time is a known concern, and that its remedy is to keep feeding the phone fresh signals. An offline camera gets no fresh signals at all.

Here is the number that makes this concrete, and it is worth sitting with. The same page gives the AOSP default for config_ntpPollingInterval as 64800000 milliseconds — 18 hours — and describes the design as "a single time query approximately once a day." That is the refresh rate for a phone that is online.

Which means the oscillator is not a fallback. It is the thing carrying your clock between refreshes, by design, even on a connected device. An online phone hands that job to the crystal for up to 18 hours at a stretch. An offline phone has been handing it to the crystal since the last time it saw a network — possibly the afternoon you set the camera up.

None of that is alarming on its own. It becomes relevant when you realise a timestamp you are treating as a fact was produced by this system, and then disconnected from it.

How to check your camera phone, in two minutes

You do not need tools for the first three steps.

1. Open the clock on the camera phone and compare it to a phone that has internet. Put them side by side. You are not looking for a perfect match — you are looking for how far apart they are. Seconds is normal. Minutes means the clock has been free-running for a long time. Hours or a wrong date means the phone lost power and came back with no way to re-learn the time.

2. Check the date, not just the time. A phone that has been fully powered down and restarted without a network can come back on a default date. If the year is wrong, every file it has written since then sorts wrongly too.

3. Look at the newest recording's filename and file date in a file manager. That is the number you will actually be handed in an emergency. If it disagrees with step 1, believe step 1.

4. If you have a computer and USB debugging enabled, adb shell dumpsys time_detector prints exactly what the phone thinks. It shows isAutoTimeDetectionEnabled(), the autoOriginPriorities() list for that device, a Time change log of clock changes and what caused each one, and separate Telephony suggestion history and Network suggestion history sections. On a truly offline phone, both history sections are the interesting part — because they are empty, and the Time change log stops at whenever the phone last had a network.

Four ways to fix it, cheapest first

1. Set it by hand, and write down when you did. Turn Set time automatically off, set the clock manually against a known-good phone, and note the date you did it on a sticker on the back of the phone. This costs nothing and it is honest: you are not claiming the clock is authoritative, you are recording when it was last true. Re-do it monthly. For a shop camera or a storefront phone, this alone puts you ahead of where most setups are.

2. Give the phone internet on a schedule, not permanently. The camera does not need to be online to record. If you can put it on Wi-Fi for a few minutes once a week — even a phone hotspot — automatic time detection will re-anchor the clock and you are back to the platform's normal accuracy. This is the best value-for-effort option for a low-data or intermittent-connection setup, because time sync is a tiny amount of traffic compared to anything else the phone would do online.

3. Leave the SIM in, if you have a spare one. If the phone is old but the SIM still works, even a carrier signal with no data plan can supply NITZ. Less accurate than NTP, per AOSP's own reasoning for the Android 12 reordering — but enormously better than a clock nobody has touched since March.

4. Keep the phone plugged in and do not let it fully power down. This does not correct drift, but it prevents the much worse failure in step 2 above: a cold boot with no network, which can lose the date entirely rather than merely bending it.

What the documentation does not tell you

Three things, stated plainly, because the gaps matter as much as the facts:

• AOSP publishes the polling intervals and the timeout, but no drift figure for the phone's own clock. There is no documented "your phone loses N seconds per week." That number depends on the specific hardware and its temperature, and a camera phone sitting in a warm window is not in a lab. This is exactly why the advice above is measure your own phone, not apply my number — anyone quoting you a universal drift rate is not getting it from this documentation.

• The values quoted here are the AOSP defaults. The same page notes device manufacturers can modify these. Your phone may ship with different intervals or a different server list. dumpsys time_detector shows you what yours actually does.

• A correct clock is not the same as provable time. Nothing in this article makes footage tamper-evident or gives it legal weight. It only stops you from handing someone a timestamp you have no reason to believe. If you are heading somewhere that a timestamp will be contested, talk to someone qualified about what that requires — I am not that person, and a filename is not an affidavit.

Where our app sits in this

I should be precise about this rather than flattering. Background Camera RemoteStream records with the screen off, stores locally, and serves a live view over your own network. It does not run its own clock, and neither does any other camera app I know of. Every app writing a file on Android gets its timestamps from the system clock, and the system clock is governed by what you just read.

So this is not a feature gap in one app or an advantage in another. It is a property of the platform that the offline setup makes visible — and the no-cloud setup is one I think is worth choosing. A cloud camera gets correct time as a side effect of talking to a server constantly. Take the server away and you take the side effect away too. That is a fair trade, and a better one when you know you are making it.

Ten minutes with a sticker and a second phone closes most of the gap. Do it before something happens, not after.

---

Related reading:

• Turn an old Android phone into a screen-off security camera (no cloud, LAN-only)
• The Most Privacy-Respecting Way to Use an Old Android Phone as a Home Security Camera
• What's the Cheapest Way to Set Up a Home Security Camera Without a Subscription in 2026?

Background Camera RemoteStream is free on Google Play. More at superfunicular.com.