Есть внутреннее Android-приложение для полевой инвентаризации оборудования на складах и стройплощадках. Сейчас оно работает только онлайн: сканирование QR/штрихкодов, просмотр карточек, создание актов и фотофиксация. На объектах часто нет сети, из-за чего сотрудники ведут записи в сторонних заметках и потом вручную переносят данные. Нужно добавить полноценный офлайн-режим с надежной синхронизацией при появлении интернета. Техническая среда: Kotlin, Android 10+, MVVM, Retrofit, Room уже используется частично, серверное API менять нельзя. Авторизация по OAuth2, access token живет 30 минут, refresh token доступен. Бэкенд предоставляет REST endpoints: GET /items?updatedSince=timestamp, POST /acts, PATCH /items/{id}, загрузка фото отдельным endpoint. На сервере есть поле version (int) и updatedAt (ISO) для сущностей Item и Act, но конфликт-резолв на сервере отсутствует. Что требуется реализовать: - Локальное хранилище: расширить схему Room для Item, Act, Attachment, а также таблиц очереди операций (pending ops) и метаданных синхронизации. Данные (включая чувствительные поля и пути к вложениям) должны храниться с шифрованием на устройстве. Допустимо использовать Jetpack Security (EncryptedFile/EncryptedSharedPreferences) и/или SQLCipher for Android, выбор обосновать в комментарии к PR. - Очередь изменений: все действия пользователя в офлайне должны записываться как идемпотентные операции (создание актов, изменение статусов, привязка фото, правки полей), с возможностью повторной отправки без дублей. Для каждой операции нужен clientOperationId (UUID) и детерминированные правила повторной отправки. - Синхронизация в фоне: через WorkManager (constraints: network connected, battery not low). Реализовать двунаправленную синхронизацию: pull обновлений с сервера через updatedSince, затем push локальных операций. Поддержать backoff, частичные ошибки, сетевые таймауты и обновление токена. - Разрешение конфликтов на клиенте: если локально изменяли Item и на сервере он тоже изменился (version/updatedAt), нужно применить стратегию: приоритет у локального изменения для конкретного набора полей (зафиксировать список), но если конфликт по статусу/ответственному - показать пользователю экран сравнения с выбором варианта и логированием решения. Экран должен появляться только для реально конфликтующих сущностей. - Вложения (фото): сохранять фото локально с очередью загрузки, переживать перезапуск приложения. Ограничение: не более 50 МБ суммарно в очереди, при превышении показывать понятное уведомление и блокировать добавление новых вложений до синхронизации/удаления. - Телеметрия: добавить локальный лог синхронизации (в файл) с уровнями, без отправки наружу. Лог должен содержать количество операций, время синка, количество конфликтов, ошибки API. Конкретный результат: PR в репозиторий с рабочим офлайн-режимом, миграциями БД, тестами и краткой инструкцией как проверить на устройстве. Ограничения: серверное API не менять, новые библиотеки добавлять только при необходимости и с минимальным footprint, поддержка Android 10-14, приложение должно корректно работать без Google Play Services. Критерии приемки (измеримые): 1) В режиме airplane mode можно: отсканировать 30 позиций, изменить минимум 20 полей у разных Item, создать 5 Act и прикрепить 10 фото - все данные сохраняются локально и отображаются после перезапуска приложения. 2) После включения интернета синхронизация завершается без дублей: на сервере появляется ровно 5 новых Act, у Item нет повторяющихся изменений, все 10 фото привязаны. 3) При искусственно созданном конфликте (Item изменен на сервере после последнего pull, и тот же Item изменен локально) приложение выявляет конфликт и показывает экран сравнения; после выбора пользователя итог совпадает с выбранной версией, конфликт исчезает при следующем синке. 4) Фоновый sync через WorkManager выполняется не чаще чем раз в 15 минут, но ручной запуск из экрана настроек инициирует sync сразу. 5) Локальные данные действительно зашифрованы: нельзя прочитать содержимое БД/файлов вложений в открытом виде при копировании с устройства (достаточно указать способ проверки). Ожидаемые этапы: аудит текущей архитектуры и схемы данных, проектирование модели синка и конфликтов, реализация storage/queue, реализация sync engine, UI конфликтов, тестирование и стабилизация. Доступ предоставлю: исходники Android, Swagger/коллекция запросов, тестовый стенд API, несколько тестовых аккаунтов и сценарии полевых пользователей.