Short answer: A Google Play services release note describes a security behaviour that restarts a phone which has stayed locked for three days running. A handset doing camera duty in an empty house satisfies that description by construction: it is locked, and nobody unlocks it. The restart is the cheap half. The expensive half is the state the phone comes back into, which Android calls Direct Boot, and the platform guide is plain that applications sit that state out unless they registered for it beforehand. This post reads the two documents side by side, separates the part of an unattended recording setup that is exposed from the part that is not, and ends with a test you can run on your own handset in an afternoon instead of guessing.
The line in the release notes
Google keeps a running changelog for the pieces of Android that update through Play rather than through a system image. It is worth knowing where it lives, because the entry that matters here is not on the current year's page at all — it sits in the Google system services release notes archive, under Google Play services v25.14 (2025-04-14), in the Security & Privacy section. Prefixed [Phone], it reads:
"Enables a future optional security feature, which will automatically restart your device if locked for 3 consecutive days."
Future and optional are the load-bearing words here, and they pull in opposite directions. Future means the note is announcing plumbing rather than a behaviour you can assume is switched on in front of you. Optional means that where it has surfaced, it has surfaced as something a person or a manufacturer decides, not as a fixed property of the platform.
I went looking for a follow-up entry. The current release-notes page carries no further mention of the behaviour anywhere in its 2026 entries, under Security and privacy or any other heading. The nearest thing to a successor is a System management line under Google Play services v26.24 (2026-06-22) — "This update adds a notice about how your current device screen lock is used for user data encryption" — which corroborates the tie between the screen lock and encryption that the rest of this post is about, and settles nothing about the restart.
So the note is roughly seventeen months old and the changelog has not returned to it. That is a real limit on what can honestly be said here: the criterion is documented in Google's own words, and the default state on your particular phone is not settled by those words. Vendor-by-vendor reporting exists. Reporting is not a first-party page, so it stays out of this post and the test at the end takes its place.
What the criterion selects for
Read the condition again on its own terms. It says nothing about a lost phone, a stolen phone, a phone in an airport tray or a phone in an evidence bag. What it names is a handset that has stayed locked for three days running, which is a description of a device nobody has interacted with.
Now describe an old handset mounted in a hallway, or taped inside a window, or sitting on a bookshelf pointed at a front door. The screen is off. The lock is engaged, because you set a screen lock before you left it somewhere. Nobody picks it up, because the entire point of the arrangement is that nobody has to. That phone is not an edge case for this criterion. It is the shape the criterion describes, held for weeks at a time.
This is the part that tends to get missed in checklists about leaving a phone recording. The failure modes people plan for are events: a power cut, a router reboot, an app update, a thermal shutdown. Something happens, and the recorder stops. Here the input is the absence of an event. Nothing happens, for long enough, and that is the input.
Direct Boot is the state on the other side
A restart on its own would be unremarkable. Phones restart. What makes this worth a post is where the phone lands afterwards, and Android has a name and a documented contract for it. From the platform security guide on supporting Direct Boot mode, the mode runs
"when the device has been powered on but the user hasn't unlocked the device"
and the rule that governs what is alive in there is stated in one sentence:
"By default, apps don't run during Direct Boot mode."
That is the default, and defaults are what an unattended device runs on. The guide is equally direct about the exception:
"Apps must register their components with the system before they can run during Direct Boot mode or access device encrypted storage."
Registration is a manifest-time decision. It is made when the application is built, by whoever built it, and it is not something a user can enable later from a settings screen. So for any given recorder on any given phone, the question of whether it draws breath before the first unlock was answered before you installed it.
Which phones are in this mode at all
It would be reasonable to assume this applies only to recent or high-end hardware. The guide says otherwise, and ties it to something you control:
"Most devices running recent versions of Android enable Direct Boot mode whenever a lockscreen credential (PIN, pattern, or password) has been set."
The guide narrows that in its next sentence — "Specifically, this is the case on all devices that use file-based encryption" — which is a property you can read off the handset, and step one of the test below reads it.
The trigger, then, is having a screen lock. That matters for the repurposed-phone case, because it puts two sensible instincts in tension. Setting a screen lock on a phone you leave in a shared hallway is good practice, and it is also the thing that puts the device into a mode where applications do not run until somebody authenticates. Neither instinct is wrong. They just have to be held at the same time, which is easier once you know the second one exists.
The storage half
There is a second consequence, and it is about lifetimes rather than locations. The guide describes the default storage area this way:
"Credential encrypted storage is available after the user has successfully unlocked the device and until the user restarts the device."
The phrase to sit with is until the user restarts the device. Availability is not a permanent property that a phone acquires once, at setup, and keeps. It is granted by an unlock and revoked by a restart, over and over, for the life of the handset. Whatever depends on that area depends on a human being having touched the phone more recently than the last reboot.
The guide is then careful about what does not revoke it:
"If the user enables the lock screen after unlocking the device, credential encrypted storage remains available."
That sentence fixes the direction of the whole section. Locking the screen is not what closes the door; you can leave the phone locked for a fortnight and nothing changes. A restart is what closes it. Which is exactly why a documented behaviour that restarts an idle handset deserves more attention than any amount of time that handset spends locked.
And the far side is equally explicit:
"Once the user has unlocked the device, all components can access both the device encrypted storage as well as credential encrypted storage."
So the shape of the whole thing is a gap, not a break. Everything is available again the moment somebody unlocks the phone. The question is who that somebody is and how far away they live, which for a camera in an empty house is the whole question.
What this actually costs an unattended setup
Be careful about how far this reasoning is pushed, because it is easy to overrun what the documents say. Two pages, one about a Play services behaviour and one about a platform mode, do not tell you what any particular application writes, where it writes it, or whether it registered to run early. They tell you the conditions the platform imposes. The consequences for your setup depend on software neither page is about.
What the pages do let you do is stop reasoning about your phone as if uptime were a single number. Most advice about long-running phone cameras is about the process clock: how many hours the app survives before something kills it. Running underneath it is an unlock clock, which counts from the last time a person authenticated on that handset and which nothing a recording app does will reset. The behaviour in the release note runs off that second clock, and almost nothing written about phone cameras mentions it.
A test that answers it for your handset
None of the above tells you what your phone does. This does, and it takes an evening.
One. Find out whether the phone uses file-based encryption at all. With developer options and USB debugging on, from a computer:
adb shell getprop ro.crypto.type
If that prints file, the phone is on the encryption scheme the Direct Boot guide is describing. If it prints something else, the storage half of this post may not apply in the same way, and the restart half still might.
Two. Search your settings. Open the phone's settings search and try the words restart, inactivity and auto. Manufacturers name things differently and some do not expose this at all, so a null result is a result: write down what you found, including nothing.
Three. Run the reboot deliberately, and then do the hard part, which is not unlocking it. Restart the phone with the recorder configured the way you actually leave it. Let it land on the lock screen. Walk away for an hour. Do not touch it. Then unlock it and look at the newest file. If the newest file is older than the restart, you have just watched the gap this post is about, on your own hardware, on a Tuesday, rather than during the week you were away.
Four. Write down the answer next to the phone. Not in a notes app on a different device. The next person to think about this arrangement is you, in several months, having forgotten which handset gave which answer.
What I could not establish
Three things, stated plainly, because a post like this is more useful with its edges marked.
Whether the restart behaviour is enabled by default on any specific phone. The archive note says future and optional and the current year's notes add nothing, so the honest answer from first-party sources is that it depends on the handset and you have to look.
What any particular recording application does before first unlock. That is a property of the application, decided in its manifest, and it is not visible from these pages. The reboot test above is the cheapest way to find out, and it works regardless of which app you use.
Whether a phone with no screen lock is better off. It sidesteps one behaviour described here and it changes a great deal else about a device you are leaving in a room you are not in, so it is not a trade this post is going to recommend either way.
The practical shape
The useful takeaway is not a setting. It is a habit of mind about which clock you are on. An arrangement whose whole virtue is that it needs no attention is an arrangement that accumulates uninterrupted locked time faster than any phone in a pocket, and locked time is the quantity the release note names. Anyone who walks past the phone and unlocks it once a week has, without meaning to, been maintaining it.
Sources, all first-party, read on 2026-09-07:
- Google — Google system services release notes archive, Google Play services v25.14 (2025-04-14), Security & Privacy
- Google — Google system services release notes, checked for a follow-up entry; none in the 2026 entries
- Android Developers — Support Direct Boot mode
We build Background Camera RemoteStream — it records with the screen off, keeps footage on the device, and serves a live view from a small web server on the phone itself.
Top comments (0)