Does Android Auto Backup Save TWA IndexedDB Data?

Understanding Android Auto Backup and Trusted Web Activities

Many web developers transitioning to Android assume that once their Progressive Web App is compiled into a signed APK or AAB, it will behave exactly like a native app. One common point of confusion is how local storage, database persistence, and system-level backups operate. Native Android apps leverage Android Auto Backup to automatically upload user data to Google Drive, restoring it seamlessly when a user switches to a new mobile device. However, a Trusted Web Activity operates under a fundamentally different architectural model.

Because a Trusted Web Activity relies on a web engine provider such as Google Chrome, its local storage layers are isolated from the native wrapper. Developers must understand how storage, native sandboxes, and cloud backups interact in order to prevent unexpected data loss for their users.

The Core Architecture: Sandbox Separation

To understand why standard Android backups do not capture web data, it is necessary to examine the architectural split between the native TWA client and the browser provider. When you build a TWA, you are compiling a lightweight native wrapper. This wrapper contains the configurations, splash screen assets, app icons, and deep-linking rules required to satisfy the Google Play Store. It is compiled with its own unique package name.

When a user launches the app, this native wrapper initiates a secure protocol that opens the designated web origin inside Chrome or another compatible browser. While the app appears full-screen without a URL bar, the underlying engine is still the device web browser. Consequently, the data structures are stored in two entirely separate directories on the physical device.

The Native Wrapper Directory

The native wrapper maintains its own private directory located within the Android file system, typically under the path data/data/your.package.name. This directory holds system-level configuration parameters, minor native settings, cache files associated with the native splash screen, and shared preference files managed by the wrapper code.

The Browser Provider Directory

The web storage elements, including cookies, LocalStorage, Cache Storage, and IndexedDB, are stored within the application directory of the browser provider, such as data/data/com.android.chrome. This web data is scoped by origin, meaning your web application domain governs access to the records, but the files physically reside within Chrome's application sandbox.

How Android Auto Backup Evaluates TWAs

Android Auto Backup operates by default on all applications targeting modern Android SDK versions. When a backup cycle is triggered by the operating system, Android packages the contents of the application private directory up to a limit of 25 megabytes per user. It then uploads this archive to Google Drive.

When the backup agent runs against your TWA app, it scans your unique native package directory. Because your native directory only contains wrapper configuration files and splash screen metadata, only these elements are backed up. The massive database where your users store their offline items, drafted documents, session keys, and custom application states remains entirely inside the Chrome browser directory.

The Android operating system does not traverse the boundaries between Chrome and your wrapper app during a backup sequence. Therefore, if a user upgrades to a brand-new Android device, installs your TWA from the Google Play Store, and opens it, their locally saved IndexedDB and LocalStorage data will not be restored by the TWA backup process. The app will launch with empty web storage databases, forcing the user to start from scratch.

Comparing Wrapper App Data vs. Web Engine Storage

To illustrate what is preserved and what is lost during device migrations, examine the structural differences between these directories.

The Risk of Relying on Browser-Level Account Syncing

Some developers assume that Google Chrome's native account synchronization will rescue their web data. If a user is logged into their Google account inside Chrome, certain data types can sync across platforms. However, Chrome sync prioritises bookmarks, history, passwords, and open tabs.

Chrome does not synchronise complex web databases such as IndexedDB or heavy cache partitions across devices due to bandwidth limits, privacy rules, and storage size constraints. Even if some cookies or credentials sync occasionally, developers cannot rely on this mechanism to maintain continuous, complex application states. A user moving to a new phone will experience data loss if your app relies strictly on client-side IndexedDB persistence.

Designing a Resilient Data Strategy for TWAs

To ensure your users do not lose their data, you must bypass native backup constraints and use web-first patterns. This is standard practice for modern web development, but it becomes critical when your PWA is presented as a native desktop or mobile app via a TWA.

Implement Centralised Cloud Synchronization

The most robust solution is to treat local web storage purely as an offline cache. Your primary database should reside on a cloud server, accessed over HTTPS via a secure API. When users create accounts, sync their settings, notes, or progress to the cloud. When they download your app on a new device and authenticate, populate the local IndexedDB database from the cloud backup.

Manual Backup Export and Import

If you run a privacy-focused offline-first application that does not use user accounts or cloud databases, you must provide a way for users to manually migrate their data. Implement an export feature inside your web application that stringifies the IndexedDB data into a JSON file. Use the File System Access API or standard web download triggers to save this file to the local Android Download directory. Users can then move this file to their new device and use an import button within your app to restore their database states.

Request Persistent Storage

While persistent storage does not help with backups across devices, it prevents the Android OS from deleting your local data when device storage runs low. By default, IndexedDB databases are marked as temporary, meaning the browser can discard them if space is critically low. Use the persistent storage API to explicitly ask the browser to preserve your database.

if (navigator.storage && navigator.storage.persist) { navigator.storage.persist().then(granted => { if (granted) { console.log("Storage persistence granted"); } }); }

Conclusion

Android Auto Backup is a powerful tool for traditional native apps, but it offers minimal value to Trusted Web Activities because of sandbox separation. The native wrapper is backed up, but the web engine directory containing IndexedDB and LocalStorage data is not. To deliver a seamless user experience across device migrations, you must build cloud-based synchronization or explicit manual export systems within your progressive web application. This ensures that no matter what device your users use to access your converted app, their data remains intact.