Google has quietly rolled out a new Android security feature that automatically reboots phones after three days of being locked, aiming to boost security. However, not everyone’s convinced it’s the right move.
A Silent but Significant Update
The change arrived as part of the mid-April update to Google Play services (version 25.14), listed under “Security & Privacy” in the official Google System Release Notes. The wording is brief but telling: “Enables a future optional security feature, which will automatically restart your device if locked for 3 consecutive days.”
Unlike the usual Android announcements, this one slipped in without much fanfare, i.e. with no flashy blog post or developer breakdown, just a line buried in a list of updates across devices from phones to TVs.
However, despite the quiet rollout, this appears to be a major shift in how Android handles device security, particularly for phones that may be lost, stolen, or seized.
Why Reboot After 3 Days? It’s All About Encryption and Access
The main reason for this new Android feature comes down to how data is encrypted, and when it’s most vulnerable.
When a phone has been rebooted and hasn’t yet been unlocked by its owner, it’s in what’s called the “Before First Unlock” (BFU) state. In this state, the most sensitive data on the device is fully encrypted and essentially out of reach, even for sophisticated forensic tools. However, as soon as a phone is unlocked, it enters what’s called the “After First Unlock” (AFU) state, where some decrypted data is held in memory to speed up performance and access.
It’s this that creates a window of vulnerability. For example, tools like Cellebrite and Magnet Forensics (often used by police or investigators) can take advantage of the AFU state to extract certain types of data, especially if the phone hasn’t been rebooted in several days. Security experts have long warned of this window/gap. For example, as cryptography professor Matthew Green of Johns Hopkins University put it when Apple introduced a similar feature last year: “If an attacker can keep your phone from rebooting, they can keep it in the vulnerable AFU state forever”.
Therefore, by automatically forcing a reboot after three days of lock-screen inactivity, Android ensures that any phone left unused will revert back to the much more secure BFU state. In effect, it closes the window of opportunity for anyone trying to get into a device without the owner’s passcode.
This appears to be the real driver behind the change, i.e. it’s not really about convenience or performance but rather it’s a deliberate step to reduce the chances of successful forensic data extraction, no matter who’s trying to get in.
Copying Apple’s Playbook?
As highlighted in the previous section, it should be noted that Apple implemented a similar feature last year, and some industry watchers see Google’s move as a belated but necessary catch-up.
With Android following suit in this way, it now seems that both major mobile platforms are adding time-based layers of protection to address real-world forensic threats.
Why Now?
Quite simply, Android following Apple’s lead could be seen as a response to growing forensic capabilities, i.e. the tools used by law enforcement and private analysts are becoming more adept at extracting data from unlocked phones.
What Does This Mean for Everyday Users?
For the average user, this change may go completely unnoticed, unless they’ve left their phone off or untouched for more than 72 hours. Then, they might return to find it’s unexpectedly rebooted and asking for a passcode, rather than accepting biometric logins.
That could be a mild nuisance, especially for business users who:
– Travel frequently and may leave a work phone powered off.
– Use backup phones or devices in rotation.
– Depend on biometric-only login (e.g. fingerprint or face unlock).
For these users, an unexpected reboot could mean delays in access, lost background data (e.g., unsaved files or chats), or even missed updates.
However, for companies handling sensitive data (e.g., law firms, healthcare providers, or cybersecurity outfits), this forced reboot adds another layer of protection, especially if a phone is stolen or misplaced.
Opt-In or Automatic?
One murky area is whether this reboot behaviour is mandatory or optional. In the release notes, Google refers to it as an “optional” feature. However, there’s no toggle visible yet in standard Android settings menus, and no guidance has been published on how users or admins can enable or disable it.
This apparent lack of clarity appears to have already drawn some criticism. For example, as highlighted on social media by tech privacy advocate Jake Williams, founder of Rendition Infosec: “Security through forced behaviour is only helpful if users understand it. Right now, there’s no visibility, no toggle, and no documentation. That’s not great.”
IT administrators managing fleets of Android devices through enterprise tools like Android Enterprise or Mobile Device Management (MDM) platforms are keen to know whether they’ll be able to manage this setting centrally and how this will interact with other enforced device policies.
Could It Disrupt Background Processes or Device Monitoring?
Another concern is how this auto-reboot might affect background tasks on enterprise phones. Some businesses use Android phones for unattended applications, like mobile monitoring, warehouse inventory, or transport tracking. For example, if a logistics firm has Android tablets locked in driver dashboards running 24/7, a forced reboot could temporarily interrupt GPS tracking or routing apps. If no one is around to unlock the rebooted device, it could remain offline.
These kinds of cases may not affect most consumers, but for business users relying on always-on systems, any unexpected restart appears to carry operational risk.
A Shift Toward Default Security Layers
While the auto-reboot change is just one line in a long list of system updates, it appears to be part of a continued evolution in Google’s security approach, one that leans more on automatic, default protections rather than user-controlled ones.
Alongside this feature, the April update also includes improvements to:
– Play Protect (Google’s built-in malware scanning tool).
– On-device location history settings (updated UI and controls).
– Device transfer and setup utilities (simplified for new phones).
It seems, therefore, that the goal appears to be to make Android safer out of the box, without requiring users to understand the details. That said, this approach could backfire if users feel blindsided or if critical details (like the three-day countdown) aren’t communicated clearly.
So far, Google hasn’t published any official blog post or help page detailing how this new auto-reboot works, why it’s been added, or how to manage it. Even the support site refers to it only briefly in system release notes, with no accompanying explanation.
That silence may fuel further criticism, especially in markets where trust in big tech is already fragile.
What Does This Mean For Your Business?
For such a low-key rollout, this new Android feature could have some wide-reaching consequences, both positive and problematic. At its core, the automatic reboot after three days of lock-screen inactivity is a serious move to bolster data protection. This reflects a growing recognition across the tech industry that data at rest (especially in the wrong state) can be dangerously vulnerable. For many users, especially those unaware of how phone encryption works, this update will simply run quietly in the background, but the shift it represents is anything but silent.
From a security perspective, this is clearly a step in the right direction. For businesses handling sensitive information, e.g. legal, financial, or healthcare providers, this automatic return to the most secure encryption state could offer an added layer of peace of mind. For example, a misplaced work phone left in the back of a taxi, or a stolen device locked in a drawer, now has a stronger line of defence by default. For UK businesses, particularly SMEs with fewer internal IT resources, this type of automatic protection may also help close security gaps that might otherwise go unaddressed.
However, Google’s quiet handling of the feature’s rollout has left some questions unanswered. For example, there’s no clear documentation, no toggle in user settings, and apparently no way (yet) for IT administrators to manage the setting across devices. This lack of transparency may create confusion for both individual users and enterprise teams, particularly if it disrupts business-critical processes running on unattended or semi-automated Android devices. For industries that rely on always-on tablets or mobile data terminals, the risk of unexpected downtime or access issues can’t really be ignored.
The fact that this is likely a response to increasingly powerful forensic tools also raises broader questions around user privacy and platform responsibility. Android’s decision mirrors Apple’s earlier move, but the timing and quiet delivery suggest a reactive rather than proactive approach. It may well strengthen security, but it also highlights how quickly threat landscapes can change, and how reliant users are on the decisions made behind the scenes by platform providers.
For now, the feature adds to a wider trend in Android development, i.e. automatic, behind-the-scenes protections designed to make devices safer out of the box, but as ever, the balance between security, usability, and transparency remains delicate. Whether this change becomes a quiet triumph or a point of friction will largely depend on how Google chooses to communicate it going forward, and how well it listens to the concerns of users, developers, and the businesses that rely on its platform every day.
