An offline app change can affect data that exists only on a device, data waiting to synchronize, and records that have already diverged from a server copy. Evidence should make those states visible. Keep a small, reproducible packet that proves what version ran, how local data changed, what happened offline, and what happened after reconnection.
Identify every version boundary
Record the old and new app build identifiers, release channel, signing identity reference, operating-system version, device or emulator model, local database schema, sync protocol, and relevant server API version. Preserve the source revision and build receipt if the team controls the app. Do not copy private signing keys, access tokens, or user credentials into the evidence packet.
State the intended change in user terms and technical terms. For example: a new field becomes editable offline, its local schema adds a column, and a queued operation sends the field after connectivity returns. List the data and behavior that must remain unchanged.
Preserve schema and migration evidence
For apps using Room, Android’s database migration guidance recommends exporting schema history and retaining it in version control so older versions can be recreated for tests. Keep the before and after schema artifacts, every supported migration path, migration test output, and validation queries for important records.
Record whether downgrade is supported. If it is not, say so plainly. The same Android guidance warns that destructive migration fallback permanently deletes table data when no path exists. Evidence should show that the production configuration does not invoke destructive behavior unexpectedly, and any intentionally destructive test must use disposable synthetic data.
Keep a state manifest, not a data dump
Create a test manifest with synthetic records representing synced data, offline-created data, pending edits, deletion, attachment metadata, preferences, and a planned conflict. Give records stable test identifiers and expected values. A hash or count can help compare larger fixtures, but retain a human-readable list of the critical assertions too.
Avoid exporting real customer content merely for convenience. If a production defect requires real evidence, minimize the fields, redact where possible, record lawful purpose and access, and follow the organization’s retention policy. The test packet should usually be fully reproducible without personal data.
Document the offline and reconnect phases
Record the starting network condition, when connectivity is removed, actions performed offline, app restarts, queued-operation count, retry state, and any visible warnings. Android’s offline-first architecture guidance explains that the local data source commonly acts as the canonical read source while network state may lag, and that reconnection can require conflict resolution and version metadata.
For each queued action, preserve its test identifier, operation type, creation time, attempt history, acknowledgement, and final state. Do not log secrets or full private payloads. For the planned conflict, record both local and remote starting values, the configured resolution policy, the observed winner, and what the user sees.
Prove backup and restoration separately
Keep the backup method, scope rules, transport or storage class, creation time, app version, restore target, and validation result. Android’s backup and restore test guide demonstrates that testing includes changing app state, producing a backup, reinstalling or clearing the app, restoring, and confirming the retained state. A successful backup command without a restore result is incomplete evidence.
Test both the supported same-device and device-transfer scenarios when the product claims them. Record excluded caches or regenerable files so their absence is not mistaken for data loss. Also record settings or credentials that are intentionally not restored.
Capture results as assertions
Use a checklist that names the assertion, expected result, actual result, evidence location, and reviewer. Include cold launch while offline, reads from local storage, local edits, process restart, migration, backup restore, reconnect, retry, conflict resolution, duplicate prevention, and final data reconciliation. Record failures and unknowns; do not change the expected result after the test.
Finish with the release decision, authorized reviewer, open risks, rollback or forward-fix constraints, and next test date. Retain only the evidence needed to reproduce and explain the outcome. The strongest packet is not the largest one—it is the one that lets another person rebuild the starting state, repeat the transition, and confirm whether user work survived.
Sources
- Migrate your Room database — Android Developers
- Build an offline-first app — Android Developers
- Test backup and restore — Android Developers