Findings on edge to edge support

[subhajitxyz]

Notes

• Device: motorola edge 60 fusion
• Android Version: 16
• Issue: UI overlapping with status bar and navigation bar across multiple screens.

Overlapping Issue Screenshots (Status Bar & Navigation Bar)

Below screenshots describes about the overlapping issue. (Although almost every screen has this ovelapping issue on status bar and navigation bar, but i have shared few.)

Issue

• Screen 1: Toolbar is overlapping with status bar and extra space appears between toolbar and content.

• Screen 2: some extra space appears between toolbar and content. but hint is not overlapping with nav bar (Because in state_fragment this framelayout already applied fitssystemwindow = true, that is why, hint is not overlapping but some extra space appear in top. which works on lower devices, but it is not working on version 16. I think that is why android suggest to use windowInsets instead of fitystemwindow.)

• Screen 3: welcome screen overlaps with navigation bar which makes hard to use the options(like skip, arrow)

• Scree 4: Toolbar is overlapping with status bar and navigation bar. At top right corner, the Three dot option overlaps with nav bar.

1	2

3	4

[subhajitxyz]

Try 1

Tried to Implement support for edge to edge on Exploration Activity

I used WindowInsetsListener

ExplorationActivity

val toolbar = findViewById<Toolbar>(R.id.exploration_toolbar)
    ViewCompat.setOnApplyWindowInsetsListener(toolbar) { view, insets ->
      val vInsets = insets.getInsets(
        WindowInsetsCompat.Type.systemBars() or
          WindowInsetsCompat.Type.displayCutout()
      )

      view.updatePadding(top = vInsets.top, left = vInsets.left, right = vInsets.right)
      insets
    }

StateFragmentPresenter

val hintview = binding.animableHintsAndSolutionFragmentContainer
    ViewCompat.setOnApplyWindowInsetsListener(hintview) { view, insets ->
      val vInset = insets.getInsets(
        WindowInsetsCompat.Type.systemBars() or
          WindowInsetsCompat.Type.displayCutout()
      )
      view.updatePadding(left = vInset.left, right = vInset.right, bottom = vInset.bottom)
      insets
    }

• Used padding in top, left, right to toolbar
• remove fitsystemwindow = true from state_fragment to remove extra space between toolbar and content (See screenshot 1, 3 on above body)
• Used padding on specifically on animable_hints_and_solution_fragment_container (although there are views like congratulations_text_view)

Output

• padding applied on top (works good. I have in display camera . That is why the top padding looks bigger in screenshots )
• extra space between toolbar and content is removed.
• padding applied for animable_hints_and_solution_fragment_container (But the navigation bar is translucent and light color, and content is drawn behind it, which looks odd)

ScreenShots

1	2

[subhajitxyz]

Try 2

ExploratonActivity

val toolbar = findViewById<Toolbar>(R.id.exploration_toolbar)
    ViewCompat.setOnApplyWindowInsetsListener(toolbar) { view, insets ->
      val vInsets = insets.getInsets(
        WindowInsetsCompat.Type.systemBars() or
          WindowInsetsCompat.Type.displayCutout()
      )

      view.updatePadding(top = vInsets.top, left = vInsets.left, right = vInsets.right)
      insets
    }
    
    // By default, on android version 16, nav bar is translucent and window.isNavigationBarContrastEnforced = true. So android adjusts contrast of nav bar based on background color.
    // but we use light theme for this activity, and our background is not properly dark on dark mode. so nav bar by default appears translucent light color for both light and dark mode.
    
     // So I used this window.isNavigationBarContrastEnforced = false
    // Note: It makes nav bar transparent and restrict android to adjust contrast of nav bar based on background color.
    // Since we are making nav bar transparent. So, we need to give bottom padding to a layout which have color for light and dark mode. (Like I do in state_fragment's framelayout and it works good.) 

    window.isNavigationBarContrastEnforced = false
    

state_fragment
Removed fitsSystemWindow = true

StateFragmentPresenter

val rootView = binding.rootStateLayout
    ViewCompat.setOnApplyWindowInsetsListener(rootView) { view, insets ->
      val vInset = insets.getInsets(
        WindowInsetsCompat.Type.systemBars() or
        WindowInsetsCompat.Type.displayCutout()
      )

      view.updatePadding(left = vInset.left, right = vInset.right, bottom = vInset.bottom)
      insets
    }

Output ScreenShot:

Android Version: 16

1	2

3	4

Output ScreenShot:

Android Version: 11

1	2

3	4

### Output

• padding applied on top, (works good. I have in display camera . That is why the top padding looks bigger in screenshots ) padding is applied on left and right also (so that toolbar does not overlap in landscape mode)
• extra space between toolbar and content is removed.
• padding applied on layout of state_fragment

Reason: Since we are making nav bar transparent. So, we need to give bottom padding to a layout which has color for light and dark mode. (Like I do in state_fragment's framelayout and it works good.)
Otherwise, if we give padding on rootlayout which does not have any color. so, transparent nav bar appears light color because there is not background color and we have light theme for activity.

Hi @BenHenning , @adhiamboperes , I have tried to solve overlapping problem in status bar and nav bar on android 16. (Although I have not tried to color the status bar like currently we have). Please Share your thoughts!
Hi @Neer-rn , I tried implementing this specifically in the Exploration Activity. I hope it helps!

[Neer-rn]

Hi @subhajitxyz,

Thanks a lot for doing this! I have been working on this issue and I actually posted my findings on #5943 too and honestly our approaches are pretty similar which makes me more confident that we're on the right track.

In my investigation I also found that fitsSystemWindows="true" everywhere (like I did in PR #6117) was the wrong approach, it behaves differently on different views and causes all sorts of problems. I also tried ViewCompat.setOnApplyWindowInsetsListener() and it worked well for the toolbar part.

Two things from your testing that are really helpful for me:

1. The bottom navigation bar handling, I hadn't tested that part yet. The isNavigationBarContrastEnforced = false thing is a good find, I will look into this more.
2. The backward compatibility testing on Android 11 I only tested on API 35 emulator so knowing it works on older versions too is really valuable.

In the meeting we discussed the next steps introducing a feature flag, breaking the work into smaller tasks, adding CI scripts, and making a wiki page. I'm going to post a detailed breakdown on #5943 soon.

I will take a deeper look into the bottom nav bar part based on your findings and will keep you updated on what I find. Thanks again for testing, that really helps!

[subhajitxyz]

One more thing:

• On SDK ≥ 35, edge-to-edge is enabled by default.
• On SDK < 35, edge-to-edge is not enabled by default. To enable it, we need to call enableEdgeToEdge().
  According to the Android documentation, enableEdgeToEdge() was added in AndroidX Core/Core-KTX version 1.17.0.

However, in the Oppia codebase (maven_install.json), the current versions are:

androidx.core:core-ktx → 1.1.0  
androidx.core:core     → 1.7.0

So, enableEdgeToEdge() is not available with the current dependency versions.

[Neer-rn]

Ohhh you are right about the versions, I originally only checking versions.bzl which shows 1.0.1 but the actual resolved version is 1.7.0 in maven_install.json because of transitive deps. Thanks for catching that! And yeah enableEdgeToEdge() is not available. But I think it should be fine for now because edge-to-edge is automatic on SDK 35+ anyway and that's where we actually need the inset handling to work. I will keep this in mind going forward though, thanks!

[BenHenning]

The 1.7.0 bit is going to be a bother for us. My assumption was that we could use enableEdgeToEdge as the main thing we gate with the feature flag but it seems that won't actually be possible. @Neer-rn or @subhajitxyz so you have a sense for how much of this work will be done in Kotlin vs. XML? If all or most of it is being done in Kotlin then we can proceed with a feature flag fairly easily I think, but anything in XML is possibly going to be much trickier with a feature flag.

[Neer-rn]

@BenHenning,

So I went through the codebase to check the Kotlin vs XML split for this.

Most of the work is actually Kotlin:

• Drawer-based screens (Home, ClassroomList, Options, Help) use a plain Toolbar without AppBarLayout → fix is ViewCompat.setOnApplyWindowInsetsListener() on the toolbar
• Screens without any toolbar (splash, onboarding, profile chooser, intro) → ViewCompat on root view
• Bottom inset handling → ViewCompat + isNavigationBarContrastEnforced = false
• StatusBarColor.statusBarColorUpdate() replacement (6 presenters using the deprecated window.statusBarColor)

All of this is pure Kotlin so it can be gated by the feature flag easily.

The XML part is 38 layouts that have AppBarLayout the fix there is adding fitsSystemWindows="true" + darker background color on the AppBarLayout. For these we could either apply the XML changes unconditionally or go ViewCompat for those screens too so everything stays behind the flag.

Both me and @subhajitxyz have already tested the pure ViewCompat (Kotlin-only) approach, and it works without any XML changes. So if we go ViewCompat everywhere, the feature flag can gate everything cleanly.

And yeah we don't actually need enableEdgeToEdge() since edge-to-edge is automatic on SDK 35+ anyway. The flag would just control whether our inset-handling code runs.

I am thinking of going forward with the Kotlin-only approach so that everything stays behind the feature flag and if any issue comes up the flag can take care of it. Should I continue with this approach as I am currently working and writing code taking this approach only.

[subhajitxyz]

Since we currently can’t use enableEdgeToEdge(), but there is a workaround mentioned in android documentation: manually enabling edge-to-edge using WindowCompat.setDecorFitsSystemWindows(window, false).
However, in that case, we need to ensure that we handle insets ourselves (such as applying padding for system bars and IME padding). (Edit: Added in Api 30 and deprecated in api 35)

I was thinking about what the expected behavior should be after feature flag gating.
Currently, we are using:

• values/themes for API < 35
• values-v35/themes for API ≥ 35

How should we implement this?

Option 1

• If the feature is on → Enable edge-to-edge for all devices and handle insets manually, overriding the theme behavior.
• If the feature is off → Fall back to the theme-based approach.

Option 2

• If the feature is on → Devices < 35 continue using themes as they are. Devices ≥ 35 use manual edge-to-edge with insets handling, overriding values-v35/themes
• If the feature is off →Devices ≥ 35 fall back to values-v35/themes

@BenHenning I agree with @Neer-rn that most of the work can be done in kotlin. so we can use feature flag.

[BenHenning]

Thanks both, that's very helpful. Let's do pure Kotlin for now so that everything can be safely gated behind a feature flag, and then we can consider what to move to XML once the feature is actually finalized and ready to go.

@subhajitxyz how hard do you think it will be to maintain to versions of the layouts? That would be my main concern, but if managing insets is more challenging then that's probably the best approach. I want to limit how much duplication we need to do here where possible, so I was assuming we'd either de facto launch edge-to-edge support for pre API 35 users or the extra code to make our layouts work on 35+ with edge-to-edge is relatively small and something we can maintain. Until I see actual code I can't be sure of either, though.