**Подготовка (0-10 минут): Диагностика и планирование**
Не бросайтесь сразу менять версию в `build.gradle`. Первые 10 минут посвятите разведке.
- **Определите текущее состояние.** Откройте файл `build.gradle` уровня модуля (обычно `app/build.gradle`). Найдите зависимости `com.google.android.gms:play-services-*` и `com.google.firebase:firebase-*`. Зафиксируйте текущие версии. Также проверьте `com.google.gms:google-services` в корневом `build.gradle`.
- **Изучите примечания к выпуску (Release Notes).** Перейдите на официальную страницу [Google Play Services Release Notes](https://developers.google.com/android/guides/releases). Внимательно прочтите заметки о версии, на которую планируете обновляться. Ищите ключевые слова: `breaking changes`, `deprecated`, `behavior changes`. Особое внимание уделите тем модулям, которые вы используете (например, Maps, Location, Auth, Analytics).
- **Оцените объем изменений.** Если обновление минорное (например, с 20.3.0 до 20.4.0), риски ниже. При переходе на мажорную версию или обновлении с очень старой версии будьте готовы к более тщательному тестированию. Если времени в обрез, возможно, стоит обновиться только на один-два патча, а не прыгать на последнюю мажорную.
- **Создайте новую git-ветку.** Например, `hotfix/update-play-services`. Вся работа ведется в ней.
- **Обновите версию Google Play Services.** В файле `app/build.gradle` обновите версии. Рекомендуется использовать [Bill of Materials (BOM) Firebase](https://firebase.google.com/docs/android/learn-more#bom), который обеспечивает совместимость версий библиотек Firebase. Если вы его используете, обновите только `platform('com.google.firebase:firebase-bom:XXX')`. Если нет — обновите каждую зависимость вручную, соблюдая совместимость. Для не-Firebase компонентов Play Services можно использовать общую версию, но лучше уточнить в документации.
- **Синхронизируйте проект.** Нажмите `Sync Now` в Android Studio. Это критический момент. Если синхронизация прошла успешно — хороший знак. Если появились ошибки разрешения зависимостей (dependency resolution), вам可能需要 явно указать версии для конфликтующих библиотек или использовать `force` (как временное решение). Часто помогает очистка кэша Gradle: `./gradlew cleanBuildCache`.
- **Соберите проект.** Запустите `./gradlew :app:assembleDebug` из командной строки или через IDE. Убедитесь, что сборка завершается без ошибок.
- **Запустите Lint.** Выполните `./gradlew :app:lintDebug`. Статический анализ может выявить использование устаревших (deprecated) API, на которые могли указать в release notes. Быстро просмотрите отчет, сфокусировавшись на ошибках (errors) и предупреждениях (warnings), связанных с Google Play Services.
- **Проверьте, нет ли удаленных API.** Если в release notes указано на удаление какого-то метода или класса, поищите его использование в вашем коде через `Find in Path` (Ctrl+Shift+F) в Android Studio.
У вас нет времени на полный регресс. Сфокусируйтесь на сценариях, которые напрямую используют обновленные библиотеки.
- **Разверните Debug-сборку** на подключенном устройстве или быстром эмуляторе (предпочтительно с Google Play Services).
- **Составьте чек-лист из 5-7 ключевых пользовательских сценариев.** Например:
* Отправка аналитического события (Firebase Analytics).
* Получение push-уведомления (Firebase Cloud Messaging).
* Работа с облачным хранилищем (Firebase Firestore/Storage).
* Проверка in-app покупок (если используете Billing).
- **Быстро пройдите каждый сценарий.** Фиксируйте любые падения приложения (crashes), ошибки в логах (Logcat) и некорректное поведение. Особое внимание уделите разрешениям (permissions) — иногда их обработка меняется.
- **Проверьте мониторинг.** Если у вас есть интеграция с Crashlytics (Firebase Crashlytics), убедитесь, что после обновления он продолжает работать и отправлять отчеты.
Если все ключевые сценарии работают, сборка стабильна, а Lint не выявил критических проблем, можно двигаться дальше.
- **Создайте Pull/Merge Request.** Добавьте в описание ссылку на release notes и краткий отчет о проведенном тестировании.
- **Запустите CI/CD пайплайн.** Если у вас настроена автоматическая сборка и прогон тестов, убедитесь, что они проходят в новой ветке.
- **Если время позволяет**, попросите коллегу сделать quick review изменений (фактически, только файла `build.gradle`).
- **Смерджите изменения** в основную ветку (main/master) и запустите сборку production-артефакта (APK/AAB).
Если в ходе часового тестирования обнаруживается критический баг, у вас есть варианты:
* **Откатиться.** Если проблема серьезная, а время поджима, проще откатить изменения и остаться на старой, работающей версии, пока не будет больше времени на анализ.
* **Быстрое точечное исправление.** Если проблема понятна (например, изменился signature метода), попробуйте исправить ее сразу, следуя официальной миграции. Но будьте осторожны — не создавайте больше проблем.
* **Отложить фичу.** Если обновление не связано с критической безопасностью, возможно, его можно запланировать на следующий спринт с полноценным тестированием.
Главный секрет успешного срочного обновления — не скорость рук, а скорость принятия обоснованных решений. Четкий план, фокус на рисках и приоритизация тестирования позволяют уложиться в жесткие сроки без компромиссов в качестве. Держите этот алгоритм наготове, и следующее срочное обновление Google Play Services не застанет вас врасплох.
Комментарии (11)