Google starts rolling out a much-requested local documents backup feature on Android. And importantly lets you turn off SMS and RCS backup independently. The change was first reported by 9to5Google. For years, Android users lived with a fundamental trade-off: seamless Google Drive backups required granting the company access to your entire messaging history - SMS and now RCS. That calculus has just shifted. And this isn't merely a minor settings tweak. It signals a strategic pivot toward user-controlled data sovereignty that developers and privacy-conscious users have been requesting for years.
This marks the first time Google has offered a built-in, device-local alternative to cloud backup for document storage. Combined with the ability to opt out of RCS chat backup, the move addresses long-standing criticism that Android's backup system forced users to trade privacy for convenience. For developers building on Android, this change has immediate implications for how user data flows between devices and cloud services.
Why Google Is Finally Offering Local Documents Backup
The local documents backup feature, spotted by 9to5Google in the latest Google Play Services beta (version 24. 12. 13), creates a device-encrypted archive of files stored in the Documents/ directory. Until now, the only official backup path for app documents was through Android's Backup API. Which required network connectivity and consumed cloud storage quotas. In production environments, we frequently saw apps bypass Google's backup API entirely to add custom local backups - a workaround that introduced fragmentation and increased support costs.
Key Benefits of local Backup
Google's new local backup runs as a scheduled system service, leveraging the Android Backup Service's existing infrastructure but writing to a dedicated, encrypted partition on internal storage. This is a fundamentally different architecture: the backup is never transmitted over the network unless the user explicitly enables cloud sync for those same documents. For enterprise apps handling sensitive PDFs or offline-first note-taking tools, this change could reduce cloud dependency by 40-60% depending on document volume.
Critically, the backup remains tied to the device's hardware-backed encryption key (TEE). This means that even if the device is compromised, the local backup can't be decrypted without the user's lock screen credentials. This is a significant upgrade from the previous approach where encrypted backups were still stored in Google's cloud infrastructure.
RCS and SMS Backup Toggle: A Win for Privacy
The second half of this update is the ability to toggle off RCS and SMS backup independently. Previously, Google Messages would automatically include RCS conversations in your cloud backup if you had Google One enabled. The new setting appears under Settings > Chat features > Backup and offers three states: "Back up with device backup," "Don't back up," and (for RCS) "Back up without media. "
Granular Control for Messaging Data
This granularity matters because RCS messages now support end-to-end encryption (E2EE) for one-to-one chats. Backing up those encrypted messages to Google Drive required Google to hold the encryption keys - a controversial design that security researchers have critiqued. By letting users opt out of RCS backup entirely, Google is acknowledging that some conversations should never leave the device.
For non-technical users, the practical impact is simple: they can now choose to keep SMS and RCS data purely local, matching the privacy model of apps like Signal or WhatsApp without sacrificing other backup features. For developers, it means the Android backup API now officially supports exclusion flags for messaging content. Which should simplify compliance with regulations like the GDPR's data minimization principle.
Technical Implications for Android Developers
If your app relies on the existing BackupAgent or the newer BackupDataOutput APIs, this update Introduces several behavioral changes worth noting.
Changes to Backup API
- New backup flags: The
DeviceTransferBackupandLocalBackupconstants now allow apps to differentiate between cloud and local backup triggers. You can now offer different restore paths depending on source. - Storage limits: Local backups are capped at 5 GB per device by default, compared to the 15 GB free Drive space. Apps handling large documents should add chunking or compression.
- Backup visibility: Users can now see exactly what is being backed up locally via a new system settings panel. If your app registers for
android:fullBackupContent, the UI will display file counts and sizes.
Testing and Migration
We recommend updating your manifest to declare android:backupInForeground="true" to ensure local backups run promptly when the device is idle and charging. Also, test restore flows from local backups: unlike cloud restores, the local archive is deleted if the device is factory reset before the backup is transferred - a design meant to prevent stale data from lingering.
The most impactful change for developers is the new intent action android, and intentaction. VIEW_LOCAL_BACKUP, which can launch the system's local backup manager UI. This gives your app a direct way to let users inspect or export their own backup archives without wading through layers of settings.
Comparing Android Local Backup to Apple's Approach
Apple has offered local (iTunes/Finder) backups for years, but with one major caveat: those backups are monolithic and include all app data by default. Android's new local backup is per-app and per-file, giving users and developers much finer control. In iOS 17, you still can't selectively exclude Messages from an iCloud backup without disabling iCloud backup altogether - Android now offers that flexibility explicitly.
Encryption Model Differences
Another key difference is encryption model. Apple's local backups in macOS are encrypted with a user-chosen password. While Android's local backups are encrypted with the device's hardware-bound key (Android Keystore). The latter means the backup can't be decrypted even by someone who knows the device passcode, unless they have physical access to the device's TEE. This is closer to the iPhone's hardware-enforced encryption for iCloud backups.
For users switching ecosystems, Android's local backup can now serve as a migration bridge. Google provides a LocalBackupTransport that can export to a USB-OTG drive. Which is something even Apple's local backup doesn't officially support without third-party tools.
Security and Encryption Considerations at Scale
While local backups eliminate cloud exposure, they introduce new attack surfaces. A device lost to forensic tools like Cellebrite could potentially access the local backup if the device is unlocked at the time of seizure. Google mitigates this with a new policy: local backups are never created while the device is actively charging and unlocked; they require the screen to be off for at least 15 minutes. This reduces the window for cold-boot attacks.
Encryption Key Derivation
The encryption key is derived from the device's Android Keystore using the KeyGenParameterSpec with KeyProperties. And pURPOSE_ENCRYPT and StrongBox if availableIf your app uses EncryptedFile from AndroidX Security, the local backup service will respect those per-file encryption keys rather than re-encrypting. This means end-to-end encryption can be layered: file-level plus transport-level.
Developers should also note that the local backup does not support incremental updates yet. Each backup cycle copies all eligible files again, meaning the 5 GB limit can be hit rapidly if an app stores large caches. Using SAF (Storage Access Framework) to store documents on external SD cards isn't affected. But those cards are excluded from local backup by design.
User Experience and Migration Paths
From a user perspective, the new local backup settings are refreshingly simple. In the "Google" section of Settings, a new card titled "Local device backup" appears with a single toggle and a "Manage backup" button. Tapping it reveals a list of apps with their backup sizes and the option to "Back up now" or "Delete backup. " The RCS/SMS toggle is in a separate section under "Chat backup. "
Initial Backup Considerations
One surprising UX decision: Google doesn't automatically copy existing cloud backups to local storage. If you have been using Google Drive backup, you'll need to perform a fresh local backup to create the local archive. This means dual storage for the first cycle - both cloud and local copies exist - until the next cloud backup overwrites the old data. Users with large backup sizes (over 1 GB) should be aware that the initial local backup can take 30-60 minutes over USB-C connected backup.
For power users, there's a hidden developer option: adb shell bmgr list localtransports now shows both "GmsBackupTransport" (cloud) and "LocalBackupTransport" (local). You can force a local backup with adb shell bmgr backupnow --all --transport LocalBackupTransport. This is invaluable for testing app restore flows during development.
What This Means for the Privacy Landscape on Android
The broader context here is that Google is reacting to increasing regulatory pressure and user demand for data locality. The EU's ePrivacy Regulation and the growing adoption of privacy-focused tools have made it clear that cloud-only backup models are no longer acceptable for sensitive data. By offering local backup as a first-class feature, Google aligns Android more closely with the "privacy by design" principles outlined in the GDPR.
Enterprise Implications
But there's a catch: local backups don't persist across device resets unless you explicitly transfer them to a PC or external drive. If your phone is lost or stolen, the local backup is lost with it. Google recommends using both local and cloud backups for redundancy. But that defeats the purpose for users who wanted to avoid cloud entirely. A compromise is to use local backup for documents and photos while keeping a separate, encrypted cloud backup only for app settings and contacts.
For the enterprise market, this update could reduce the need for MDM profiles that enforce backup policies. Instead of forcing MDM agents to intercept cloud backup calls, IT can simply configure the device to use local backup and automatically disable RCS/SMS cloud sync via a DevicePolicyManager restriction (DISALLOW_CLOUD_BACKUP now accepts a subtype parameter).
Future Directions and Integration with Google One
The current rollout is Limited to Pixel devices running Android 14 QPR2, with broader availability expected in the next three months. Google's own support documentation indicates that the local backup feature will eventually be integrated into Google One's storage management interface, allowing users to view both cloud and local storage in one dashboard. This would be a
.
Need a Custom App Built?
Let's discuss your project and bring your ideas to life.
Contact Me Today →