If you’ve recently submitted your app to the Play Store and got hit with two warnings about edge-to-edge display, you’re not alone. These warnings started appearing for apps targeting SDK 35 (Android 15), and a lot of developers were caught off guard.
The good news? Both issues are very fixable. This post walks you through exactly what these warnings mean, why Google made these changes, and how to properly fix them without breaking your existing app.
Table of Contents
What Are These Warnings Actually Saying?
Before jumping into the fix, let’s quickly understand what’s going on.
Warning 1: Edge-to-Edge May Not Display for All Users
“From Android 15, apps targeting SDK 35 will display edge-to-edge by default.”
In plain English — Android 15 forces your app to draw behind the system bars (status bar at the top and navigation bar at the bottom). Your app’s content will extend all the way to the edges of the screen, underneath those bars.
This is actually a good thing for users. It makes apps look more immersive and modern. But if your app isn’t prepared for it, your UI elements might get hidden behind the navigation bar or status bar.
Warning 2: Your App Uses Deprecated APIs
“android.view.Window.setNavigationBarDividerColor, setStatusBarColor, setNavigationBarColor have been deprecated in Android 15.”
These are the old ways of controlling the color of your status bar and navigation bar. Android 15 has deprecated them — meaning they still technically work for now, but you should migrate away from them because they’ll eventually stop working and they don’t play nicely with the new edge-to-edge behavior.
Why Did Google Make These Changes?
Before Android 15, apps would draw their content only in the area between the status bar and navigation bar. The system bars had their own background color, set by you via APIs like setStatusBarColor().
With Android 15 and SDK 35, Google enforced edge-to-edge as the default. Your content now draws behind the system bars. This means:
- You no longer need to set a color for the navigation bar or status bar — they’re transparent by default
- You do need to handle window insets so your content doesn’t accidentally sit behind those bars
- The old color-setting APIs are now pointless in this new model, so they’ve been deprecated
The Fix — Step by Step
There are two parts to the fix:
- Call
enableEdgeToEdge()to properly enable edge-to-edge with backward compatibility - Handle window insets so your content doesn’t get clipped by system bars
- Remove the deprecated API calls
Let’s go through each one.
Step 1: Call enableEdgeToEdge() in Your Activity
This is the most important step. You need to call this before setContentView() in your Activity’s onCreate().
Kotlin:
import androidx.activity.enableEdgeToEdge
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
enableEdgeToEdge() // Add this line BEFORE setContentView
setContentView(R.layout.activity_main)
}
}
Java:
import androidx.activity.EdgeToEdge;
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
EdgeToEdge.enable(this); // Add this line BEFORE setContentView
setContentView(R.layout.activity_main);
}
}
Important: Make sure you have
androidx.activity:activityversion 1.8.0 or higher in yourbuild.gradleforenableEdgeToEdge()to be available.
dependencies {
implementation "androidx.activity:activity-ktx:1.9.0" // Kotlin
// or
implementation "androidx.activity:activity:1.9.0" // Java
}
What does enableEdgeToEdge() actually do? It sets up your window to draw behind the system bars, makes the status bar and navigation bar transparent, and handles light/dark mode for the system bar icons automatically. It also handles backward compatibility, so it works correctly on older Android versions too.
Step 2: Handle Window Insets So Nothing Gets Hidden
Once edge-to-edge is enabled, your content extends behind the system bars. That’s great visually, but you don’t want your buttons or important text sitting right behind the navigation bar where users can’t see or tap them.
You fix this by applying window insets to your root layout or the specific views that need padding.
The modern way — using ViewCompat.setOnApplyWindowInsetsListener():
Kotlin:
import androidx.core.view.ViewCompat
import androidx.core.view.WindowInsetsCompat
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
enableEdgeToEdge()
setContentView(R.layout.activity_main)
val mainView = findViewById<View>(R.id.main) // your root layout view
ViewCompat.setOnApplyWindowInsetsListener(mainView) { view, insets ->
val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
view.setPadding(
systemBars.left,
systemBars.top,
systemBars.right,
systemBars.bottom
)
insets
}
}
Java:
import androidx.core.view.ViewCompat;
import androidx.core.view.WindowInsetsCompat;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
EdgeToEdge.enable(this);
setContentView(R.layout.activity_main);
View mainView = findViewById(R.id.main);
ViewCompat.setOnApplyWindowInsetsListener(mainView, (view, insets) -> {
Insets systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars());
view.setPadding(
systemBars.left,
systemBars.top,
systemBars.right,
systemBars.bottom
);
return insets;
});
}
This code listens for the actual inset values from the system and applies them as padding to your root view. Your content stays safely inside the visible area while the background still extends beautifully behind the system bars.
Your root layout in XML (make sure it has the id main or whatever you reference):
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/main"
android:layout_width="match_parent"
android:layout_height="match_parent">
<!-- your content here -->
</androidx.constraintlayout.widget.ConstraintLayout>
Step 3: Remove the Deprecated API Calls
The warnings specifically mention these three methods:
android.view.Window.setNavigationBarDividerColor
android.view.Window.setStatusBarColor
android.view.Window.setNavigationBarColor
Search your project for all usages of these and remove them. Here’s what to look for:
// DELETE these — they are deprecated and no longer needed
window.statusBarColor = Color.BLACK
window.navigationBarColor = Color.WHITE
window.navigationBarDividerColor = Color.GRAY
// DELETE these — they are deprecated and no longer needed
getWindow().setStatusBarColor(Color.BLACK);
getWindow().setNavigationBarColor(Color.WHITE);
getWindow().setNavigationBarDividerColor(Color.GRAY);
When you call enableEdgeToEdge(), the system bars become transparent and adapt to your app’s theme automatically. You don’t need to manually set their colors anymore. The whole point of edge-to-edge is that your content is what you see behind the bars, not a solid color block.
What If You Set Status Bar Colors for a Reason?
Some developers set the status bar color intentionally — for branding purposes or to match their app’s toolbar. In the edge-to-edge world, here’s how to think about this:
Instead of coloring the status bar, extend your toolbar’s background color to fill that space. Since your content now draws behind the status bar, if your toolbar has a blue background, it will naturally bleed up into the status bar area — which is often exactly the effect you want.
If you need to handle status bar icon colors (dark icons on a light background or vice versa), enableEdgeToEdge() handles this automatically based on your app theme. But you can also control it manually:
Kotlin:
// Force light icons (for dark backgrounds)
WindowCompat.getInsetsController(window, window.decorView)
.isAppearanceLightStatusBars = false
// Force dark icons (for light backgrounds)
WindowCompat.getInsetsController(window, window.decorView)
.isAppearanceLightStatusBars = true
What About Apps Using Jetpack Compose?
If your app uses Compose, the approach is similar but even cleaner.
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
enableEdgeToEdge()
setContent {
MyAppTheme {
Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
// innerPadding already includes the system bar insets
MainScreen(modifier = Modifier.padding(innerPadding))
}
}
}
}
}
Compose’s Scaffold component handles the insets automatically when you use innerPadding. Just pass that padding modifier to your main content composable and you’re done.
For individual composables that need inset awareness outside of Scaffold:
import androidx.compose.foundation.layout.WindowInsets
import androidx.compose.foundation.layout.safeDrawingPadding
Box(
modifier = Modifier
.fillMaxSize()
.safeDrawingPadding() // handles status + navigation bar insets
) {
// your content
}
Quick Summary of What You Need to Do
Here’s a no-fluff checklist to fix both warnings:
- [ ] Update
androidx.activitydependency to version 1.8.0 or higher - [ ] Call
enableEdgeToEdge()(Kotlin) orEdgeToEdge.enable(this)(Java) at the top ofonCreate(), beforesetContentView() - [ ] Apply window insets using
ViewCompat.setOnApplyWindowInsetsListener()on your root view - [ ] Search the entire project for
setStatusBarColor,setNavigationBarColor, andsetNavigationBarDividerColorand delete all usages - [ ] Test your app on an Android 15 emulator or device to confirm everything looks correct
- [ ] Also test on an older Android version (Android 10–13) to make sure the backward compatibility works fine
Common Mistakes to Avoid
Don’t call enableEdgeToEdge() after setContentView(). It needs to run before the layout is inflated. If you call it after, you might see flickering or incorrect behavior.
Don’t forget to test on older devices. enableEdgeToEdge() handles backward compatibility, but always verify on older API levels. Things like gesture navigation vs. 3-button navigation behave slightly differently.
Don’t apply insets to every view — just the root. Applying insets padding to the root view is usually enough. If you apply it to nested views too, you’ll end up with double padding.
Don’t panic about the obfuscated class names in the warning. The Play Console warning mentions classes like c1.P.n and n2.d.onCreate. These are obfuscated class names from ProGuard/R8. They refer to your own code — use the Play Console’s deobfuscation mapping file, or just search your whole project for usages of the three deprecated methods and you’ll find them.
Final Thoughts
The move to edge-to-edge is genuinely a step forward for Android UI. Apps look more polished and modern when content flows behind the system bars instead of being boxed in by colored blocks. The transition requires a little upfront work, but once you’ve done it, you’ll probably wonder why you weren’t doing it this way all along.
The two-step fix is straightforward: add enableEdgeToEdge(), handle your insets, and delete the old deprecated color calls. That’s really all there is to it.
If your app has multiple Activities, you’ll need to apply this to each one — or better yet, create a base Activity class that handles it once, and have all your Activities extend from that.
Good luck with the update, and happy coding. 🚀
Have questions or ran into a specific edge case? Drop a comment below — happy to help.
Other Resource: