Android - Implementation of offline mode with diff-sync and encryption for field inventory application

There is an internal Android application for field inventory of equipment in warehouses and construction sites. Now it works only online: scanning QR/barcodes, viewing cards, creating acts and taking photographs. Sites often do not have a network, forcing employees to take notes in third-party notes and then manually transfer the data. We need to add a full-fledged offline mode with reliable synchronization when the Internet appears.

Technical environment: Kotlin, Android 10+, MVVM, Retrofit, Room is already partially used, the server API cannot be changed. Authorization via OAuth2, access token lasts 30 minutes, refresh token is available. The backend provides REST endpoints: GET /items?updatedSince=timestamp, POST /acts, PATCH /items/{id}, photo uploading as a separate endpoint. The server has a version (int) and updatedAt (ISO) field for the Item and Act entities, but there is no resolve conflict on the server.

What needs to be implemented:
- Local storage: extend the Room schema for Item, Act, Attachment, as well as pending ops tables and synchronization metadata. Data (including sensitive fields and attachment paths) must be stored encrypted on the device. It is acceptable to use Jetpack Security (EncryptedFile/EncryptedSharedPreferences) and/or SQLCipher for Android; justify your choice in a comment to the PR.
- Change queue: all user actions offline should be recorded as idempotent operations (creating acts, changing statuses, linking photos, editing fields), with the ability to resend without duplicates. Each operation requires a clientOperationId (UUID) and deterministic resubmission rules.
- Synchronization in the background: via WorkManager (constraints: network connected, battery not low). Implement bidirectional synchronization: pull updates from the server via updatedSince, then push local operations. Support backoff, partial errors, network timeouts and token refresh.
- Conflict resolution on the client: if the Item was changed locally and it also changed on the server (version/updatedAt), you need to apply a strategy: the local change has priority for a specific set of fields (fix the list), but if there is a conflict by status/responsible - show the user a comparison screen with selecting an option and logging the solution. The screen should only appear for entities that actually conflict.
- Attachments (photos): save photos locally with a download queue, survive application restarts. Limitation: no more than 50 MB in total in the queue; if exceeded, show a clear notification and block the addition of new attachments until synchronization/deletion.
- Telemetry: add a local synchronization log (to a file) with levels, without sending it outside. The log should contain the number of operations, synchronization time, number of conflicts, and API errors.

Specific result: PR to a repository with a working offline mode, database migrations, tests and brief instructions on how to check on the device.

Limitations: do not change the server API, add new libraries only when necessary and with a minimal footprint, support Android 10-14, the application must work correctly without Google Play Services.

Acceptance criteria (measurable):
1) In airplane mode, you can: scan 30 positions, change at least 20 fields for different Items, create 5 Acts and attach 10 photos - all data is saved locally and displayed after restarting the application.
2) After turning on the Internet, synchronization is completed without duplicates: exactly 5 new Acts appear on the server, Item has no duplicate changes, all 10 photos are linked.
3) In case of an artificially created conflict (Item is changed on the server after the last pull, and the same Item is changed locally), the application detects the conflict and shows a comparison screen; after the user selects the result matches the selected version, the conflict disappears with the next synchronization.
4) Background sync via WorkManager is performed no more than once every 15 minutes, but manual launch from the settings screen initiates sync immediately.
5) Local data is truly encrypted: it is impossible to read the contents of the database/attachment files in clear text when copied from the device (it is enough to specify the verification method).

Expected stages: audit of the current architecture and data schema, design of a sync and conflict model, implementation of storage/queue, implementation of the sync engine, UI conflicts, testing and stabilization.

I will provide access to: Android sources, Swagger/request collection, API test bench, several test accounts and field user scenarios.