Android phones will soon reboot themselves after sitting unused for three days
arstechnica.com
arstechnica.com
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.
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?
It's not like I'm trying to defend against some state actors or whatver.
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.
For obvious reasons those ads are long gone...
Web browsers are an immediate example that comes to mind. When everyone started switching to Chrome, the other browsers fell all over themselves to strip down into minimalism, as though it was the sparse UI that was capturing users' hearts, as opposed to the rendering speed and compatibility. So then you had all these other fat, slow browsers that took away the only thing that was still distinguishing them from Chrome.
In this case though, I guess it's about money. Why put in an SD card slot when you can instead extort your customers for a cloud storage subscription or a lucrative upsale to the higher model with more storage?
Meanwhile as a customer nothing makes me more irate than "upgrading" to something that's worse because I can't replace the battery and the OS no longer gets updates.
7 days timeout on was introduced in iOS 18, but then decreased to 3 days. I dont use this device physically - it's just a phone that always connected to power and sit on top of mac mini for debugging and running some ios exclusive apps.
And I honestly dont do anything remotely interested to the police to worry about it. Yet it all just worked and now it doesnt.
If you're able to have fully unlocked devices at your test setup I'd suggest giving that a shot to see if it fixes your issue around device restart.
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...
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)
power+volume = screenshot
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.
And yes, this has actually happened to me at least twice.
They all even share a unified battery charging mechanism and integrated packaging for easy portability.
I'm not sure if the idea of these pocket supercomputers will ever catch on, but it sure seems like it'd be nice.
I've had that happen a few times and the alarms went off on time but they used the default alarm tune instead of the one I had selected, presumably that data was still encrypted.
The amount of misinformation in this thread is huge though. I generally read every changelog for major Android updates and the amount of engineering going on is amazing. People just assumes that a few things doesn't work while they do.
Unless of course OP is using a custom alarm app this may be true, but then it is the app fault and not Android.
Edit: accordingly to ChatGPT the feature is the WorkManager: https://developer.android.com/topic/libraries/architecture/w.... I can't confirm this but looks correct to me after a quick look at its documentation.
These have existed for many decades.
On Android, my experience has been that new major versions are often unstable / involve some risk of bricking / include feature regressions (dumbing down of multi-task in Android 13 if I remember well). Waiting for a few month before installing a major update, while not optimal for security, is necessary to make sure that the most critical bugs are fixed beforehand.
Regarding applications, today there's so many applications being always updated all the time that there's no way it's good for the flash memory to constantly rewrite it every day. Plus this often leads to random application restarts while they are updated automatically. (and non-OSS applications updates can result in unwanted changes such as more ads, random changes in UI...).
It's still possible to disable automated updates on Android and I am glad that they allow it.
Major version upgrades are a different type of upgrade altogether. They are optional while the previous major is still maintained.
Minor upgrades is what should always be automatic.
> Flash wear
No, it doesn't matter.
Total write endurance (i.e., the number of bytes written the device is designed to handle under some standard load) is usually a large multiple of the chip size itself - say, 200x-400x, so e.g. 100TB of writes for a 256GB setup. A particular workload is only really meaningful to flash wear if it is in the scale of several full storage rewrites during the lifetime of the device.
The exact write endurance depends on the exact configuration (specific chip selection, allocated reserve), but even microSD cards have wear levelling these days.
Your device is going to die or be retired with a certain flash write wear, but I find it extremely unlikely that your device will die of a flash write wear. The wear endurance is dependent on the specific flash setup.
A much larger cause of wear is app caches (e.g., streaming video continously overwriting a disk cache, browsing social media). If you take pictures, those might end up written multiple times as first the original is written, then the automatically processed version, then any edits you make, then if storage saving measures is enabled maybe its deleted and a compressed version is written, if you later open the app the original is downloaded and written again, ...
I don't think there is such a choice on Pixel phones but I'd be happy to be proven wrong. When the next major update is available the phone just asks to update to it every few days (but won't do it without user consent). I don't think there's security updates on a given phone for old major versions when a new one is available (there likely are for older phones that don't get the major update however).
Thank you for your explanations on flash wear, makes sense. Taking a low value of 13TB endurance (64GB times 200), this is still 7GB per day for five years and I don't think app updates can consume that much.
(And it has been problematic for me at times when this happened.)
There could be secret pathways but I don’t know them.
If you enter password 1 it goes into your normal account, if you enter password 2 it goes into another user account with a burner environment where you can install a few token commonly used apps for plausible deniability.
The existence of password 2 should be optional and you should not be able to tell if the system has one or two passwords configured.
It's gonna be seen as pretty implausible when you don't have constant & recent messages with your loved ones in there.
When Google does it: "Google is using it to help the FBI"
(But the iphone was hacked by the FBI...)
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.
Don't think old Androids will get this update.
I think the main advantage to using phones for random stuff is availability: We here on HN probably have a decent selection of old phones to pick from, so it doesn't cost any money at all to give a new purpose to one.
Same for 5G modems. A $50 phone will give you gigabit 5G, but you'll pay $500 to get that in non-phone form factor, mostly because on patents on the 5G tech which are charged differently for phones vs dedicated modems.
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.
You don’t have to do anything for someone to hold a phone to your fingertip, or a camera to your face.
An argument against being compelled to provide biometrics does not necessarily hinge on it being analogous to testimony.
There is a specific precedent where you being compelled into providing biometrics can be inadmissible, and that is where you are compelled to unlock the phone, since doing so, even with biometrics is akin to providing testimony that the phone is yours, you know how to unlock it, which finger to use, etc. (see United States v. Brown, No. 17-30191 [1]). But that doesn’t actually prevent them using your biometrics to unlock the phone, so its pretty niche.
[1] https://law.justia.com/cases/federal/appellate-courts/ca9/17...
But you're replying as if my comment was claiming courts haven’t treated biometrics like physical evidence. That's not what I was doing.
The reference to Brown here appears to be massively misleading: far from being niche, it complicates the biology != testimony in a way that cuts to the heart of the most common real-world application of biometric compulsion which is smartphone access; from chatgpt'ing about it it appears that it's not the only court to rule on this and it probably awaits a SCOTUS decision to resolve an existing split.
The Supreme Court has declined multiple times to hear cases that would help settle the legal ambiguity. I don’t think United States v. Brown complicates things because the specifics on the case were not whether or not you can be compelled to provide biometrics, but whether being compelled to “unlock a device” and manipulating the device yourself constitutes protected testimony. [0] They even cited United States v. Payne [1] where the court upheld that forcibly taking your finger to unlock a phone did not violate the defendant’s Fifth Amendment rights, and at issue was only the wording of the order.
From my understanding, the current split about being compelled to provide passcodes, and to a much lesser extent biometrics, is the foregone conclusion exception stemming from the Fisher v. United States [2] case, where, as Justice White said “the existence and locations of the papers[were] a foregone conclusion and the [defendant’s physical act] adds little or nothing to the sum total of the Government’s information by conceding that he in fact has the papers… [And so] no constitutional rights [were] touched. The question [was] not of testimony but of surrender.”
This has been used in relation to court cases on biometrics and passcodes [3]. It appears that courts that rule that you can be compelled seem to look narrowly at the passcode itself i.e. the government knows you own the phone and knows you know how to unlock it, so it is a foregone conclusion to provide it. Courts that rule you cannot be compelled seem to look at the phones contents i.e. the government does not know what is on the phone so decrypting the data would be providing protected testimony, or a stricter interpretation that you cannot be compelled to disclose the contents of the mind.
[0] Somehow I linked to the wrong case originally https://law.justia.com/cases/federal/appellate-courts/cadc/2...
[1] https://cdn.ca9.uscourts.gov/datastore/opinions/2024/04/17/2...
[2] https://supreme.justia.com/cases/federal/us/425/391/
[3] https://www.barclaydamon.com/webfiles/Publications/Unlock-De...
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.
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.
This scares me, because I have plenty of old devices I no longer know the passwords for. I don't think I'm alone - plenty of people forget passwords they don't use in years.
If the police came and searched my house, they could probably find some ancient laptop or phone from a decade ago, demand I unlock it, and then put me in prison forever when I cannot do do so.
Also (this may be of limited consolation) the officer who compels you to disclose the key must have some idea of what data it is protecting in order to satisfy RIPA 2000 s 51(5)(a):
> The matters to be taken into account in considering whether the requirement [for proportionality] of subsection (4)(b) is satisfied in the case of any direction shall include... the extent and nature of any protected information, in addition to the protected information in respect of which the disclosure requirement is imposed, to which the key is also a key
Possibly could have gone differently if they had said they changed their 15 letter password every two weeks, but really?
If there's an excuse for something that is difficult to disprove because it's based on the word of the person it would undermine the justice system.
Imagine if ignorance of the law was an excuse.
CPS won’t (as a matter of policy, and also can’t afford to waste time and money) spend time trying to prosecute a forgotten password for old laptop, unless it’s connected to some other serious, evidenced, allegations.
(I was on a jury in just this situation. Reasonable doubt is a high bar and prosecutors know this).
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.
Even if the end result is the same, anything that forces authorities to use official power over informal power is a net win.
I have to have 3 devices: mine, work and a shared one for travel that crosses customs boundaries. It’s a massive pain in the ass.
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 livid for Italy 16 hours later despite being free to go on with his vacation.
Land of the free my ass.
It's extremely dangerous to condone and think that police officers are entitled to write the rules.
That said, the last time I went to Italy the customs guy looked annoyed at being awake. He asked my son’s age (he is huge but too young to use the electronic gate), then shrugged and stamped my passport with all of his strength.
Even on Schengen borders they can ask you for your phone and deny your entry if you don't comply as a non-citizen.
Most countries recognize very different limits at a customs boundary. Is this appropriate in an age where a tiny device gives you access to all of your "papers" in many cases? I don't think so, but international law doesn't recognize our concerns with respect to that.
In the US I've heard that boundary (the "border") encompasses ~75% of everyone living inside. It's like "within X miles of a border" and includes rivers and airports as well as the entire coastline.
I'm not up to date on these rules and who's been caught out by them, but I have repeatedly heard the claim above.
Sure! Otherwise we won't be able to smoothly run our own servers on our phones: https://news.ycombinator.com/item?id=31841051
I think you're basically calling out all the democracies, then.
If we start being perfectionist, we pretend there's no difference between most nations in the rights their citizens have. And that's not even remotely true.
In December 2024 all UN member countries voted in favor of "UN Cybercrime Treaty" which binds signatories to adopt a legislation to force you to give cops your passwords and other credentials.
https://documents.un.org/doc/undoc/gen/n24/426/74/pdf/n24426...
I was admittedly confused about this distinction at one point too. It's a trade-off (although few people effected by this own phones with truly free, user-respecting soft/hardware in the first place).
Not really. Samsung was the first with this, but their reasoning had absolutely nothing to do with security. It was because their phones slowed down over time and their solution was to give users the option to reboot it at specific intervals. You could even make the argument that the Samsung solution is still the superior solution because you get to set the interval.
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).
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.
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.
---
### 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.
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
I have that on a spare unrooted Android phone. Seems to be working so far. But I'm sure Google could bypass it if they really wanted to. I don't know if they've ever made an effort to bypass Netguard (or similar) in the past.
Picked up a gl.inet x300b off ebay and never looked back.
- [ ] 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.
Some people lose or get their phone broken and start from a blank one on a regular basis.
In my case the only things that matter to me are synchronised through syncthing and radicale (a carddav/caldav server).
I think it should be doable _technically_, but I think getting the mobile radios working before the OS boots would be challenging.
Like I could just grab your thumb drive, and put a new system on there that looks the same, and steals your password.
That said, I think this is a fairly good idea, although with the encryption stuff they do, this will cause people who rarely use their phones to miss calls and alarms.
If this is true, then the new update will save a lot of battery for those phones that are sitting idle.
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.
> 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.
1) There is no developer accessible API to allow app developers to create an app to allow me to script power options (example, as an end user I want to script a restart or shut down my phone nightly).
2) Asking Google Assistant will not restart or shut down the phone.
3) Apple and Android have made it harder to shut down the phone, requiring double key press kung fu to even bring up the power menu.
One click for me and it restarts fyi
It appears as an “app” like any other
Open it, will ask you to confirm, hit yes and it will restart
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!
In contrast, technological change will forever alter the balance of power. What we should be asking is "Instead of patching society with political solutions, how about we solve fundamental problems permanently with technology?".
Besides most people support the police no matter what. Police know not to abuse their powers against Whites.
https://www.blackenterprise.com/white-protesters-form-human-...
I don't know if it'll take a fancy buzzword or what. Unobtrusive software? Silent Software?
STFU (BSD equivalent) and STFU-O (GPL equivalent)
No LGPL equivalent because I would want even software that uses STFU-* licensed code as a library to follow the STFU-* license.
Just have to explicitly define what counts as a notification lol
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
Only law enforcement cares about the difference between the AFU state and BFU state.
firstly how about fixing software which forces 'inactive hours' yet reboots even when cpu is at 100% utilisation, and software which dims or locks a mobile screen during video playback, and soft/hardware which doesn't respect user-supplied suspend/standby timeouts in their power plans, and ....
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.
Not sure I'm too happy about this...
If you are in a hospital- your phone will reboot to pin level. So you need to unlcok it few times and wait 3 minutes before it becomes reactive.
Then all your alarms will not work.
They add crap like this, yet the stock calendar app needs a separate appto play music to warn you. This of course breaksafter a reboot..
My grandma has a second phone as backup - it will constantly reboot and will never be ready to be used the time it is needed - as a backup. Since it will keep rebooting and requiring a pin.
Who comes up with those anti user ideas?
That we will probably be unable to turn off (or the option to turn off will disappear after few months). Also old people will not know how to turn it off
Sometimes it feels like tech is going backwards. Rather than rebooting, just develop a proper method to unload/uncache, without making a device useless while that happens. Or use that multicore arch to swap the “dirty” instance with a clean one, in realtime.
It works there better anyway, because it's integrated with the OS, and not just one privileged service.
Not falling for it anymore. Fuck Google and the rest of Big Tech.
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.
Whos justice system? Lots of countries represented on HN. Many with questionable systems.
Even if you somehow live in a jurisdiction with a perfect justice system, that doesn't mean everyone else is.
The BFU state is more secure than AFU.
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... unless it's always been your dream to be a Russian serf, or an Egyptian slave?
I'll just add this, I was amongst the first to ever own a cellular mobile phone. I owned several Motorola 'bricks' (DynaTAC) if you're old enough to know what that is, and before that I owned a mobile car phone in pre-cellular times, the nature of that tech was such that very few phone numbers were available—simply it was damed expensive and one had to be very keen to own one.
What I'm taking about is a lot more complex than your understanding (or that which you wish to admit to).
Lmao I regularly go several days without calling family and months between any of those others.
Why not flush something properly in the RAM instead to wipe the "cached" secrets?
A full restart feels like an overkill.
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.
A full restart guarantees that everything will be wiped.