Android 15 upgrade diary: Target SDK 35 migration challenges

Note for the skeptics: I know Android 16 is coming soon, but it’s not too late to talk about Android 15. In real world production apps especially large ones upgrades don’t happen instantly. Stability, library support, and user adoption all take time. If you’re just now targeting SDK 35, you’re not behind you’re being practical.

When Google releases a new Android version, it’s always an exciting (and sometimes nerve-wracking) time for developers. I recently upgraded both the targetSdkVersion and compileSdkVersion from API level 34(Android 14) to API level 35(Android 15) and in this blog post, I’ll walk through my experience the good, the frustrating, and the things I wish I knew earlier.

Why we need to upgrade?

As a developer, staying on top of the latest OS versions is important to:

Ensure app compatibility
Take advantage of new APIs and system behaviors
Prepare for future user adoption
If you don’t update later Google will force to you upgrade otherwise you will not publish new version of your app

Upgrade Process

Environment Setup

Installed Android studio Hedgehog (depending on your version)
Updated SDKs and tools
Installed Android 15 system

App Migration

Updated the SDK versions to 35 (targetSdkVersion and compileSdkVersion)
Updated dependencies and libraries to ensure compatibility

Behavioral Changes

Some permissions and background task behaviors changed. For example:

New foreground service limitations
Foreground service limit: dataSync and mediaProcessing services can run only 6 hours per day
Timeout behavior: System throws exception if onTimeout() doesn't call stopSelf()
BOOT_COMPLETED change: Apps can’t auto-start certain foreground services on boot
Overlay requirement: Starting a foreground service from background now needs a visible overlay

Challenges I Faced

Everything was going smoothly until I encountered an issue where the toolbar was overlapping the status bar

To fix this you can add the following in your res/values-v35/themes.xml file:

<item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>

Another options is the fix is slightly different. You need to call enableEdgeToEdge() inside your activity onCreate(), and make sure it's called before setContentView or setContent {}.

At first, I was relieved the issue seemed fixed. But a few days later, our QA team noticed a strange bug, on Pixel devices running Android 15, the status bar was still overlapping the toolbar.

What made this even more confusing was that the issue only occurred on Pixel phones. Other manufacturers handled the UI correctly, which was surprising you’d expect either all devices to break or none at all.

I started deep-diving Googling, combing through StackOverflow, and checking official documentation. But I came up empty, it felt like I was the first developer in the world to face this specific bug.

Eventually, after hours of debugging and experimentation, I discovered the root cause the fix needed to be applied specifically for night mode too. Adding the same theme override in res/values-night-v35/themes.xml finally resolved the issue on Pixel devices.

To ensure consistency across Pixel and other devices, and across both light and dark modes, I added the same theme override in:

res/values-v35/themes.xml
res/values-night-v35/themes.xml

This resolved the overlapping issue across all configurations finally.

Lessons learned

Always read official behavior change documentation skimming the release notes isn’t enough. Some subtle changes (like windowOptOutEdgeToEdgeEnforcement) can easily break your UI without obvious clues
Don’t assume one fix fits all modes and manufacturers just because it works in light mode or on one device doesn’t mean you’re done. Night mode and Pixel-specific behaviors may introduce unique quirks
Test across multiple device brands and system configurations
Pixel devices often adopt platform changes more strictly always include them in your QA matrix
Apply fixes for both light and night configurations
If you’re using values-v35 make sure to mirror it in values-night-v35 unless you're absolutely sure it’s not needed
Start with dependency upgrades before bumping the target SDK
updating your libraries first helps identify compatibility issues early and can save hours of debugging

Final Thoughts

Upgrading from Android 14 to 15 was more than just bumping a version number it required deep understanding of platform changes, behavior quirks, and device-specific inconsistencies.

These types of edge cases remind us why testing, documentation reading, and staying updated with community feedback are essential parts of professional Android development. While frustrating at times, tackling these challenges is also what makes us better engineers.