Є внутрішнє 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, кілька тестових акаунтів і сценарії польових користувачів.