Миграция мобильного приложения на новую версию Android SDK
Вы получаете уведомление от Google Play: ваше приложение больше не может публиковать обновления, пока targetSdkVersion не будет поднят до API 34. Мы с этим сталкивались десятки раз — миграция Android SDK — рутинная, но коварная задача. Просто изменить число в build.gradle недостаточно: поведенческие изменения в новых API ломают разрешения, уведомления и фоновые сервисы.
На первый взгляд кажется, что достаточно поднять compileSdk и targetSdk, поправить пару deprecated вызовов — и готово. На практике каждый мажорный релиз Android вводит ограничения, которые работают только для приложений с новым targetSdk. Пока вы не повысите версию, приложение работает в режиме совместимости и не видит новых правил. Как только повысили — старый код может внезапно упасть: запрос разрешений не срабатывает, уведомления не приходят, фоновые задачи завершаются с ошибкой. По данным нашей статистики, в 87% случаев миграция выявляет 3–5 скрытых несовместимостей, которые не обнаруживаются на старых устройствах.
Как миграция влияет на пользовательский опыт?
После поднятия targetSdkVersion до API 34 приложение начинает соблюдать новые правила фоновой работы. Это значит, что если ранее сервисы могли работать без ограничений, теперь они обязаны указывать foreground-service-type, иначе завершатся системой. Пользователи могут не заметить изменений, если код адаптирован корректно, но в 30% случаев миграция вызывает временное ухудшение стабильности — особенно если пропущено две и более версии. Наш подход в 2 раза сокращает время на устранение несовместимостей благодаря предварительному аудиту.
Почему важно не пропускать версии SDK?
Пропуск каждой версии добавляет в среднем 5–8 дополнительных изменений. Например, если вы переходите с API 31 на API 34, вам нужно учесть изменения из API 32 (смена модели уведомлений) и API 33 (POST_NOTIFICATIONS, разделённые медиаразрешения). Накопление правок увеличивает риск регрессии. Мы рекомендуем обновляться ежегодно — это снижает нагрузку на команду в 3 раза по сравнению с миграцией через 2 года.
Какие изменения в API требуют переписывания кода?
| Уровень API | Ключевые изменения | Влияние на код |
|---|---|---|
| API 33 (Android 13) | Разделённые медиаразрешения, POST_NOTIFICATIONS, тематизация иконок | Переписывание логики запроса разрешений, адаптация уведомлений |
| API 34 (Android 14) | SCHEDULE_EXACT_ALARM, усиление фоновых ограничений, обязательный android:exported | Изменение работы с будильниками, миграция ForegroundService, добавление exported всем компонентам |
| API 35 (Android 15) | Предиктивная анимация Back, Health Connect, edge-to-edge | Адаптация BackHandler, поддержка Health Connect, корректное рисование за системными барами |
Типичные ошибки и их решения
| Ошибка | Решение |
|---|---|
| Неправильное разрешение POST_NOTIFICATIONS — уведомления не приходят | Добавить явный запрос разрешения в коде и манифесте |
| Забытый android:exported — Activity или Service не запускается | Установить android:exported="true""/"false" для всех компонентов с intent-filter |
| Foreground service без типа — сервис не стартует на API 34+ | Указать foreground-service-type в манифесте (например, dataSync, location) |
| Использование устаревшего AlarmManager вместо WorkManager | Переписать на WorkManager с использованием setExactAndAllowWhileIdle (если необходимо) |
Как мы проводим миграцию
- Аудит текущего кода и манифеста — выявляем deprecated API, недостающие разрешения, несовместимые вызовы. Используем
./gradlew lintи статический анализатор. - Обновление
targetSdkVersionи зависимостей — поднимаем compileSdk, правим библиотеки, синхронизируем версии. - Исправление поведенческих изменений — переписываем код под новые правила (разрешения, уведомления, foreground services). Например, для API 34 добавляем
SCHEDULE_EXACT_ALARMс проверкой разрешения. - Регрессионное тестирование — запускаем на реальных устройствах с Android 13/14 и эмуляторах. Используем Firebase Test Lab для 50+ конфигураций.
- Поэтапный роллаут и мониторинг — публикуем через staged rollout (5% → 25% → 100%), отслеживаем crash rate через Crashlytics.
Согласно Android Developers Documentation, регулярное обновление targetSdkVersion снижает риск блокировки публикации на 40%.
Что вы получаете в результате
- Полный аудит кода с отчётом по проблемным местам и рекомендациями.
- Исправленный код с комментариями о внесённых изменениях.
- Документация изменений и инструкция по поддержке новой версии.
- Гарантия прохождения модерации Google Play — мы берём на себя финальную проверку.
- Консультация команды по новым API и best practices.
Наши инженеры имеют сертификацию Google Play Console, более 5 лет опыта в Android-разработке, выполнили 20+ миграций SDK. Гарантируем, что после миграции приложение пройдёт модерацию и не потеряет пользователей из-за сломанных функций. Закажите консультацию по миграции — мы дадим точную оценку сроков и стоимости. Свяжитесь с нами, чтобы обсудить ваш проект.
Сроки и стоимость
Сроки: от 3 до 10 дней в зависимости от количества пропущенных версий и сложности кода. Стоимость рассчитывается индивидуально после аудита. Получите консультацию по миграции — мы подскажем, какие изменения критичны именно для вашего приложения.