bug(YT Music): Fix per patch recommended version

[Abilash-22]

Feature description

Today out of curiosity I patched the Youtube music app version 8.44.53 and it seems to be working fine.

Motivation

I kindly request you to upgrade the suggested version of Youtube music app to any so that we can patch the latest version and enjoy any new features as such.

Acknowledgements

• I have checked all open and closed feature requests and this is not a duplicate
• I have chosen an appropriate title.
• All requested information has been provided properly.

[LisoUseInAIKyrios]

The last time it was any version, multiple client side playback flags were added and nobody noticed. Playback was broken for users who had the flags enabled, and playback worked for users it was not enabled.

The same problem also showed as broken patch functionality, but only for some users.

It's better to wait 3-6 months and bump the recommended version then, when YT has decided what to do with a/b tests and the flags are enabled/disabled for most users.

Users can always turn off version constrains in Manager and patch whatever works, and they go into the wilderness of unknown on their own.

[Abilash-22]

Well, that makes total sense. It's like I am using a beta version, there maybe bugs or something may get broken.

[oSumAtrIX]

The version constraint must be decided for each patch respectively, there is no one version for all patches

[LisoUseInAIKyrios]

The issue of user specific a/b flags breaking stuff exists for all patches.

[LisoUseInAIKyrios]

There are only two ways to tell:

1. Wait long enough (3-6 months? Maybe longer?), and all the a/b flags for a specific release are then decided by YT (the a/b testing has conclude), so most/all users have the same flags. Then verify all patches work correctly.

2. Don't wait 6 months, and manually go thru each new release and find all the new flags that did not exist in the previous recommended app targets. Then manually force each flag on and verify all patch features still work. But this still doesn't account for server side changes (such as litho layout changes), which cannot be forced on with patching.

Given the low attention YT Music gets, option 1 is the current solution until someone steps up and does option 2.

[oSumAtrIX]

The issue of user specific a/b flags breaking stuff exists for all patches.

I am pretty sure custom branding, enable debugging or the theme patch work on any version to just name a couple. Versions are patch specific and modularity demands independent separating this concern to each patch, irrespective to any circumstance, even if a/b flags were to break all patches.

There are only two ways to tell:

You don't have to wait. You can go back in time the same way you're trying to go forward. Each app comes with default flags and as such you can go back in time and use the defaults to see that they do not affect the patches. That said, each patch is supposed to treat flags its concerned about. Depending on flags and forcing versions is O(N) maintenance work. Dealing with it once, is O(C).

[LisoUseInAIKyrios]

Custom branding was broken on most of the latest unreleased YT Music (I fixed it today). It patched successfully but the app crashed on startup. Fingerprints and patches are not guaranteed to always work.

Forcing an old set of flags just to get old features isn't a solution, and at that point the user should just use an older but tested and verified app target.

It's worth pointing out that not all client side flags are hooked by the debugging patch. So it's not even possible to force on/off specific flags unless new patch code is developed.

[LisoUseInAIKyrios]

The simplest and most foolproof solution is to:

1. Keep updating YT Music so the latest target can be patched.
2. Encourage users to who want to be test subjects to turn off version constrains and patch the latest app target.
3. Accept bug reports for the latest app target.
4. Update the recommended app target after enough time has gone by and no outstanding bugs are open.

Then users can venture into the unknown, while users who just want a working app can use the recommended target that is well tested.

[oSumAtrIX]

Fingerprints and patches are not guaranteed to always work.

Nothing is, but if the confidence is high you can bet on it more often than having to maintain bumping the versions everytime. It breaking once every year over having you to commit "bump this" and close "can you update" issues I don't know how many times, is simply more favorable.

Forcing an old set of flags just to get old features isn't a solution, and at that point the user should just use an older but tested and verified app target.

You force it for the respective patch OR handle both flags. This is entirely the patches mandatory responsibility.

[LisoUseInAIKyrios]

Forcing flags means knowing the flag exists, and knowing it must be forced on/off.

Bumping to new versions without knowing these flags is back to the same problem of why spoof client stopped working and nobody noticed.