Синхронизация данных через Google Drive API в мобильном приложении

Реализация синхронизации данных через Google Drive

Вы запустили мобильное приложение с заметками. Через месяц пользователь жалуется: при переустановке все данные пропали. Вы подключаете Google Drive API — пользователь уже авторизован, квота 15 ГБ бесплатно. Но интеграция оказывается сложнее, чем кажется: токены протухают, конфликты версий приводят к потере заметок, фоновая синхронизация разряжает батарею. На основе 5 лет опыта мы собрали работающее решение: код, конфиги и архитектуру.

В отличие от Firebase или собственного бэкенда, данные хранятся на личном аккаунте пользователя: он контролирует их и может удалить в любой момент. Это даёт пользователю контроль над приватностью, а разработчику — экономию на серверной инфраструктуре. Наш опыт — 5 лет в мобильной разработке, более 10 проектов с синхронизацией через Drive.

Почему Google Drive, а не Firebase?

Firebase предлагает готовую синхронизацию, но привязывает пользователя к вашему аккаунту и требует оплаты. Google Drive использует личное хранилище пользователя — вы не платите за серверы, а пользователь контролирует свои данные. Для резервных копий и настроек Drive надёжнее: файлы хранятся в аккаунте Google, который редко теряется. Сравнение затрат: Firebase Realtime Database для 10 000 пользователей требует ежемесячных платежей (зависит от трафика), а Drive бесплатен в рамках квоты пользователя. При этом скорость синхронизации ниже, но для фоновых бэкапов это некритично.

Но синхронизация через Drive API скрывает подводные камни: авторизация, квоты, конфликты версий, фоновая синхронизация на Android с WorkManager. Без правильной архитектуры данные потеряются или приложение получит массу ошибок. Рассмотрим, как спроектировать надёжное решение.

Как выбрать между AppData folder и Drive Files?

Google Drive API предоставляет два типа хранилища для приложений, и выбор критичен для архитектуры.

Application Data folder — скрытая папка, видная только вашему приложению. Пользователь не видит файлы в Drive UI, но они занимают его квоту. Идеально для резервных копий и синхронизации настроек.

Drive Files — обычные файлы в Drive пользователя, видимые в интерфейсе. Нужен scope drive.file — приложение может работать только с файлами, которые само создало.

Для синхронизации данных приложения — Application Data folder. Для работы с пользовательскими документами — Drive Files.

Какие данные синхронизировать через AppData folder?

Аутентификация через Google Sign-In

Google Drive API documentation рекомендует использовать OAuth 2.0 с соответствующим scope. Ниже пример на Kotlin.

// Android: настройка Google Sign-In с Drive scope val signInOptions = GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN) .requestScopes(Scope(DriveScopes.DRIVE_APPDATA)) .requestEmail() .build() val googleSignInClient = GoogleSignIn.getClient(activity, signInOptions) // После успешного входа получаем credentials fun handleSignInResult(completedTask: Task<GoogleSignInAccount>) { val account = completedTask.getResult(ApiException::class.java) val credential = GoogleAccountCredential.usingOAuth2( context, listOf(DriveScopes.DRIVE_APPDATA) ) credential.selectedAccount = account.account // Drive service для API-запросов driveService = Drive.Builder( NetHttpTransport(), GsonFactory.getDefaultInstance(), credential ).setApplicationName("MyApp").build() } 

На iOS — GoogleSignIn-iOS SDK с аналогичной настройкой scope.

Создание и обновление файлов резервной копии

class GoogleDriveBackupManager(private val driveService: Drive) { suspend fun saveBackup(data: AppBackupData) = withContext(Dispatchers.IO) { val json = Json.encodeToString(data) val content = ByteArrayContent("application/json", json.toByteArray(Charsets.UTF_8)) // Ищем существующий файл резервной копии val existingFileId = findBackupFile() if (existingFileId != null) { // Обновляем существующий driveService.files().update(existingFileId, null, content) .execute() } else { // Создаём новый в appDataFolder val fileMetadata = File().apply { name = "app_backup.json" parents = listOf("appDataFolder") } driveService.files().create(fileMetadata, content) .setFields("id, name, modifiedTime") .execute() } } private fun findBackupFile(): String? { val result = driveService.files().list() .setSpaces("appDataFolder") .setFields("files(id, name, modifiedTime)") .setQ("name = 'app_backup.json'") .execute() return result.files?.firstOrNull()?.id } suspend fun loadBackup(): AppBackupData? = withContext(Dispatchers.IO) { val fileId = findBackupFile() ?: return@withContext null val outputStream = ByteArrayOutputStream() driveService.files().get(fileId) .executeMediaAndDownloadTo(outputStream) val json = outputStream.toString(Charsets.UTF_8.name()) Json.decodeFromString<AppBackupData>(json) } } 

Как обрабатывать конфликты синхронизации?

Для приложений с множеством сущностей используем отдельный файл на каждый тип данных или версионированные снепшоты. Сравниваем modifiedTime — устройство с более новым файлом считается авторитетным. Если разница менее минуты, приоритет отдаём локальным данным. Это стандартный подход для offline-first архитектуры.

Сжатие gzip уменьшает размер данных на 60–80% — это в 2–5 раз ускоряет передачу по сети и снижает расход квоты Drive. Экономия на трафике заметна уже при 100 МБ данных.

Синхронизация нескольких файлов

data class DriveFileInfo( val id: String, val name: String, val modifiedTime: com.google.api.client.util.DateTime, val size: Long ) suspend fun listBackupFiles(): List<DriveFileInfo> = withContext(Dispatchers.IO) { val result = driveService.files().list() .setSpaces("appDataFolder") .setFields("files(id, name, modifiedTime, size)") .setOrderBy("modifiedTime desc") .execute() result.files?.map { file -> DriveFileInfo( id = file.id, name = file.name, modifiedTime = file.modifiedTime, size = file.getSize() ?: 0L ) } ?: emptyList() } 

Фоновая синхронизация

Используем WorkManager для периодической синхронизации — он корректно обрабатывает жизненный цикл Android и не разряжает батарею.

class DriveBackupWorker( context: Context, params: WorkerParameters, private val backupManager: GoogleDriveBackupManager, private val localDataManager: LocalDataManager ) : CoroutineWorker(context, params) { override suspend fun doWork(): Result { return try { val localData = localDataManager.exportAll() backupManager.saveBackup(localData) Result.success() } catch (e: UserRecoverableAuthIOException) { // Токен истёк — нужна переаутентификация notifyAuthRequired() Result.failure() } catch (e: IOException) { // Сетевая ошибка — retry Result.retry() } } } // Регистрация периодического бэкапа val backupRequest = PeriodicWorkRequestBuilder<DriveBackupWorker>(6, TimeUnit.HOURS) .setConstraints(Constraints( requiredNetworkType = NetworkType.UNMETERED, // только WiFi requiresBatteryNotLow = true )) .build() 

Обработка квоты и ошибок

Google Drive квота у пользователя обычно 15 ГБ, но не бесконечна. Мы применяем:

• Сжатие данных перед сохранением (gzip JSON-файлов даёт 60–80% экономии)
• Хранение только последних 3–5 версий резервных копий
• Отображение пользователю размера занятого места

suspend fun getAppDataFolderSize(): Long = withContext(Dispatchers.IO) { val files = listBackupFiles() files.sumOf { it.size } } 

UserRecoverableAuthIOException — токен истёк или пользователь отозвал доступ. Нельзя игнорировать. Перехватываем, показываем UI для повторной авторизации.

Rate limiting. Drive API ограничен 1000 запросов в 100 секунд на пользователя. Используем батчевые запросы, кэширование на клиенте, синхронизацию по таймеру или при выходе из приложения.

Процесс работы

1. Анализ архитектуры приложения и выбор стратегии синхронизации.
2. Проектирование схемы данных и версионирования.
3. Реализация аутентификации и менеджера резервного копирования.
4. Настройка фоновой синхронизации через WorkManager.
5. Тестирование на реальных устройствах с различными версиями ОС.
6. Деплой и мониторинг.

Что входит в работу

• Анализ архитектуры приложения и выбор стратегии синхронизации
• Реализация аутентификации через Google Sign-In
• Создание менеджера резервного копирования с версионированием
• Настройка фоновой синхронизации через WorkManager
• Документация по интеграции (код, конфиги, инструкции)
• Тестирование на реальных устройствах
• Поддержка в течение месяца после сдачи

Реализация синхронизации через Google Drive с фоновым бэкапом, версионированием и обработкой авторизации: 2–3 недели. Стоимость рассчитывается индивидуально. Получите консультацию — оценим ваш проект бесплатно. Свяжитесь с нами для детального анализа вашего приложения.