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.

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, if 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.