Android phones will soon reboot themselves after sitting unused for three days

Origin and implementation

  • Multiple commenters note that similar “auto reboot when idle” features have existed for years:
    • GrapheneOS has a configurable auto‑reboot (10 minutes–72 hours, can be disabled).
    • Samsung offered scheduled reboots, originally framed as a workaround for slowdowns, not security.
    • iOS added a related feature recently; some think Android is following Apple, others credit GrapheneOS.
  • The Ars piece is called out as slightly misleading: Google’s own release notes say Play Services “enables a future optional security feature” rather than an immediate, mandatory change.
  • Some argue the feature should live in low‑level init/OS rather than in Google Play Services; Play Services is seen by some as an anti‑fragmentation mechanism, by others as a way to make Android more proprietary.

Security rationale and technical debate

  • Core security argument: rebooting returns the device to “before first unlock” (BFU), with full disk encryption and keys out of RAM, which:
    • Mitigates many AFU‑state exploits.
    • Frustrates law enforcement keeping seized, locked phones powered while they acquire an exploit.
  • Several comments stress that just clearing RAM or “flushing cached secrets” is complex and bug‑prone; a full reboot is simpler and more reliably wipes all secrets from memory and kills most malware.
  • Others ask why not more granular designs (better key management, suspend‑state hardening, dual‑profile/duress passwords, hidden volumes).

Configurability and Play Services concerns

  • Strong sentiment that this is acceptable only if:
    • It’s clearly optional.
    • Timeouts are configurable (shorter for high‑risk users, disabled for IoT/servers).
  • Skepticism that “optional” could later become forced, and concern that Play Services lets Google push system‑level behavior without OEM or user control.

Impact on alternate and idle uses

  • Many use old Android phones as:
    • Hotspots, guesthouse Wi‑Fi, smart‑lock bridges, CCTV gateways.
    • Always‑on Briar Mailbox nodes or pseudo‑servers.
    • Backup/emergency or travel devices that sit idle for days.
  • Auto‑reboot is seen as breaking these use cases unless a reliable off‑switch exists.

Usability drawbacks

  • Concerns about:
    • SIMs with PINs: after reboot, no network until PIN re‑entered.
    • Missed alarms, calls, and app notifications when a device silently reboots locked.
    • Hospitalizations or travel leading to unintended lockouts or even data wipes if more aggressive options existed.

Law enforcement, rights, and politics

  • Long subthread on:
    • AFU vs BFU states in forensics, and how this feature can protect against prolonged device seizure.
    • Countries where refusing to unlock can be a crime, making such protections less useful or risky.
    • Broader debates about relying on tech vs legal reform, and compulsion to reveal passwords or biometrics.