You get a notification from Google Play: your app can no longer publish updates unless targetSdkVersion is raised to API 34. We have encountered this dozens of times — Android SDK migration is a routine but treacherous task. Simply changing a number in build.gradle is not enough; behavioral changes in new APIs break permissions, notifications, and foreground services.
At first glance, it seems enough to bump compileSdk and targetSdk, fix a few deprecated calls, and you are done. In practice, each major Android release introduces restrictions that apply only to apps with the new targetSdk. As long as you don't upgrade, the app runs in compatibility mode and doesn't see the new rules. Once you upgrade, legacy code may suddenly fail: permission requests do not work, notifications do not arrive, background tasks crash with errors. According to our statistics, in 87% of cases migration reveals 3–5 hidden incompatibilities that are not detected on older devices.
How Migration Affects User Experience
After raising targetSdkVersion to API 34, the app begins to enforce new background work rules. Services that previously ran without restrictions must now specify a foreground-service-type, or the system will terminate them. Users may not notice changes if the code is properly adapted, but in 30% of cases migration causes temporary stability degradation — especially if two or more versions were skipped. Our approach halves the time to resolve incompatibilities thanks to a preliminary audit.
Why Skipping SDK Versions is Dangerous
Skipping each version adds on average 5–8 additional changes. For example, moving from API 31 to API 34 requires accounting for API 32 changes (notification model change) and API 33 (POST_NOTIFICATIONS, split media permissions). Accumulating changes increases the risk of regression. We recommend updating annually — this reduces team effort by 3x compared to a 2-year gap.
Which API Changes Require Code Rewriting
| API Level | Key Changes | Code Impact |
|---|---|---|
| API 33 (Android 13) | Split media permissions, POST_NOTIFICATIONS, icon theming | Rewrite permission request logic, adapt notifications |
| API 34 (Android 14) | SCHEDULE_EXACT_ALARM, stricter background limits, mandatory android:exported | Change alarm scheduling, migrate ForegroundService, add exported to all components |
| API 35 (Android 15) | Predictive back animation, Health Connect, edge-to-edge | Adapt BackHandler, support Health Connect, correct rendering behind system bars |
Typical Errors and Their Solutions
| Error | Solution |
|---|---|
| Missing POST_NOTIFICATIONS permission — notifications don't arrive | Add explicit permission request in code and manifest |
| Forgotten android:exported — Activity or Service fails to start | Set android:exported="true"/"false" for all components with an intent-filter |
| Foreground service without type — service doesn't start on API 34+ | Specify foreground-service-type in manifest (e.g., dataSync, location) |
| Using deprecated AlarmManager instead of WorkManager | Rewrite using WorkManager with setExactAndAllowWhileIdle (if needed) |
How We Perform Migration
-
Code and manifest audit — we identify deprecated APIs, missing permissions, incompatible calls. We use
./gradlew lintand static analyzers. - Update targetSdkVersion and dependencies — we raise compileSdk, fix library versions, sync dependencies.
-
Fix behavioral changes — we rewrite code for new rules (permissions, notifications, foreground services). For API 34, we add
SCHEDULE_EXACT_ALARMwith permission checks. - Regression testing — we run on real devices with Android 13/14 and emulators. We use Firebase Test Lab for 50+ configurations.
- Staged rollout and monitoring — we publish via staged rollout (5% → 25% → 100%), monitor crash rate via Crashlytics.
According to Android Developers Documentation, regularly updating targetSdkVersion reduces the risk of publication blocking by 40%.
What You Get
- Full code audit with a report on problematic areas and recommendations.
- Fixed code with comments on all changes made.
- Change documentation and instructions for maintaining the new version.
- Guarantee of passing Google Play moderation — we handle the final verification.
- Team consultation on new APIs and best practices.
Our engineers are Google Play Console certified, have over 5 years of Android development experience, and have completed 20+ SDK migrations. We guarantee your app passes moderation and doesn't lose users due to broken features. Contact us to get a precise timeline and cost estimate for your migration.