feat: Add Set target SDK version 34 patch (Disable edge-to-edge display)

[LisoUseInAIKyrios]

Forces off Android 15 edge to edge display by changing the target SDK version to Android 14.

Effectively, this will restore opaque nav/status bars.

Before: Photo Math (bottom nav bar is transparent)

[oSumAtrIX]

Is there no way to control the behaviour directly without downgrading the SDK version?

[LisoUseInAIKyrios]

Is there no way to control the behaviour directly without downgrading the SDK version?

It appears the theme file can set windowOptOutEdgeToEdgeEnforcement to true, but that requires knowing what theme file is used and there may be many of them. Google is said to deprecate that override value in the future.

Setting the target SDK automatically opts out of the behavior.

[oSumAtrIX]

In this case, iterate through all the themes XML files and set windowOptOutEdgeToEdgeEnforcement to true instead of downgrading the SDK. If there is a non deprecated way of disabling edge to edge, you can do that instead.

[LisoUseInAIKyrios]

https://developer.android.com/about/versions/16/behavior-changes-16#edge-to-edge

It seems opting out is only for Android 15. Android 16 ignores the flag.

So, changing the target sdk appears to be the only way for Android 16+

[oSumAtrIX]

This patch should be turned into a changeTargetSdkPatch as it is mainly doing that. A patch option can control the SDK version and could use the compileSdk version by default.

[LisoUseInAIKyrios]

A generic patch doesn't appear to have any use case except for this specific situation (edge-to-edge display).

Using an older target sdk may cause unknown and undesirable backwards compatibility behavior.

Users already get confused enough and apply universal patches without understanding what they are doing: "I applied remove screenshot patch and the app is crashing" (the unpatched app doesn't even restrict screenshot usage).

If other purposes for changing the target sdk is found then the patch can be made generic. But for now I think it's much simpler to keep the patch focused on this one specific change.

[oSumAtrIX]

Users getting confused by universal patches is not a concern patches is supposed to fix by labeling patches something they arent really doing. The business logic of the patch implies a different name than currently given. It is a patch that changes the target SDK and as such should be named like that. Naming it like something else on the other hand is where issues start to happen. The patch is not just disabling edge to edge display, it is downgrading the SDK, so "unknown and undesired backwards compatibility behaviour" still applies regardless. If the patch is named according to what it does, this side effect would be expected behaviour as the patch did what it was named after, which is changing the target SDK. The user confusion with universal patches is not this repositories or patches concern and should not be a supporting argument to name the patch after something else than it really does.

[LisoUseInAIKyrios]

The patch explains what it does (changes target sdk), but if it's generic that means the user now needs to know that using sdk 34 turns off edge to edge display.

And if there's no other use case except this, then why give the user an option (target sdk) when there is literally only one value that is useful?

Making the patch a generic Change target sdk is making it unnecessarily complex with no added value.

[oSumAtrIX]

The patch explains what it does (changes target sdk), but if it's generic that means the user now needs to know that using sdk 34 turns off edge to edge display.

Thats what the description or even patch option values are for. You can add SDK 34 as a value and mention that it disables edge to edge display.

And if there's no other use case except this, then why give the user an option (target sdk) when there is literally only one value that is useful?

There may be other use cases, I don't know what new Android SDK versions add but let alone for scalability and future possible usecases, this change would be useful.

Making the patch a generic Change target sdk is making it unnecessarily complex with no added value.

The patch is already a "generic change target SDK" patch, just that it now should provide an option to change to any SDK and not an arbitrary value like 34 which makes the primary and only business logic the patch has, dynamic and scalable. The name "Disable edge-to-edge display" is not the actual name of the patch according to the core business logic. If there was some Android API to disable edge-to-edge display, and the patch would use that to disable this feature, then the name would be appropriate.

[LisoUseInAIKyrios]

I'm searching now, and I can't find another other compatibility behavior that could be desirable to revert.

And some of the backwards compatibility would be bad to revert.

Such as changing to sdk 33 that reverts 34's behavior of allowing a an app to run in the background less time before it's paused/hibernated. Revering that behavior will cause the app to use more battery (if the user wants to allow more background time, the app should instead be whitelisted for battery usage).

Another is Android 33 has lower range for accessibility text size (34 is up to 200%, 33 is up to 130%)

Yet another is early versions of Android sdk turns off various hardware acceleration functionality.

I don't think letting the user pick a version is a good idea. If we cannot find a single use case outside of forcing sdk 34, then there is no reason to let them.

If we find another use case, then sure change this to a generic patch. But until then let's not make this complicated.

[MarcaDian]

I wonder if downgrading the target SDK version fixes these dark mode bugs? I think it's related to the update to Android 15.

Or these bugs caused by not using the androidx library?

[LisoUseInAIKyrios]

@MarcaDian what's wrong with the third photo?

[oSumAtrIX]

I don't think letting the user pick a version is a good idea. If we cannot find a single use case outside of forcing sdk 34, then there is no reason to let them.

The user can choose a higher SDK value. There is no reason to cripple the patch in its core logic.
But even then, making the patch less flexible by not adding the option, the patch is still named incorrectly. If you hardcode the arbitrary SDK version 34 the patch remains a "Set target SDK version 34" patch and not a "Disable edge-to-edge display" patch, because it sets the SDK version to 34.

[MarcaDian]

In the third screenshot, the GitHub mobile client, I just wanted to show that this bug is not only in the settings of the revanced, but also in third-party programs.
At the same time, everything is fine in the settings of the YouTube client.

[LisoUseInAIKyrios]

Setting the sdk higher than unpatched has a high likelihood the app won't work correctly (or even launch at all), because nearly every new sdk has new requirements such as declaring exports/permissions and some classes will throw exceptions if not used in the 'new' way.

Forcing to 35 or above will break nearly all old apps because edge-to-edge is then forced on but the UI isn't updated to handle edge to edge.

If the patch name must be explicitly based on what it does, it can be Change target SDK and the description explains it changes to sdk 34 that forces off edge-to-edge display. If even a single other sdk target can be found that is useful to force, then the forced sdk target can be an option.

[oSumAtrIX]

"Change target SDK" would call for the option. If the patch is restricted to SDK 34, it is noteworthy for the name to be "Set target SDK version 34" with a description motivating this arbitrary SDK version.