An annual offline-app review should prove that users can read and change the right data without a connection, understand what remains pending, reconnect without duplication, and recover from a failed update or lost device. Review the product with representative builds and synthetic records rather than relying on architecture diagrams.
Confirm supported conditions and ownership
List supported operating systems, app versions, devices, account types, offline duration, and features that intentionally require a connection. Name owners for the local database, synchronization service, API compatibility, authentication, backups, and incident response. Remove undocumented claims such as “works fully offline” when only part of the workflow is supported.
Trace several representative actions from user input to final synchronized state: open an existing record, create one offline, edit from two devices, delete an item, add an attachment, sign out, and reconnect after a long gap. Record which local store is authoritative and which server resolves conflicts.
Android's offline-first architecture guidance describes using a local data source for reads, persistent queues for deferred work, connectivity signals for synchronization, and versioning when local and network state conflict. Verify the current implementation still matches its written policy.
Reconcile local and queued data
Use synthetic accounts to inventory pending reads, writes, deletions, and attachment transfers. Every queued item should have a stable identifier, creation time, state, retry policy, and user-visible result. Test a process stop, device restart, intermittent network, expired authentication, and repeated reconnect. Confirm each operation is acknowledged once or remains visibly pending.
Review queue growth and retry behavior over a representative period. Look for requests that retry forever, silent permanent failures, duplicate server records, and work that disappears after sign-out. Check that a restored connection does not create a burst large enough to overwhelm the service or consume unreasonable battery and data.
Sample conflict cases. Android notes that offline writes may require version metadata and a defined resolution rule. Confirm the rule is suitable for each data type. Last-write-wins may be reasonable for a low-risk preference but unsafe for irreplaceable notes, permissions, financial records, or destructive actions. Preserve both versions or require review where loss would be consequential.
Test every supported migration path
Inventory local schema versions still present among active users and the upgrade paths they can take. Android's Room migration guidance recommends exporting schema history and testing automated and manual migrations. Recreate supported older schemas with invented fixtures, migrate them to the current version, and compare required records field by field.
Check downgrade and rollback boundaries. An older binary may be unable to read a newer schema. Document whether recovery uses a compatible backup, a forward repair, or a blocked downgrade. Do not use destructive migration fallback as a routine fix for data whose synchronization status is unknown.
Restore a real backup
Review what the supported backup includes and excludes: database, attachments, preferences, encryption material, device-only drafts, and pending operations. Android's backup testing guide uses a cycle of changing state, triggering backup, clearing or reinstalling, restoring, and validating the result. Run the full cycle with synthetic data.
After restore, work offline before reconnecting. Confirm restored identifiers do not cause duplicate uploads, old data does not overwrite newer server state, and blocked or expired accounts remain protected. Record backup and restore times, tool versions, fixture identifiers, expected values, and actual values.
Review privacy, security, and user control
Verify local encryption and key handling according to the platform's supported design. Confirm logs do not contain tokens or sensitive record contents. Test account removal, device handoff, and local-data deletion through the approved flow. Make clear which data remains because of backup, retention, or another signed-in device.
Review offline authentication behavior. Set an explicit grace period and risk boundary rather than allowing cached access indefinitely by accident. Check that permission changes and account suspension take effect when the app reconnects.
Rehearse failure and close decisions
Run a controlled recovery exercise covering a failed migration, a stuck queue, and a synchronization conflict. Confirm the alert, support view, manual fallback, rollback or forward-repair steps, and customer-safe communication. Account for every fixture after recovery.
Finish with owners and due dates for unsupported versions, queue defects, migration gaps, restore failures, excessive resource use, or unclear conflict rules. Keep the test matrix and baseline for next year. The review passes when offline work remains understandable and recoverable across disconnection, restart, upgrade, restore, and reconnection—not merely when the app opens in airplane mode.
Sources
- Build an offline-first app — Android Developers
- Migrate your Room database — Android Developers
- Test backup and restore — Android Developers