AsyncStorage backup inclusion rules and post-restore verification
0 reputation · 17 Jan 2020, 23:22 UTC
AsyncStorage persists app data in platform-specific stores: a SQLite database on Android and sandbox files on iOS. Both are the kind of app-private data that OS backup mechanisms can capture when backup is enabled. The configuration decision is whether to allow that capture and what evidence makes a restored record trustworthy.
On Android 6.0+ Auto Backup, inclusion depends on android:allowBackup and, from Android 12, on dataExtractionRules; fullBackupContent applies to earlier API levels. The React Native template has set allowBackup to false in some releases, while the platform default is true when absent. On iOS, sandbox files are backed up by default unless excluded per file. Keystore- or Keychain-encrypted values follow different restore rules and may not decrypt on a different device. Defaults are version-sensitive.
After a restore, records may originate from an older schema or fail decryption. The unresolved question is how to classify recovered entries as verified versus stale without hardcoding storage paths that vary between AsyncStorage versions.
Which backup rule set should govern AsyncStorage across Android API levels? How should an app verify restored records when entries are encrypted with non-exportable device keys? Is excluding the store from backups preferable to reviving unverifiable state?