Міграція мобільного додатку на нову версію 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 днів залежно від кількості пропущених версій та складності коду. Вартість розраховується індивідуально після аудиту. Отримайте консультацію з міграції — ми підкажемо, які зміни критичні саме для вашого додатку.