It's good to have an option like that, even being a default, but there definitively need a switch to disable that if it is your own will.
It's not even necessarily that good enough against cops, because in a lot of shitty countries, even some pretending to be democratics, not disclosing or at least inputting your password might be a crime severely punished.
If I'm not wrong, there was a guy that had to stay years in jail until he would comply with the judge order to unlock his device.
Interestingly, it could also be seen the other way around; it's a potential way for Google to force deployments of system updates (potentially at the request of law enforcement). With an automatic reboot, then the update can automatically be applied without user action.
This makes no sense, Android already will reboot itself after receiving an update and being inactive for a while (generally while charging it will install the update in its secondary partition, do some verification checks and reboot if there is no user interaction).
This sounds vendor-specific and not general for Android. I've never had that happen on any device but Windows and I would be very upset if it did happen.
This is super annoying on newer iOS for device that I use purely for development. Before it was possible just keep iPhone unlocked indefenitely, but now it reboots and boom I have to use TouchID again.
This is again Apple being Apple making things harder without option to disable it even when development mode is on.
Unfortunately I use Advanced Data Protection on my Apple account so I kind a need that passcode. And moving to having completely different Apple account for development is PITA.
But I think connecting a device that can be used as authentication method without choosing a defense would negate the purpose of advanced data protection of your account and other devices.
>not disclosing or at least inputting your password might be a crime severely punished
And to your point, I believe it's now the case in the U.S. that you can be legally compelled to unlock a fingerprint lock, but not a pin for whatever reason.
Compiled unlock via biometrics is still somewhat contested. The general argument boils down to biometrics being something you can't really protect internally. A passcode that is only known inside of your gray matter can therefore can only be externalized via some sort of testimony. Being compelled to reveal a passcode violates your ride against compelled speech and self-inccrimination.
In US you are protected by 5th. But it seems like the question hasn't been addressed by the Supreme Court since currently the answer depends on your jurisdiction. Which inspired me to check: here in Pennsylvania, the court cannot compel you to unlock your device with the password.
I don't get the difference. Today after 72 hours (3 days) my phone asks me for my password and won't accept biometrics. Also, this is a problem for all the people that use them as alarm clocks. I use Alarm Clock Xtreme for example.
(At least on iOS) shutting down the phone has something to do with wiping credentials/keys from RAM from where they can potentially be dumped. A just-booted phone is fully encrypted with no keys in memory.
For this use case there needs to be a reasonably quick way to erase/permanently lock a phone. Or maybe it needs to be something that is both 1. Less severe than that 2. Secure against personal inducements 3. More automatic.
So maybe something like a paired app with a friend/someone who is beyond the reach of the authorities, and if the phone isn't unlocked in a given definable period (or it can be triggered immediately), it then can't be unlocked without that person's active cooperation.
That's off the top of my head, so I'm sure there are optimizations.
This just gave me an idea: How about the phone accepting 2 password. One is the regular password and brings you into your regular account and then a dummy password that brings you into a dummy (but somewhat plausible, maybe user set up) account. That way you can still enter your normal account whenever you feel like it and if you are being pressured you just put in your "alternative password" and it just brings you to the dummy account.
But the problem is that when authority wants you to unlock your device, they kind of already know why, what they are expected to find but they would that as a more complete proof. But from external input they would expect some downloaded files or accounts (like social accounts you were connected with your phone a minute ago), some SMS they saw passing, some call logs, so connection to your known accounts...
I was thinking this would be the final death knell to using an (unrooted) Android phone as a cheap home server. But then again, not sure if that was even possible before with all the "battery protection" logic built into Android.
As the GrapheneOS docs note, the feature is better implemented in init and not in system server or the app/services layer like Google has done here? Though, I am sure Google engs know a thing or two about working around limitations that GrapheneOS developers may have hit (in keeping the timer going even after a soft reboot, where it is just the system server, and the rest of the userspace that depends on it, that's restarted).
Huh, I have GrapheneOS and I never noticed it rebooting. (And when i manually reboot, the "BIOS" prevents it from booting without acknowledging that I'm aware it's a non-Google OS, so how does it work?)
The feature is not enabled by default. Also, the boot doesn't wait for you indefinitely - it just gives you a few seconds to glance the checksum and halt it, before it proceeds automatically.
You don't have to acknowledge anything. The boot screen shows a warning which you can interrupt. If you don't do anything it'll continue to load as normal.
Its not an OS update, its a Google Play Services update .. so if they still apply you would get it
I found it strange that things like 'prettier settings screens' and 'improved connection with cars and watches' would be included in Google Play Services. Surely those things are part of the OS not part of a thing which helps you access the Play store?
I've been using a LineageOS (prev. Cyanogenmod) phone for years and have never installed any google stuff so I don't get these updates anyway.
The system only reboots once it has been locked for a particular duration. Setting it to 1 minute basically says: put the system into a more secure state (e.g. purge unencrypted memory) and ensure that it is ready to go when I next need it. That said, while it is not unrealistic it would be problematic since accidentally letting the phone lock (e.g. input timeout) would result in a time consuming reboot.
Not bad. If I could make a feature request it would be something like, After 3 days of being idle:
- [ ] Reboot
- [ ] Power Off
- [X] WIPE triple opt-in
Maybe there is a custom phone OS for this that makes the phone act more ephemeral and network boot off my self hosted iPXE/immich server? A dumb smart phone so to speak. An ephemeral diskless phone.
> ...the new Play Services will limit that exposure to three days, even if it's plugged in.
This will be fun to track down after a long weekend in embedded devices once this android patch number is old enough to be baked into crappy payment terminals and mall kiosks.
« This actually caused some annoyance among law enforcement officials who believed they had suspects' phones stored in a readable state, only to find they were rebooting and becoming harder to access due to this feature. »
Wouldn't the phones run out of battery after a few days anyway?
Or do they keep them plugged in?
This won't help those of us living in countries where "elected" officials elect themselves. We haven't had a single honest election in decades (and probably won't ever have one), so measures like this are better than nothing.
> This actually caused some annoyance among law enforcement officials who believed they had suspects' phones stored in a readable state, only to find they were rebooting and becoming harder to access due to this feature.
Lmao.
> The early sluggishness of Android system updates prompted Google to begin moving parts of the OS to Google Play Services. This collection of background services and libraries can be updated by Google automatically in the background as long as your phone is certified for Google services (which almost all are). That's why the inactivity reboot will just show up on your phone in the coming weeks with no notification. There are definitely reasons to be wary of the control Google has over Android with elements like Play Services, but it does pay off when the company can enhance everyone's security without delay.
I'm surprised this is something taken seriously only now by stock android. Isn't it known universally that AFU devices are insecure? What's the point of adding strict password policies, biometrics etc, if data from a stolen phone can be (relatively) trivially be exfiltrated unencrypted?
Samsung's have had some feature that lets you set days of the week for the phone to restart (IME during early morning hours) automatically. It's not perfect but it's something. iOS seems to have some unclear logic to either restart or re-request password (not biometrics).
Android ships a feature called bootchart which you can use to prove that most of the time your phone spends booting.. it is actually far from bottlenecked on storage or compute - bugs to be fixed; not worked around with even more complexity. Heck, some phones do not even stop playing their vendors fancy animated logo when they are finished before the animation is.
Why would I want my phone to auto reboot without my intervention? Never mind that it’ll never make three days on a single charge even if I don’t touch it.
It is not clear to me at all why the ‘benefits’ presented outweigh the negatives (which is _my_ device doing anything without me instructing it to). Even if you can turn it off, this is apparently enabled by default.
Law enforcement keeping hold of my phone for 3 days is simply not a realistic problem for me. Coming back to an annoyingly locked phone after forgetting it for a weekend very much is. The chances of law enforcement wanting anything with it are low enough that dealing with an extra unlock is more likely to be an impactful issue, even considering the potential impact that law enforcement or others stealing it could have.
> Coming back to an annoyingly locked phone after forgetting it for a weekend very much is.
It is?
I mean, my iPhone asks me for my passcode every 7 days anyways. And that's the only thing that happens on reboot anyways.
Also, you forget your phone for a weekend? How do you do anything during that weekend, like keep in touch with loved ones, get driving directions, pull up a boarding pass, check for delays, look up restaurants?
Easy, do what we did before mobile phones—civilization existed for thousands years and worked quite well without them (Rome built an empire sans mobile phones, so did the English). We even ran and coordinated the largest and most organized event in human history—WWII—without them!
Some of us have not yet succumbed to phone addiction (I often go for quite some days without using a phone and still have a normal life).
Hey, if you want to go back to life in Ancient Rome, with the disease and lack of medicine, the slavery, the dictatorship... be my guest.
When you say civilization worked quite well for thousands of years, as an argument against mobile phones, I'm not sure you've quite thought your argument through... I don't think you'd want to be most people in most of those civilizations ;) Or maybe it's always been your dream to be a Russian serf?
That "something" is at least the entire userspace, so any attempt at doing so ends up being UX-equivalent to a full restart - while having a decent chance of leaving unintended trace data lying around in memory.
A full restart guarantees that everything will be wiped.
Restart - simple with known and predictable effects, data no longer accessible, all secrets flushed no matter where they were or cached.
Turn off disk encryption, suspend all running services, overwrite all secrets in the O/S wherever they are, and then restore all that on entering password. Probably can't do anything about secrets cached by actual apps.
Complex, hard to maintain and probably buggy.
It's not even necessarily that good enough against cops, because in a lot of shitty countries, even some pretending to be democratics, not disclosing or at least inputting your password might be a crime severely punished. If I'm not wrong, there was a guy that had to stay years in jail until he would comply with the judge order to unlock his device.
Don't think old Androids will get this update.
This is again Apple being Apple making things harder without option to disable it even when development mode is on.
Has anyone found a way to bypass it?
Don’t set it up with a passcode in the first place?
And to your point, I believe it's now the case in the U.S. that you can be legally compelled to unlock a fingerprint lock, but not a pin for whatever reason.
So maybe something like a paired app with a friend/someone who is beyond the reach of the authorities, and if the phone isn't unlocked in a given definable period (or it can be triggered immediately), it then can't be unlocked without that person's active cooperation.
That's off the top of my head, so I'm sure there are optimizations.
Currently only available for Pixel phones, 6 and later. Offers many other security-related features.
But the problem is that when authority wants you to unlock your device, they kind of already know why, what they are expected to find but they would that as a more complete proof. But from external input they would expect some downloaded files or accounts (like social accounts you were connected with your phone a minute ago), some SMS they saw passing, some call logs, so connection to your known accounts...
As the GrapheneOS docs note, the feature is better implemented in init and not in system server or the app/services layer like Google has done here? Though, I am sure Google engs know a thing or two about working around limitations that GrapheneOS developers may have hit (in keeping the timer going even after a soft reboot, where it is just the system server, and the rest of the userspace that depends on it, that's restarted).
I found it strange that things like 'prettier settings screens' and 'improved connection with cars and watches' would be included in Google Play Services. Surely those things are part of the OS not part of a thing which helps you access the Play store?
I've been using a LineageOS (prev. Cyanogenmod) phone for years and have never installed any google stuff so I don't get these updates anyway.
1. It's deployed to all devices and not subject to manufacturer approval for updates
2. It's easier to update without requiring user interaction or approval
3. It's closed source unlike Android so changes can't be incorporated by competitors
---
### Google Play services v25.14 (2025-04-14)
#### Security & Privacy
• [Phone] Enables a future optional security feature, which will automatically restart your device if locked for 3 consecutive days.
They went with 2^32-1 milliseconds or about 49.7 days.
We don't talk enough about Microsoft's strong legacy of security innovations, IMHO.
The minimum on GrapheneOS is 10 min and the maximum is 72 hours. It can also be disabled.
The system only reboots once it has been locked for a particular duration. Setting it to 1 minute basically says: put the system into a more secure state (e.g. purge unencrypted memory) and ensure that it is ready to go when I next need it. That said, while it is not unrealistic it would be problematic since accidentally letting the phone lock (e.g. input timeout) would result in a time consuming reboot.
- [ ] Reboot
- [ ] Power Off
- [X] WIPE triple opt-in
Maybe there is a custom phone OS for this that makes the phone act more ephemeral and network boot off my self hosted iPXE/immich server? A dumb smart phone so to speak. An ephemeral diskless phone.
This will be fun to track down after a long weekend in embedded devices once this android patch number is old enough to be baked into crappy payment terminals and mall kiosks.
Probably overall a good thing though.
Wouldn't the phones run out of battery after a few days anyway? Or do they keep them plugged in?
Lmao.
> The early sluggishness of Android system updates prompted Google to begin moving parts of the OS to Google Play Services. This collection of background services and libraries can be updated by Google automatically in the background as long as your phone is certified for Google services (which almost all are). That's why the inactivity reboot will just show up on your phone in the coming weeks with no notification. There are definitely reasons to be wary of the control Google has over Android with elements like Play Services, but it does pay off when the company can enhance everyone's security without delay.
All the more reasons to move to AOSP forks.
I don't know if it'll take a fancy buzzword or what. Unobtrusive software? Silent Software?
Samsung's have had some feature that lets you set days of the week for the phone to restart (IME during early morning hours) automatically. It's not perfect but it's something. iOS seems to have some unclear logic to either restart or re-request password (not biometrics).
This should be standard
> Security & Privacy
> [Phone] Enables a future optional security feature, which will automatically restart your device if locked for 3 consecutive days.
So it only "enables" a "future" "optional" feature.
Why would I want my phone to auto reboot without my intervention? Never mind that it’ll never make three days on a single charge even if I don’t touch it.
The BFU state is more secure than AFU.
Even if you somehow live in a jurisdiction with a perfect justice system, that doesn't mean everyone else is.
Whos justice system? Lots of countries represented on HN. Many with questionable systems.
Law enforcement keeping hold of my phone for 3 days is simply not a realistic problem for me. Coming back to an annoyingly locked phone after forgetting it for a weekend very much is. The chances of law enforcement wanting anything with it are low enough that dealing with an extra unlock is more likely to be an impactful issue, even considering the potential impact that law enforcement or others stealing it could have.
That's what cops and spooks would like to have you think.
It's not a problem, until it suddenly is.
It is?
I mean, my iPhone asks me for my passcode every 7 days anyways. And that's the only thing that happens on reboot anyways.
Also, you forget your phone for a weekend? How do you do anything during that weekend, like keep in touch with loved ones, get driving directions, pull up a boarding pass, check for delays, look up restaurants?
Easy, do what we did before mobile phones—civilization existed for thousands years and worked quite well without them (Rome built an empire sans mobile phones, so did the English). We even ran and coordinated the largest and most organized event in human history—WWII—without them!
Some of us have not yet succumbed to phone addiction (I often go for quite some days without using a phone and still have a normal life).
When you say civilization worked quite well for thousands of years, as an argument against mobile phones, I'm not sure you've quite thought your argument through... I don't think you'd want to be most people in most of those civilizations ;) Or maybe it's always been your dream to be a Russian serf?
Why not flush something properly in the RAM instead to wipe the "cached" secrets?
A full restart feels like an overkill.
A full restart guarantees that everything will be wiped.
https://blogs.dsu.edu/digforce/2023/08/23/bfu-and-afu-lock-s...
Restart - simple with known and predictable effects, data no longer accessible, all secrets flushed no matter where they were or cached.
Turn off disk encryption, suspend all running services, overwrite all secrets in the O/S wherever they are, and then restore all that on entering password. Probably can't do anything about secrets cached by actual apps. Complex, hard to maintain and probably buggy.