[HN Gopher] Android phones will soon reboot themselves after sit...
___________________________________________________________________
Android phones will soon reboot themselves after sitting unused for
three days
Author : namanyayg
Score : 243 points
Date : 2025-04-19 12:14 UTC (10 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| jfkimmes wrote:
| 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
| Freak_NL wrote:
| Heh, my first thought was "Don't they do this already?", but
| apparently GrapheneOS was ahead of the curve there. Nice.
| sva_ wrote:
| Samsung has also had this feature for ages.
| amelius wrote:
| 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?)
| edent wrote:
| 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.
| daneel_w wrote:
| 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.
| ignoramous wrote:
| > _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).
| gumbojuice wrote:
| 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)
| wizzwizz4 wrote:
| 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.
| devrandoom wrote:
| I skimmed through the docs, couldn't see anything about
| soaking disabling it.
| wizzwizz4 wrote:
| 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.
| devrandoom wrote:
| Wow I'm blind. Thanks and apologies.
| rixed wrote:
| Same here, using several old androids as hotspots here and
| there. They stopped receiving updates long ago though, so I'm
| not worried.
| clort wrote:
| 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.
| aftbit wrote:
| 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
| pengaru wrote:
| 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.
| 1832 wrote:
| Also bad news for my megayacht (use's an old android phone to
| monitor location and detect movement)
| imcritic wrote:
| 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.
| davikr wrote:
| The system is provably fully encrypted after a restart.
| scarface_74 wrote:
| 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...
| MattPalmer1086 wrote:
| 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.
| crote wrote:
| 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.
| scarface_74 wrote:
| 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.
| udev4096 wrote:
| They stole the idea from GrapheneOS and shipped a barely half-
| baked version with hardcoded time. GrapheneOS has configurable
| time for it since years
| mcraiha wrote:
| Can you set the time to one minute?
| ThePowerOfFuet wrote:
| 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.
| devrandoom wrote:
| Not against it, but I'm genuinely curious what the use case
| would be for that?
| amelius wrote:
| I guess as a prank, just like setting the language to
| Chinese for English speakers.
| 67593874748 wrote:
| Could be useful in a scenario where you won't be using your
| phone often and really want to maximize battery life.
| udev4096 wrote:
| No, that is unrealistic. Please stop trolling
| II2II wrote:
| 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.
| OneDeuxTriSeiGo wrote:
| 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.
| iancarroll wrote:
| 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...
| lysace wrote:
| 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.
| philistine wrote:
| 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.
| lysace wrote:
| No joke.
|
| https://web.archive.org/web/20041207171440/http://support.m
| i...
|
| https://web.archive.org/web/20130731171959/https://sites.go
| o...
| yalok wrote:
| I'm not sure it was because they cared about security - looks
| more like accounting for 32-bit timestamp rollover would be
| very disruptive to the huge (legacy) code base and it was a
| quick fix to work around the problem :)
| Dwedit wrote:
| To this day, some programs malfunction after 2^31
| milliseconds have passed since bootup, which is the halfway
| point. Milliseconds since bootup has just become negative,
| and has not rolled over yet. Just having a negative number of
| milliseconds is enough to mess with those programs.
| surajrmal wrote:
| 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.
| Beijinger wrote:
| Pff. Windows does this since decades. No? I vaguely remember this
| nag screens after unauthorized updates.
| booleandilemma wrote:
| 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?
| kranke155 wrote:
| Not shit software
| layer8 wrote:
| Inert software. Inertware?
| mystified5016 wrote:
| Good software
| bobsmooth wrote:
| This is a terrible idea for an internet connected device.
| TheBicPen wrote:
| 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.
| MiddleEndian wrote:
| I've mused about writing a distribution license where every
| type of notification and update can be disabled, and any
| modification must follow the same license.
|
| 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
| LinuxBender wrote:
| 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.
| dist-epoch wrote:
| The WIPE is doable with a custom "management app", which has
| the permission to wipe the phone. Maybe such a thing already
| exists.
| al_borland wrote:
| A wipe seems extreme. An unexpected trip to the hospital could
| leave someone with a wiped phone when they come to.
| criddell wrote:
| If that's something you are worried about, don't choose that
| option.
| Krasnol wrote:
| Is there a person on this planet where an unexpected
| hospital visit could not happen?
| xboxnolifes wrote:
| 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.
| LinuxBender wrote:
| 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.
| Aeolun wrote:
| 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.
| WD-42 wrote:
| Just be glad it's not windows, which does it every 3 hours.
| recursive wrote:
| Topical joke 25 years ago
| scarface_74 wrote:
| Says someone who has never had to deal with corporate
| installed malware - ie MDM software.
| jillyboel wrote:
| For when it's sitting in an evidence baggy in the police
| station connected to a charger waiting for forensics
| Aeolun wrote:
| If that is a good thing what does that imply about my
| activities (or what an utter failure your justice system is)?
| edoceo wrote:
| No implication, it's a standard feature.
|
| Whos justice system? Lots of countries represented on HN.
| Many with questionable systems.
| gruez wrote:
| >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.
| jillyboel wrote:
| The goal of a security system is to keep adversaries out
| saagarjha wrote:
| I guarantee you that regardless of where you live your
| justice system is abusing the same access.
| alistairSH wrote:
| It's pretty well spelled out in the article...
|
| The BFU state is more secure than AFU.
| crazygringo wrote:
| It's very clearly explained in the article.
| Aeolun wrote:
| 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.
| wiseowise wrote:
| > 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.
| andybak wrote:
| This is not not the question you originally asked. Indeed
| it's a much better question.
| 67593874748 wrote:
| > 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.
| crazygringo wrote:
| > _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?
| hilbert42 wrote:
| _" 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).
| crazygringo wrote:
| 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?
| lupusreal wrote:
| > 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.
| 627467 wrote:
| 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
| jonathanstrange wrote:
| Thanks, No. I'd like to opt out of this.
| greatgib wrote:
| 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.
| SXX wrote:
| 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?
| layer8 wrote:
| > I have to use TouchID again.
|
| Don't set it up with a passcode in the first place?
| SXX wrote:
| 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.
| elashri wrote:
| 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.
| SXX wrote:
| 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.
| elashri wrote:
| But this still weaken your defense against apple or
| whomever you are trying to defend against.
| layer8 wrote:
| Why not have the option, though?
| elashri wrote:
| I don't understand option to do what, you can disable
| advanced data protection for sure. What do you suggest
| here ?
| crazysim wrote:
| Do you think it's possible to jiggle it ala mouse jigglers
| and USB jigglers?
| SXX wrote:
| 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.
| crazysim wrote:
| Issue is, you kinda have a agent 007, sort of setup with
| the advanced data protection thing. I think you need an
| appropriate solution.
| SXX wrote:
| But all I want is "Please dont reboot my phone! Very
| please!" setting in options.
| out-of-ideas wrote:
| might have to resort to the homer j drinking bird to tap
| the screen (for reference
| https://youtu.be/R_rF4kcqLkI?t=174 )
| SXX wrote:
| No joke btw I already testing setup with auto clicker
| from AliExpress and Assistive Touch automation...
| nativeit wrote:
| Considering this is all about Android adopting a very similar
| feature, it doesn't sound like "Apple being Apple"...
| Mountain_Skies wrote:
| It's Apple being a trailblazer and leading the industry.
| Sometimes that lead is in a bad direction.
| dagmx wrote:
| The rest of the industry are adults and can be
| responsible for their own decisions though.
| SXX wrote:
| I'm 99% sure that Android version will be toggagle via
| Developer Options.
| anonymars wrote:
| 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...
| OneDeuxTriSeiGo wrote:
| 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.
| saagarjha wrote:
| Keep an app running?
| SXX wrote:
| Might be I did something wrong, but even with YouTube video
| running via iPhone Mirroring device still went to reboot.
| saagarjha wrote:
| Hmm, yeah that seems wrong. I don't get reboots on
| devices I use frequently; I think it is only supposed to
| kick in when the device is not in use for a long time (it
| is meant to stop police who have a locked device they
| will try to brute force into).
| SXX wrote:
| Are you on latest iOS? Are you stilllocking / unlocking
| the phone once in 3 days at least?
|
| 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.
| cameroncairns wrote:
| My physical ios device test harness has no pin
| numbers/touch id activated for any of the connected
| phones. I noticed early on in testing that it would
| require physical access to reinput the pin code even when
| the device was already unlocked when I would restart an
| XCUI test.
|
| 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.
| gcanyon wrote:
| 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.
| dsr_ wrote:
| 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.
| hypeatei wrote:
| You might get even more charges for doing that, though.
| Destroying evidence, obstruction or some made up charge.
| gcanyon wrote:
| 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.
| NekkoDroid wrote:
| 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.
| exe34 wrote:
| you'll get rubber hosed just in case.
| greatgib wrote:
| 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...
| LWIRVoltage wrote:
| A Veracrypt style hidden OS profile that is forensically
| invisible would be a better option - This would allow one to
| enter a password and give another "profile" or OS- that
| unlike current alternate profile stuff- would be solid
| against Cellebrite and GreyKey snooping into the device, and
| it'd be impossible to tell there was a hidden user/etc on it
| rvnx wrote:
| 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.
| mystified5016 wrote:
| This is the real reason
| markus_zhang wrote:
| I actually think this is the reason. But I think Android has
| an option to disable auto update?
| rixed wrote:
| Except that on most phone you can already reboot the device
| if you long-press some button, can't you?
| BurningFrog wrote:
| You can always turn it off and on, AFAIK.
| ffsm8 wrote:
| 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)
| kokada wrote:
| 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).
| kqr wrote:
| 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.
| arghwhat wrote:
| 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.
| TylerE wrote:
| 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.
| mh- wrote:
| 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.
| Talanes wrote:
| 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.
| nradov wrote:
| You don't keep a real flashlight next to your bed?
| saagarjha wrote:
| Why would you when you have a phone?
| sneak wrote:
| You don't keep a real camera next to your bed? What about
| a two-way radio? MP3 player?
| ssl-3 wrote:
| I keep all of those things next to my bed.
|
| 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.
| mvdtnz wrote:
| That's a weird thing to ask.
| Krasnol wrote:
| What Android version do you use where it doesn't happen`?
| rat9988 wrote:
| Never happened on my samsung.
| ssl-3 wrote:
| I've woken up to a rebooted Samsung phone.
|
| (And it has been problematic for me at times when this
| happened.)
| VWWHFSfQ wrote:
| It's already trivial to reboot a locked android phone
| rtpg wrote:
| At least on iOS an update requires an explicit unlock, is
| this not the case on Android?
|
| There could be secret pathways but I don't know them.
| kwanbix wrote:
| 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.
| h4x0rr wrote:
| The phone doesn't accept biometrics but is still in AFU
| state. Encryption keys are in memory.
| xrisk wrote:
| (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.
| krisoft wrote:
| > 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.
| xg15 wrote:
| 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.
| joak wrote:
| 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.
| blackoil wrote:
| https://xkcd.com/1172/
|
| Don't think old Androids will get this update.
| xethos wrote:
| 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.
| TulliusCicero wrote:
| Eventually, the android phones of today will be old android
| phones.
| Lammy wrote:
| 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.
| MiddleEndian wrote:
| 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.
| MattSayar wrote:
| Completely agree, I don't want this to disrupt the Bop
| Spotter
|
| https://walzr.com/bop-spotter
| lostlogin wrote:
| Thanks for this.
| yellowapple wrote:
| Probably a good time as any to replace it with something
| purpose-built anyway. A Raspberry Pi with a directional
| microphone and a custom app feeding said microphone data to
| a service like AudD or ACRCloud could readily do the trick
| without any of Android's extra baggage - though I do wonder
| how effective those services would be at detecting songs
| amid a bunch of background noise like Bop Spotter does via
| Shazam.
| MattSayar wrote:
| I think half the value of the phone here is the built-in
| battery
| ssl-3 wrote:
| Perhaps, but it's also inexpensive to (properly) use one
| or more 18650s with a Raspberry Pi if that's what one
| wants to do.
|
| 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.
| prmoustache wrote:
| You can power a raspberry pi with that battery though.
| glenstein wrote:
| >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.
| baby_souffle wrote:
| 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.
| intrasight wrote:
| 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.
| sneak wrote:
| Biometrics aren't testimony.
|
| You don't have to do anything for someone to hold a phone to
| your fingertip, or a camera to your face.
| crazygringo wrote:
| > _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.
| oarsinsync wrote:
| > 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.
| ololobus wrote:
| 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.
| Talanes wrote:
| >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.
| sneak wrote:
| Apple doesn't like supporting the use case of multiple phones
| for one person. They even encourage their employees to use
| their personal devices and accounts.
| epolanski wrote:
| 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 livid for Italy 16 hours later despite being free to go
| on with his vacation.
|
| Land of the free my ass.
| SoftTalker wrote:
| Ok, but try refusing the requests of border authorities in
| any country and see how far you get before you find yourself
| escorted to a back room.
| epolanski wrote:
| I've visited 45 countries in my life and I've never ever
| been even asked once to even show the contents of my bag,
| let alone access to my phone.
| scarface_74 wrote:
| There is nothing any technology company can do to protect
| against rubber hose decryption.
| amelius wrote:
| Can't it run two OSes, so the booting becomes instantaneous?
| (Like swapping graphics buffers, but now with the entire OS)
| edelbitter wrote:
| 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.
| surajrmal wrote:
| 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.
| fguerraz wrote:
| How about instead of patching up our societies with technology we
| vote for the right people / laws for once?
| recursive wrote:
| How about both?
| homebrewer wrote:
| 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.
| dagmx wrote:
| Does passing laws against a crime/overreach completely stop it
| happening?
| bigyabai wrote:
| The "right people" aren't represented by either side of
| America's bipartisan system. Good luck with your mass popular
| movement.
| teddyh wrote:
| This feudal system is too oppressive! Let's put a _good_ king
| on the throne!
| beeflet wrote:
| That plan, if implemented, may last as short as 1 election
| cycle. All political progress will inevitably be undone.
|
| 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?".
| scarface_74 wrote:
| You don't vote for the police or the three letter agencies and
| elected officials have little power over people with guns. Yes
| I know both on the the state level the police are suppose to be
| under the command of the civil government. But no elected
| official wants to get on the wrong side of the police unions.
|
| 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-...
| wiseowise wrote:
| > 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.
| 67593874748 wrote:
| Google locking features behind the closed source, proprietary
| Play Services is "more reason to move to AOSP"?
| bigyabai wrote:
| You don't need Play Services for this feature to work. The
| design is not proprietary or even hard to reverse-engineer.
| surajrmal wrote:
| 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.
| graypegg wrote:
| > ...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.
| tripdout wrote:
| I don't think those would be likely to have Play Services,
| though.
| rixed wrote:
| << 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?
| aftbit wrote:
| They keep them plugged in
| FeistySkink wrote:
| How is this going to work with SIM cards that need a PIN? I'll be
| just unreachable until I notice the reboot?
| switch007 wrote:
| Locking the SIM is considered part of the feature on GrapheneOS
| AIUI
| myself248 wrote:
| 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!
| cubefox wrote:
| 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.
| bobsmooth wrote:
| I misread this as reformat and was concerned for a sec. This is a
| good idea.
| vishnuharidas wrote:
| 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.
| emrah wrote:
| A phone sitting idle is very unusual though, a very edge case
| chowells wrote:
| Everything except a very minimal core is kept on an encrypted
| partition. Until the password is provided, most things _can 't_
| launch.
| chmod775 wrote:
| 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...
| m-p-3 wrote:
| uhh, that's going to disrupt Briar Mailbox, which relies on an
| Android device to act as an always-on node. I really hope there
| is a way to toggle this.
|
| https://briarproject.org/download-briar-mailbox/
| yellowapple wrote:
| Can I configure this? In some cases I'd want the auto-reboot to
| be more aggressive (for example: after 3 hours). In other cases
| I'd want to disable the auto-reboot entirely.
| hnburnsy wrote:
| So the phone will reboot it self, but...
|
| 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.
| panny wrote:
| Why would it reboot instead of just power off?
___________________________________________________________________
(page generated 2025-04-19 23:00 UTC)