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.
Long Press power while pressing volume down works on all Android devices I've used to date.
And that's ignoring the fact that disconnecting power, waiting a few days and then reconnecting it will inevitably let you cold boot it, too (which this would be an equivalent to - as far as I understood it)
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 default on iOS and on many Android versions.
It's often configurable, but e.g. carrier policy or local vendors can enforce it.
To have updates automatically install overnight is the maximally desirable scenario - waiting for user approval usually result in open vulnerabilities, and if you interact with a prompt you are by definition using your device and it is therefore a much worse time than while you're asleep.
I haven't had that happen on iOS, but I have woken up in the night needing my flashlight just to find my phone applying a lengthy update. I have it set to download automatically and install manually now, I believe.
I haven't had any problems in at least 7+ years, but I work in coffee and I can remember at least two instances where an Apple update made half the staff late by turning off their alarms, myself included.
> 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.
This sounds a lot like the Regulation of Investigatory Powers Act 2000 in the United Kingdom, where several people have been prosecuted and imprisoned for failing to provide encryption keys.
Why so dismissive of how somebody wants to re-use an old phone that you would compare them to the absurd fictitious behavior in that comic? Would you rather they become e-waste? If it fits their needs then it fits their needs regardless of the use-case that was marketed.
It's a Google Play Services update, likely explicitly to be able to push it to all (Google-using) Android phones immediately, without waiting for OS updates. This will not be a "Guess I'll get it in a few years" update.
I generally like XKCD but dislike the message in this comic. If that's that guy's workflow, they don't have to actively support it, but he should be given the option to disable updates so he can continue to use his tools in the way he sees fit.
I can only second this. I have an old iPhone with a second sim-card, because I need it from time to time. And Apple introduced this auto-reboot a bit earlier, iirc last year. The problem is that after rebooting it also disconnects from wifi, so e.g. SMS/handoff synchronization stops working until you enter a passcode. This is very annoying because it was very convenient for me to receive calls/SMS to my main iPhone.
It’s a good and reasonable feature, especially if for some reason you are afraid of state or security agencies in a place where you live, or maybe during travel. It’s still questionable, because in some states you can indeed go to jail if you don’t unlock. Yet, I really want to be able to turn it off for use-cases like mine.
>It’s still questionable, because in some states you can indeed go to jail if you don’t unlock. Yet, I really want to be able to turn it off for use-cases like mine.
Even if the end result is the same, anything that forces authorities to use official power over informal power is a net win.
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.
Problem is not user activity - it just needs PIN, TouchID or FaceID. Even if you logged to device via iPhone Mirroring it's still gonna reboot, get locked after 72 hours and for me personally it breaks iPhone Mirroring half of the time too.
One physical option to bypass it on iPhone SE is to actually physically activate PIN entry and then use Voice Control command to enter the pin since it works even before first unlock. Though this is basically compromises pin and device encryption. But it's cheap since there are plenty of $2 devices that can simulate touchscreen clicks.
I just want some easier option that works and not require agent 007 setup to just run a buld of my AI-generated crap via Xcode.
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.
Let's say I'm not super heavy Apple service user. For me Advanced Data Protection is defence against Apple itself and ability to keep little information I share via iCloud somewhat secret: mostly another backup of some photos and few other things.
It's not like I'm trying to defend against some state actors or whatver.
If I remember correctly, Apple actually picked up the feature after seeing it implemented in GrapheneOS. I think some people associated with Graphene were calling on Apple to add it for security reasons.
Stories about airport security and officers demanding access your phone is one of the reasons I will never come to the US.
An (Italian) friend of mine was stuck in Newark for 8 hours after he refused access to his phone, dragged in some room and questioned for hours along his wife while split from him own kids, even though he later gave them the password (he initially said no because he thought it was out of the line, he had nothing to hide). He left for Italy 16 hours later despite being free to go.
Land of the free my ass. Disgusting police state pseudo democracy.
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.
> Also, this is a problem for all the people that use them as alarm clocks.
Yes. But quite honestly the right solution for that would be Apple providing an alarm clock API. The alarm clock application could call it with the next scheduled alarm’s time and the os would just wake up at that time and let the application do the sound / alarm thing.
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...
>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.
> 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
What's your point? That because it isn't useful in every country, it's not worth making available to any countries?
It's not preventing you from providing your password.
You started by saying it's a good option to have, so I don't understand the point of your second paragraph.
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.
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.
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).
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.
As the article alludes to, Apple recently shipped the same policy to iOS so this is likely just following the precedent from them. Android developers don't pay attention to community forks.
I'm pretty sure you're joking. Windows 95 crashed if you sneezed in its general direction, I'm pretty sure it would blue screen due to some edge case well before 49 days of runtime.
Graphene's autoreboot has 12 different options (excluding disabling it) ranging from 72 hours down to 10 minutes and the timer is reset each time the device is unlocked. Tbh I think a 1 minute setting would actually be nice (for things like when you are going through customs, etc) but I get why they don't provide it.
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.
Someone may want that behavior if they were intentionally injured and kept from their phone for 3 days. The perpetrators will eventually get past the hospital security. Contents should be backed up in a safe place either way, possibly in a place that someone that cares about them may access it.
> ...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.
I found that this saves a lot of battery. My old Motorola G5G is now sitting idle, and I had to charge it every 4-5 days. I found that if the phone is restarted and NOT unlocked, it will stay charged for more than 10 days. My best guess is that a screen unlock is required to start many of the OS-level services, which takes up all the battery.
If this is true, then the new update will save a lot of battery for those phones that are sitting idle.
Or if you're primarily reachable by an app that can't launch until AFU, the phone reboots silently and you don't realize it, and you're incommunicado.
Some time later, you need to do something on the phone, you unlock it, the app starts up, and a flood of messages pours in. Wow, some of those would've been really useful to receive in a timely fashion! Whoops!
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.
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).
« 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?
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.
> 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.
No notifications? Depends on what your definition of "asking it" is, but having to explicitly do an action to check for notifications and even phone calls seems counter-productive for a phone.
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... I'm not going to stop you.
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... unless it's always been your dream to be a Russian serf, or an Egyptian slave?
> 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?
Lmao I regularly go several days without calling family and months between any of those others.
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.
It’s not about data being wiped. It’s that neither Android nor iOS has
fully encrypted storage after you reboot and enter your credentials - biometric or passcodes.
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 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.
Except that on most phone you can already reboot the device if you long-press some button, can't you?
You can always turn it off and on, AFAIK.
Long Press power while pressing volume down works on all Android devices I've used to date.
And that's ignoring the fact that disconnecting power, waiting a few days and then reconnecting it will inevitably let you cold boot it, too (which this would be an equivalent to - as far as I understood it)
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 default on iOS and on many Android versions.
It's often configurable, but e.g. carrier policy or local vendors can enforce it.
To have updates automatically install overnight is the maximally desirable scenario - waiting for user approval usually result in open vulnerabilities, and if you interact with a prompt you are by definition using your device and it is therefore a much worse time than while you're asleep.
I hate overnight updates because a dialed one means I have no alarm and will be hours late for work.
And yes, this has actually happened to me at least twice.
I haven't had that happen on iOS, but I have woken up in the night needing my flashlight just to find my phone applying a lengthy update. I have it set to download automatically and install manually now, I believe.
I haven't had any problems in at least 7+ years, but I work in coffee and I can remember at least two instances where an Apple update made half the staff late by turning off their alarms, myself included.
What Android version do you use where it doesn't happen`?
Never happened on my samsung.
It's already trivial to reboot a locked android phone
This is the real reason
I actually think this is the reason. But I think Android has an option to disable auto update?
> 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.
This sounds a lot like the Regulation of Investigatory Powers Act 2000 in the United Kingdom, where several people have been prosecuted and imprisoned for failing to provide encryption keys.
It's good to be able to disable this option: I use old Android phones as servers and don't want them to reboot every 3 days.
Completely agree, I don't want this to disrupt the Bop Spotter
https://walzr.com/bop-spotter
Thanks for this.
https://xkcd.com/1172/
Don't think old Androids will get this update.
Why so dismissive of how somebody wants to re-use an old phone that you would compare them to the absurd fictitious behavior in that comic? Would you rather they become e-waste? If it fits their needs then it fits their needs regardless of the use-case that was marketed.
Eventually, the android phones of today will be old android phones.
It's a Google Play Services update, likely explicitly to be able to push it to all (Google-using) Android phones immediately, without waiting for OS updates. This will not be a "Guess I'll get it in a few years" update.
I generally like XKCD but dislike the message in this comic. If that's that guy's workflow, they don't have to actively support it, but he should be given the option to disable updates so he can continue to use his tools in the way he sees fit.
I can only second this. I have an old iPhone with a second sim-card, because I need it from time to time. And Apple introduced this auto-reboot a bit earlier, iirc last year. The problem is that after rebooting it also disconnects from wifi, so e.g. SMS/handoff synchronization stops working until you enter a passcode. This is very annoying because it was very convenient for me to receive calls/SMS to my main iPhone.
It’s a good and reasonable feature, especially if for some reason you are afraid of state or security agencies in a place where you live, or maybe during travel. It’s still questionable, because in some states you can indeed go to jail if you don’t unlock. Yet, I really want to be able to turn it off for use-cases like mine.
>It’s still questionable, because in some states you can indeed go to jail if you don’t unlock. Yet, I really want to be able to turn it off for use-cases like mine.
Even if the end result is the same, anything that forces authorities to use official power over informal power is a net win.
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.
Has anyone found a way to bypass it?
Do you think it's possible to jiggle it ala mouse jigglers and USB jigglers?
Problem is not user activity - it just needs PIN, TouchID or FaceID. Even if you logged to device via iPhone Mirroring it's still gonna reboot, get locked after 72 hours and for me personally it breaks iPhone Mirroring half of the time too.
One physical option to bypass it on iPhone SE is to actually physically activate PIN entry and then use Voice Control command to enter the pin since it works even before first unlock. Though this is basically compromises pin and device encryption. But it's cheap since there are plenty of $2 devices that can simulate touchscreen clicks.
I just want some easier option that works and not require agent 007 setup to just run a buld of my AI-generated crap via Xcode.
Issue is, you kinda have a agent 007, sort of setup with the advanced data protection thing. I think you need an appropriate solution.
But all I want is "Please dont reboot my phone! Very please!" setting in options.
> I have to use TouchID again.
Don’t set it up with a passcode in the first place?
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.
Let's say I'm not super heavy Apple service user. For me Advanced Data Protection is defence against Apple itself and ability to keep little information I share via iCloud somewhat secret: mostly another backup of some photos and few other things.
It's not like I'm trying to defend against some state actors or whatver.
But this still weaken your defense against apple or whomever you are trying to defend against.
Why not have the option, though?
Considering this is all about Android adopting a very similar feature, it doesn’t sound like “Apple being Apple”…
It's Apple being a trailblazer and leading the industry. Sometimes that lead is in a bad direction.
If I remember correctly, Apple actually picked up the feature after seeing it implemented in GrapheneOS. I think some people associated with Graphene were calling on Apple to add it for security reasons.
The rest of the industry are adults and can be responsible for their own decisions though.
Doesn't seem like it. I remember when Samsung ads mocked Apple for the camera notch and removing the headphone jack.
For obvious reasons those ads are long gone...
I'm 99% sure that Android version will be toggagle via Developer Options.
Stories about airport security and officers demanding access your phone is one of the reasons I will never come to the US.
An (Italian) friend of mine was stuck in Newark for 8 hours after he refused access to his phone, dragged in some room and questioned for hours along his wife while split from him own kids, even though he later gave them the password (he initially said no because he thought it was out of the line, he had nothing to hide). He left for Italy 16 hours later despite being free to go.
Land of the free my ass. Disgusting police state pseudo democracy.
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.
The phone doesn't accept biometrics but is still in AFU state. Encryption keys are in memory.
> Also, this is a problem for all the people that use them as alarm clocks.
Yes. But quite honestly the right solution for that would be Apple providing an alarm clock API. The alarm clock application could call it with the next scheduled alarm’s time and the os would just wake up at that time and let the application do the sound / alarm thing.
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.
GrapheneOS offers hardening before first unlock, and an optional distress code that wipes the storage rather than unlocking.
Currently only available for Pixel phones, 6 and later. Offers many other security-related features.
You might get even more charges for doing that, though. Destroying evidence, obstruction or some made up charge.
Sure, I'm just saying there's a way to put unlocking the phone in the hands of someone who at least is not under the control of a hostile authority.
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.
It would be a kind of duress password.
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...
you'll get rubber hosed just in case.
>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.
> 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
What's your point? That because it isn't useful in every country, it's not worth making available to any countries?
It's not preventing you from providing your password.
You started by saying it's a good option to have, so I don't understand the point of your second paragraph.
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.
This is a Google Play Services update. For GrapheneOS users without GApps wondering: A similar feature is already built-in: https://grapheneos.org/features#auto-reboot
Heh, my first thought was “Don't they do this already?”, but apparently GrapheneOS was ahead of the curve there. Nice.
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.
> This is a Google Play Services update
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).
Samsung has also had this feature for ages.
It's not great news for my old phone used for wifi at our guesthouse (let's a few security cams and our smart lock get online)
Same here, using several old androids as hotspots here and there. They stopped receiving updates long ago though, so I'm not worried.
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.
They've been moving more and more into Google Play Services because:
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
You should be able to switch this off, if you notice it being enabled, so (now you know about it) it should be a one-time downtime.
I skimmed through the docs, couldn't see anything about soaking disabling it.
It's right there in the Google System Release Notes. Quoting https://support.google.com/product-documentation/answer/1434... :
---
### 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.
Wow I'm blind. Thanks and apologies.
I used to do something similar for the security cams at my desert property.
Picked up a gl.inet x300b off ebay and never looked back.
They stole the idea from GrapheneOS and shipped a barely half-baked version with hardcoded time. GrapheneOS has configurable time for it since years
I would guess the more likely inspiration would be Apple recently adding this to iOS, if GrapheneOS had it for years and they didn’t add it...
As the article alludes to, Apple recently shipped the same policy to iOS so this is likely just following the precedent from them. Android developers don't pay attention to community forks.
I'd claim that Microsoft pioneered this time limit security concept with Windows 95 almost 30 years ago.
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.
I'm pretty sure you're joking. Windows 95 crashed if you sneezed in its general direction, I'm pretty sure it would blue screen due to some edge case well before 49 days of runtime.
No joke.
https://web.archive.org/web/20041207171440/http://support.mi...
https://web.archive.org/web/20130731171959/https://sites.goo...
Can you set the time to one minute?
Graphene's autoreboot has 12 different options (excluding disabling it) ranging from 72 hours down to 10 minutes and the timer is reset each time the device is unlocked. Tbh I think a 1 minute setting would actually be nice (for things like when you are going through customs, etc) but I get why they don't provide it.
Not against it, but I'm genuinely curious what the use case would be for that?
I guess as a prank, just like setting the language to Chinese for English speakers.
Could be useful in a scenario where you won't be using your phone often and really want to maximize battery life.
No, that is unrealistic. Please stop trolling
How so?
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.
Why would you want it to auto-reboot after one minute?
The minimum on GrapheneOS is 10 min and the maximum is 72 hours. It can also be disabled.
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.
A wipe seems extreme. An unexpected trip to the hospital could leave someone with a wiped phone when they come to.
Someone may want that behavior if they were intentionally injured and kept from their phone for 3 days. The perpetrators will eventually get past the hospital security. Contents should be backed up in a safe place either way, possibly in a place that someone that cares about them may access it.
If that’s something you are worried about, don’t choose that option.
Is there a person on this planet where an unexpected hospital visit could not happen?
Wrong question. It's not about the chance of having a wipe. But if the having the wipe is worth happening on some false positives.
The WIPE is doable with a custom "management app", which has the permission to wipe the phone. Maybe such a thing already exists.
> ...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.
Probably overall a good thing though.
I don't think those would be likely to have Play Services, though.
I found that this saves a lot of battery. My old Motorola G5G is now sitting idle, and I had to charge it every 4-5 days. I found that if the phone is restarted and NOT unlocked, it will stay charged for more than 10 days. My best guess is that a screen unlock is required to start many of the OS-level services, which takes up all the battery.
If this is true, then the new update will save a lot of battery for those phones that are sitting idle.
Everything except a very minimal core is kept on an encrypted partition. Until the password is provided, most things can't launch.
A phone sitting idle is very unusual though, a very edge case
I don't touch my phone for days at a time. It's just sitting there on my desk most days.
Not sure I'm too happy about this...
How is this going to work with SIM cards that need a PIN? I'll be just unreachable until I notice the reboot?
Or if you're primarily reachable by an app that can't launch until AFU, the phone reboots silently and you don't realize it, and you're incommunicado.
Some time later, you need to do something on the phone, you unlock it, the app starts up, and a flood of messages pours in. Wow, some of those would've been really useful to receive in a timely fashion! Whoops!
Locking the SIM is considered part of the feature on GrapheneOS AIUI
How about instead of patching up our societies with technology we vote for the right people / laws for once?
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.
Does passing laws against a crime/overreach completely stop it happening?
This feudal system is too oppressive! Let’s put a good king on the throne!
How about both?
The "right people" aren't represented by either side of America's bipartisan system. Good luck with your mass popular movement.
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).
This should be standard
« 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?
They keep them plugged in
Can't it run two OSes, so the booting becomes instantaneous? (Like swapping graphics buffers, but now with the entire OS)
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.
Does it take into consideration thermal and power? Doing too much too quickly can be bad for both, so sometimes it's worthwhile to go slower.
The Ars article seems to be inaccurate. Here is what the release notes say:
> 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.
I misread this as reformat and was concerned for a sec. This is a good idea.
> 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.
All the more reasons to move to AOSP forks.
Google locking features behind the closed source, proprietary Play Services is "more reason to move to AOSP"?
You don't need Play Services for this feature to work. The design is not proprietary or even hard to reverse-engineer.
The reason it is implemented in play services is likely because of how much easier it is for them to ship the feature to the most phones possible.
Thanks, No. I'd like to opt out of this.
I just want software that will do nothing user-observable without me explicitly asking it to. No pop-ups, no suggestions, no automatic anything.
I don't know if it'll take a fancy buzzword or what. Unobtrusive software? Silent Software?
No notifications? Depends on what your definition of "asking it" is, but having to explicitly do an action to check for notifications and even phone calls seems counter-productive for a phone.
Inert software. Inertware?
Good software
This is a terrible idea for an internet connected device.
Not shit software
Pff. Windows does this since decades. No? I vaguely remember this nag screens after unauthorized updates.
Wait, why is this presented as a good thing?
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’s pretty well spelled out in the article…
The BFU state is more secure than AFU.
Just be glad it’s not windows, which does it every 3 hours.
Topical joke 25 years ago
For when it's sitting in an evidence baggy in the police station connected to a charger waiting for forensics
If that is a good thing what does that imply about my activities (or what an utter failure your justice system is)?
>or what an utter failure your justice system is
Even if you somehow live in a jurisdiction with a perfect justice system, that doesn't mean everyone else is.
No implication, it's a standard feature.
Whos justice system? Lots of countries represented on HN. Many with questionable systems.
The goal of a security system is to keep adversaries out
It's very clearly explained in the article.
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.
> Law enforcement keeping hold of my phone for 3 days is simply not a realistic problem for me.
That's what cops and spooks would like to have you think.
> Law enforcement keeping hold of my phone for 3 days is simply not a realistic problem for me.
It's not a problem, until it suddenly is.
This is not not the question you originally asked. Indeed it's a much better question.
> 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?
"How do you do anything during that weekend, …?"
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... I'm not going to stop you.
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... unless it's always been your dream to be a Russian serf, or an Egyptian slave?
> 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?
Lmao I regularly go several days without calling family and months between any of those others.
Isn't this stupid?
Why not flush something properly in the RAM instead to wipe the "cached" secrets?
A full restart feels like an overkill.
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.
It’s not about data being wiped. It’s that neither Android nor iOS has fully encrypted storage after you reboot and enter your credentials - biometric or passcodes.
The system is provably fully encrypted after a restart.
Not really.
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 just the RAM. Android devices and iOS devices are not that secure after first unlock (AFU).
https://blogs.dsu.edu/digforce/2023/08/23/bfu-and-afu-lock-s...