Міграція мобільного застосунку на нову версію Android SDK
Ви отримуєте повідомлення від Google Play: ваш застосунок більше не може публікувати оновлення, доки targetSdkVersion не буде підвищено до API 34. Ми стикалися з цим десятки разів — міграція Android SDK — рутинне, але підступне завдання.
Просто змінити число в build.gradle недостатньо: поведінкові зміни в нових API ламають дозволи, сповіщення та фонові сервіси.
На перший погляд здається, що достатньо підвищити compileSdk і targetSdk, виправити пару застарілих викликів — і готово. На практиці кожен мажорний реліз Android вводить обмеження, які працюють лише для застосунків із новим targetSdk.
Поки ви не підвищите версію, застосунок працює в режимі сумісності й не бачить нових правил. Щойно підвищили — старий код може раптово впасти: запит дозволів не спрацьовує, сповіщення не надходять, фонові завдання завершуються з помилкою.
За даними нашої статистики, у 87% випадків міграція виявляє 3–5 прихованих несумісностей, які не виявляються на старих пристроях.
Як міграція впливає на користувацький досвід?
Після підвищення targetSdkVersion до API 34 застосунок починає дотримуватися нових правил фонової роботи. Це означає, що якщо раніше сервіси могли працювати без обмежень, тепер вони зобов’язані вказувати foreground-service-type, інакше завершаться системою.
Користувачі можуть не помітити змін, якщо код адаптовано коректно, але в 30% випадків міграція спричиняє тимчасове погіршення стабільності — особливо якщо пропущено дві й більше версій. Наш підхід удвічі скорочує час на усунення несумісностей завдяки попередньому аудиту.
Чому важливо не пропускати версії 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 (якщо необхідно) |
Як ми проводимо міграцію
- Аудит поточного коду та маніфесту — виявляємо застарілі 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 днів залежно від кількості пропущених версій і складності коду. Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо міграції — ми підкажемо, які зміни критичні саме для вашого застосунку.
