4 ms·

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

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 https://grapheneos.org/features#auto-reboot

NotPractical 1y ago
Typical lazy Ars reporting. The feature originates from GrapheneOS, not iOS.
- kernal 1y ago
  No, the feature first appeared on Samsung phones to fix their bloat / slowdown issues. Now it’s suddenly a security feature.
morpheuskafka 1y ago
That’s weird. I wouldn’t expect Play Services to handle a system function like rebooting unrelated to any Google services.
- ffpip 1y ago
  Play services is how Google delivers many Android updates now so that all users can get security updates without waiting for the device vendor to publish it for each device.
- usr1106 1y ago
  No. Play Services is Google's way to make Android closed source. Many new features don't get implemented in Android, but Play Services. Many apps don't work (correctly) without Play Services.
  - surajrmal 1y ago
    Being closed source is not the goal. Update speed, consistency across the ecosystem, and feature development speed are key reasons things are implemented via play services. Also dependency on google services, but that's not relevant here. AOSP is greatly improving in its ability to tackle these things, so the choice to implement things in play services won't be as compelling as it is today for things not ultimately tied to Google.
Freak_NL 1y ago
Heh, my first thought was “Don't they do this already?”, but apparently GrapheneOS was ahead of the curve there. Nice.
- hackernewds 1y ago
  How would an OS taking over your hardware would be ahead of the curve or nice?
  - throwaway314155 1y ago
    Because it's an effective tactic against exploits that can't survive a reboot, which is somewhat common from my understanding. The idea being that police can confiscate your phone and just keep it on and charged until they can buy or develop an exploit targeting your current device and software. 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).
- kernal 1y ago
  > GrapheneOS was ahead of the curve there 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.
- illiac786 1y ago
  Still ahead of the curve, as it can be disabled on grapheneOS while it apparently won’t bee possible in Android ;)
deleted 1y ago
[deleted]
sva_ 1y ago
Samsung has also had this feature for ages.
- SG- 1y ago
  not for security tho, it was for bloat/fixing random issues like a typical Win95 daily reboot.
amelius 1y ago
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 1y ago
  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 1y ago
  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.
  - rahen 1y ago
    It's enabled on mine, at least. By default, it reboots after 18 hours without being unlocked.
    - daneel_w 1y ago
      Perhaps it's a recent change. My install of GrapheneOS is from August last year.
ignoramous 1y ago
> 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).

NotPractical 1y ago

Typical lazy Ars reporting. The feature originates from GrapheneOS, not iOS.

kernal 1y ago
No, the feature first appeared on Samsung phones to fix their bloat / slowdown issues. Now it’s suddenly a security feature.

morpheuskafka 1y ago

That’s weird. I wouldn’t expect Play Services to handle a system function like rebooting unrelated to any Google services.

ffpip 1y ago
Play services is how Google delivers many Android updates now so that all users can get security updates without waiting for the device vendor to publish it for each device.
usr1106 1y ago
No. Play Services is Google's way to make Android closed source. Many new features don't get implemented in Android, but Play Services. Many apps don't work (correctly) without Play Services.
- surajrmal 1y ago
  Being closed source is not the goal. Update speed, consistency across the ecosystem, and feature development speed are key reasons things are implemented via play services. Also dependency on google services, but that's not relevant here. AOSP is greatly improving in its ability to tackle these things, so the choice to implement things in play services won't be as compelling as it is today for things not ultimately tied to Google.

Freak_NL 1y ago

Heh, my first thought was “Don't they do this already?”, but apparently GrapheneOS was ahead of the curve there. Nice.

hackernewds 1y ago
How would an OS taking over your hardware would be ahead of the curve or nice?
- throwaway314155 1y ago
  Because it's an effective tactic against exploits that can't survive a reboot, which is somewhat common from my understanding. The idea being that police can confiscate your phone and just keep it on and charged until they can buy or develop an exploit targeting your current device and software. 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).
kernal 1y ago
> GrapheneOS was ahead of the curve there 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.
illiac786 1y ago
Still ahead of the curve, as it can be disabled on grapheneOS while it apparently won’t bee possible in Android ;)

deleted 1y ago

[deleted]

sva_ 1y ago

Samsung has also had this feature for ages.

SG- 1y ago
not for security tho, it was for bloat/fixing random issues like a typical Win95 daily reboot.

amelius 1y ago

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 1y ago
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 1y ago
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.
- rahen 1y ago
  It's enabled on mine, at least. By default, it reboots after 18 hours without being unlocked.
  - daneel_w 1y ago
    Perhaps it's a recent change. My install of GrapheneOS is from August last year.

ignoramous 1y ago

> 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).