How do you leverage WorkManager to guarantee execution, handle conflict resolution, and optimise battery usage in an offline-first Android application requiring bidirectional synchronisation?

Short answer

Offline-first Android sync keeps the local database as the UI source of truth, records pending changes and tombstones, then uses WorkManager constraints, retries, batching, and conflict handling to upload before downloading without draining battery.

Why naive retry queues collapse in practice

Building robust, offline-first applications for environments with intermittent connectivity is a notoriously difficult problem. The naive approach relies on checking the network state before every API call and attempting to queue failed requests in memory or a simple SQLite table. This strategy collapses almost immediately. In-memory queues do not survive process death, simplistic retries drain the battery, and treating the network as the source of truth leads to a frozen, unresponsive UI whenever connectivity fluctuates.

The local source of truth

A true offline-first architecture dictates that the local database is the single source of truth for the UI. The application remains fully responsive regardless of network state. This requires a robust local schema—typically using Room—augmented with metadata columns to track the synchronisation state of each record (sync_status: pending, synchronised, failed) and a last_modified_timestamp. Crucially, deletions cannot be physical; a soft-delete mechanism using tombstone flags ensures that deletions made offline are correctly propagated to the backend rather than silently disappearing before sync occurs.

Architecting the sync pipeline

Android's WorkManager is the standard for guaranteed background execution. The synchronisation pipeline must be carefully choreographed using unique work requests for uploading local changes and downloading remote updates. Order of operations is paramount: local changes must be pushed to the server before pulling the latest server state to prevent local modifications from being overwritten. Utilising WorkManager's beginUniqueWork API to chain these tasks establishes a sequential dependency that guarantees the upload worker completes successfully before the download worker begins.

These workers must be configured with specific constraints, ensuring they only execute when the device has an appropriate network connection and a sufficient battery level.

Handling failure and conflicts

Network instability is a certainty, not an edge case. Upload workers require an exponential backoff policy for 500-level errors or timeouts, returning Result.retry() to allow WorkManager to gracefully reschedule. Conversely, 400-level errors (validation failures or conflict rejections) should not be retried infinitely; the worker must return Result.failure() and log the error for user intervention.

Conflict resolution is the hardest part of bidirectional sync. A hybrid approach is often necessary. For non-critical fields, a last-write-wins policy based on the last_modified_timestamp is sufficient. For critical relational data, a server-authoritative policy is safer, combined with a separate delta table that saves local conflicting changes. This allows the user to manually review and merge changes through a dedicated UI. The synchronisation payload must include both the updated fields and the original version of the record (optimistic concurrency control) so the backend can detect if the record was modified by another client.

Optimizing execution

As datasets grow, full synchronisation runs will exceed WorkManager's maximum execution time and be killed by the OS. Synchronisation must be optimized via cursor-based pagination for downloads (fetching only records modified after the last successful sync) and batching for uploads. Breaking synchronisation tasks into smaller, granular chunks ensures each worker completes its unit of work well within the execution window allowed by the operating system, preserving battery life and data integrity.

flowchart TD
  A["Local Room Database"] -- "Triggers Sync" --> B["WorkManager Upload Worker"]
  B --> C{"Network Request"}
  C -- "Success" --> D["WorkManager Download Worker"]
  C -- "Failure (500/Timeout)" --> E["Exponential Backoff Retry"]
  C -- "Failure (400/Conflict)" --> F["Log Conflict for Review"]
  D --> G{"Process Remote Changes"}
  G -->|Resolve Conflicts| A
  G -->|Update Timestamps| A

Designing an offline-first architecture requires a robust approach to state management, conflict resolution, and reliable background execution. Leveraging WorkManager with strategic constraints and backoff policies ensures data integrity and preserves battery life under unpredictable network conditions.

© 2026 Preptima. Originally published at preptima.com.