Add full support for edge-to-edge

[Luna712]

This is required for targetSdk 36, so it is also in preparation for that.

A side effect of doing this fixes many layout bugs such as:

• In player in full screen dialogs, there is a space that still shows the player on the side. Full screen dialogs are now properly full screen.
• In provider tests, you could scroll down outside of the recycler (the whole page) but couldn't scroll back up without going back and back in. You can still scroll down but it doesn't get stuck.
• Navigation bar on setup screens now blend perfectly with the setup background color.
• Navigation and status bars now blend perfectly with the full screen dialogs in player so it doesn't just look inconsistent and odd.
• Navigation and status bars are always transparent by default and auto adjust to whatever fragment they are in. Which is why background color was moved around in layouts as the navigation and status bars use the layout root view background color so to give it a more consistent look, color was moved around so the main background color is the same as the in-app navigation views, while the actual fragment bodies use the other color to make the layout appear just how it was before.
• Fixes system navigation bar for light layouts, currently they are basically very hard and very poor contrast and visibility on light themes.
• Subtitle settings in player properly blends with navigation and status bars and uses a consistent theme with the rest of the in-player dialogs.
• The back arrow and title for the current settings fragment are now properly aligned, before they were not quite aligned, albeit not to far off but noticeable.

This also fixes immersive mode to use the modern method, the commented out was just wrong and unreliable but this uses a more reliable (and modern) method that is more compatible with edge-to-edge.

This also adds compat methods, setNavigationBarColorCompat, and enableEdgeToEdgeCompat to reduce code duplication and properly maintain compatability on very low APIs that edge-to-edge doesnt support, or is very buggy (technically Android 10 supports it but it is very buggy so we only enable on Android 11+). navigationBarColor no longer does anything at all when using edge-to-edge, so just to future proof it and to maintain consistency and reduce the likelihood of random odd bugs, we don't use it when using edge-to-edge. Technically the same goes for android:navigationBarColor and android:statusBarColor in styles.xml but it should be okay and can leave those for now.

For the cutout, it honors the camera cutout setting in Android settings in some devices, if thats set to auto or hidden it pads it and then draws a black overlay to make design look consistent and appear as if the screen ends at that point. When that setting is set to show, it doesn't draw the black bar nor pad because in that case it makes the system think there is no cutout and thus WindowInsetsCompat.Type.displayCutout returns nothing, which is what all that logic bases on for compatability accross all devices and API levels.

This also properly handles RTL support so the layout doesn't get very odd on RTL languages.

[Luna712]

I think this is now ready for review. I've done extremely extensive testing on practically every single supported API level and it seems to work fine. But there is always a good chance I missed something.

[fire-light42]

Could you perhaps split this into two pull requests, one for targetSdk and one for edge-to-edge. That way we can first merge edge-to-edge and then merge targetSdk later. By doing this we can test out edge-to-edge on the pre-release group first, without all the small changes of changing the targetSdk.

[Luna712]

Could you perhaps split this into two pull requests, one for targetSdk and one for edge-to-edge. That way we can first merge edge-to-edge and then merge targetSdk later. By doing this we can test out edge-to-edge on the pre-release group first, without all the small changes of changing the targetSdk.

Sure, good point. I did it like this only because bumping to 36 (original intent of this PR) required edge-to-edge support. I'll switch it back to 35 for now.

[Luna712]

@fire-light42 now switched back to 35. I'll do another PR later to bump to targetSdk 36. I kept manifestPlaceholders here even though its now unrelated because its useful to just have anyway.

[fire-light42]

Code looks good, will test later 👍

[fire-light42]

Everything looks good. Unfortunately it does not handle the notch correctly on phones with a notch. Please check the behavior with a notch in both versions (eg on landscape mode). If you do not have a notch on your device there is a software notch in developer settings.

[Luna712]

Everything looks good. Unfortunately it does not handle the notch correctly on phones with a notch. Please check the behavior with a notch in both versions (eg on landscape mode). If you do not have a notch on your device there is a software notch in developer settings.

Whoops, yes I did forget to handle WindowInsetsCompat.Type.displayCutout() which I think is what that is. My bad. Working on a fix. Thanks!

[Luna712]

Everything looks good. Unfortunately it does not handle the notch correctly on phones with a notch. Please check the behavior with a notch in both versions (eg on landscape mode). If you do not have a notch on your device there is a software notch in developer settings.

Ive added display cutout support. I had to end up drawing an overlay for it so that it doesn't look horrible by making the cutout background the same as the default fragment background which was a bit tricky. Hopefully I did it okay, if not I apologize.

[Luna712]

I also found and fixed another bug where using RTL layout totally messed it up. But thats also now fixed.

[Luna712]

I found and fixed one more bug with this when in chromecast or main subtitle settings, and the subtitle dialog in player so that the system bars properly blend, as it was kinda messed up before. But I think that really should be it for this lol. Hopefully anyway.

[fire-light42]

Very good pull request. However when testing I found two major bugs.

1. Subtitle settings in the player does not look the same as in the settings:

I have no idea how or why given that they use the same xml. I tested building both debug, and a stable app apk, and both had this issue. Might be OS issues?

2. When using emulator on a phone, if you go back from an episode the navigation bars will not show up until you rotate your phone, making it unnecessarily hard to navigate. This should be fixed if you do not have a very good reason for this new behavior.

Note that this is not an exhaustive list given that I only did cursory testing. More changes may be requested after you fix these.

[Luna712]

Very good pull request. However when testing I found two major bugs.

1. Subtitle settings in the player does not look the same as in the settings:

I have no idea how or why given that they use the same xml. I tested building both debug, and a stable app apk, and both had this issue. Might be OS issues?

2. When using emulator on a phone, if you go back from an episode the navigation bars will not show up until you rotate your phone, making it unnecessarily hard to navigate. This should be fixed if you do not have a very good reason for this new behavior.

Note that this is not an exhaustive list given that I only did cursory testing. More changes may be requested after you fix these.

@fire-light42

The first issue is fixed, the second I could not reliably reproduce but in theory should also be fixed. I also fixed numerous issues including padding issues for older that have the navigation bar on the bottom, even in landscape mode, among a few other fixes like status bar on light themes etc...

[Luna712]

I have no idea how or why given that they use the same xml. I tested building both debug, and a stable app apk, and both had this issue. Might be OS issues?

BTW, Just to answer this, this was caused by Theme.AppCompat.Dialog.Alert overriding some styles, to fix this, and to future proof it, I created a new DialogFullscreenPlayer which is used for all in-player dialogs and only with explicit styles to maintain consistency and make it easier to track down and understand in the future. That took me an awfully long time to track down the issue for.

[fire-light42]

Everything works when testing, both the issues I found was fixed. The only new minor issue I found was that the notch in the trailer player on phone layout pads the player unevenly when in fullscreen mode. While it is not a big issue, it is changed from pre-release and what the player is like normally.

[Luna712]

Everything works when testing, both the issues I found was fixed. The only new minor issue I found was that the notch in the trailer player on phone layout pads the player unevenly when in fullscreen mode. While it is not a big issue, it is changed from pre-release and what the player is like normally.

@fire-light42

Nice catch with that one, it should be fixed now.

[Luna712]

Also just an FYI, I do have another planned patch to normalize the status and navigation bar colors pre A11, as well as A11+ make it blend much much better and seamlessly but I decided not to in this patch, as it is already large and didn't want to make it larger, and this just mostly aimed to keep it close to how it was before. As an example of how it will look after my future patch on this:

[Luna712]

Hmm I found a new bug that exists in pre release also.

1. Play a trailer in full screen
2. Go to device home
3. Wait a bit
4. Go back to the app

Now the navigation and status bars are still hidden and its still still in full screen mode even though the trailer is not anymore. I don't plan to fix in this PR though because it's unrelated as it is in pre also.

[fire-light42]

Everything looks to be in order, but it might be of interest to match the color of the bar to the popup:

However, it is not required for a merge given that master has the same issue. If you want this merged instantly then just respond or 👍.

[Luna712]

Everything looks to be in order, but it might be of interest to match the color of the bar to the popup:

However, it is not required for a merge given that master has the same issue. If you want this merged instantly then just respond or 👍.

@fire-light42

This will be done in a separate PR, the aim of this was to try and keep similar behavior to how it is now, and in another follow up PR I plan to have it blend much better on both status and navigation bar. So this can be merged. Thanks a ton for the review and testing this also.