feat(YouTube): Bump compatibility to 18.37.36

[oSumAtrIX]

Depends on ReVanced/revanced-integrations#483

TODO

• Remember video quality: Fix class cast exception (likely offset issue)
• Return YouTube Dislike: Failing fingerprint TextComponentAtomicReferenceFingerprint
• Return YouTube Dislike: Add support for new shorts player UI (dislikes do not appear in shorts)
• Return YouTube Dislike: Fix shorts player not showing dislikes on first video loaded Edit: problem is unrelated to 18.37.36
• Disable auto captions: Fix patching null pointer exception
• Hide endscreen cards: Failing fingerprint LayoutIconFingerprint
• Hide Shorts components: Add support for new shorts UI components (patch does not function)

[LisoUseInAIKyrios]

I partially fixed RYD and it works with regular videos.

But, it's broken with Shorts in two ways:

1. The shorts UI now is different. The existing shorts layout patch points are not called, and layout inspector shows the shorts buttons are now litho component hosts. That means both RYD and the hide shorts patch needs updates.
2. When spoofing to 18.20.39 or older, the old shorts layout is used and dislikes are displayed, but for some reason it doesn't show dislikes on the first short loaded. It's fetching the dislikes correctly, but somewhere after that it's getting confused and ignoring the dislike fetch. I have not looked into why it's doing this, but this did not happen previously.

[oSumAtrIX]

shorts layout patch

Do you mean the Hide Shorts components patch? In case the buttons are now built by Litho, we should be able to filter them using the Litho filter patch. Do they appear in the logs?

That means both RYD...

If the shorts dislike button is built by Litho, a TextSpec component should be used for the "Dislike" label. This means the same hook can be used as the normal player dislike button to filter the correct TextSpec component using the path builder object.

[LisoUseInAIKyrios]

Do you mean the Hide Shorts components patch? In case the buttons are now built by Litho, we should be able to filter them using the Litho filter patch. Do they appear in the logs?

Yes hide shorts components. No I haven't checked the litho logs yet.

If the shorts dislike button is built by Litho, a TextSpec component should be used for the "Dislike" label. This means the same hook can be used as the normal player dislike button to filter the correct TextSpec component using the path builder object.

I haven't checked that either. If it is possible to fix that way, hopefully it doesn't block the video playback or cause the UI to be unresponsive. Will try later.

[oSumAtrIX]

I have confirmed that the shorts components now show up in the logs and can be blocked, I'll push a fix for them but constrain the compatibility of this patch to the latest version to get rid of legacy code.

[LisoUseInAIKyrios]

Would it make sense to keep the legacy code for app spoofing? If the patch later acts up could remove it then, but right now it still works.

[oSumAtrIX]

Alright, I'll try to keep it.

[oSumAtrIX]

@LisoUseInAIKyrios It may be possible to filter properly through protobufBufferArray. The abstract class Filter has two fields:

But this class is missing a field for ByteArrayFilterGroupList. Is there a specific reason for this?
Also, the inline docs say:

If you have more than 1 filter patterns, then all instances of this class should filtered using {@link ByteArrayFilterGroupList#check(byte[])},

Do you mean filter patterns in the sense of ByteArrayAsStringFilterGroup or the actual filters inside that group? If I have two or more ByteArrayAsStringFilterGroup, should ByteArrayFilterGroupList#check(byte[]) be used in this case, or when I have ByteArrayAsStringFilterGroup with multiple filters?

[LisoUseInAIKyrios]

But this class is missing a field for ByteArrayFilterGroupList. Is there a specific reason for this?

The abstract class group lists are always searched for, all the time, for every litho item.

The buffer can contain free form text which includes user comments, video descriptions, and more. So it's theoretically possible to match bogus text if the buffer is always searched for each litho item without first checking if the identifier/path is correct. There's also performance issues with always searching the buffer, because the buffer can get enormous in some situations and the overhead is noticable.

Surely there must be an identifier or path that can be matched first, and then the buffer is searched inside the patch? That way its certain the buffer is for the item in question, and performance is good because it's only searching the buffer when needed (and most importantly, no false matches on comments or other junk). The patch would have it's own byte filter list that it searches after an identifier/path is matched (like how the hide actions buttons patch works. It has its own buffer search that is checked only after an action button identifier/path is matched).

If I have two or more ByteArrayAsStringFilterGroup, should ByteArrayFilterGroupList#check(byte[]) be used in this case, or when I have ByteArrayAsStringFilterGroup with multiple filter

Both cases should use ByteArrayFilterGroupList#check(byte[])

If there is more than 1 pattern (regardless if it's in a single group or multiple groups), then it should always be filtered using a group list. The individual FilterGroup#check() should only be used if there is a single pattern to search for (an example is the hide mix playlist patch, which uses one group with just 1 pattern).

[oSumAtrIX]

All todos are now ticked. I am not yet entirely sure about the spoof to old version issue as I was not able to reproduce it with the latest commits. Once you give me the green light with ReVanced/revanced-integrations#483 (comment) we should be able to merge.

[LisoUseInAIKyrios]

There's a new small issue with the new shorts player that's caused by the way litho text is patched.

Since the creating and updating of litho components blocks until the RYD fetch is completed, occasionally shorts will either:

• show a frozen video while the audio plays (happens most often on the first short opened on cold start)
• video and audio plays correctly, but the UI momentarily is not shown and the UI is unresponsive until RYD fetch completes

A possible fix is to handle this the same way as the old native shorts buttons: get a reference to the dislike litho button on creation, don't block the litho thread, and then update the dislike button asynchronously after RYD fetch completes.

For now a temporary fix is to spoof to 18.20.39 which uses the old shorts player.

[oSumAtrIX]

Does the video desync with audio or sync after the request is finished? If it desyncs, it may be better to set a shorter timeout.

[LisoUseInAIKyrios]

When the video unfreezes its in sync with the audio and everything is ok.

Previously RYD had this same issue before it was changed to handle shorts asynchronously. So the old issue is basically back but now it's with litho.

[oSumAtrIX]

Unfortunately, we do not know any hook that would allow us to get a reference that we can pass via a callback to the future to edit the text, so this is gonna be a limitation.

[LisoUseInAIKyrios]

I can't find any noticeable differences between 18.37.36 and the current target version.

Could merge this after dev to main is merged, so this change will have more time on dev branch before it's eventually merged to main.

[oSumAtrIX]

Each patch is constrained to versions. The patches with issues can remain as is (as long as they are compatible with all the previous versions) while the other working patches can be bumped. This branch can then be merged to dev and main. ReVanced Manager will continue to suggest the current version as most patches support it, while being able to patch the latest version either including the patches that do not yet work reliably (toggling in the settings) or without them (default).

[LisoUseInAIKyrios]

Ok sure. I can't find any other issues and I guess this is ready to go now.

[oSumAtrIX]

I've been also testing this version and it works fine, I can personally not reproduce blocking thread issue, but I suppose it occurs on slow networks. Once I'm home, I'll append the new compatible version to the annotation field and merge

[oSumAtrIX]

RYD patch lost compatibility with the current supported version. Either we have to revert the changes for RYD patch in this PR or we have to constrain it to the currently working version (with the present issue).

[LisoUseInAIKyrios]

The current issue won't be fixed anytime soon (add support to alter litho asynchronously).

The app can be spoofed to 18.20.39 and that fixes any RYD shorts issues.

I think keep the RYD changes and merge.

[cyberboh]

Missing something:

INFO: Decoding app manifest
WARNING: Player flyout menu is incompatible with version 18.37.36. This patch is only compatible with version com.google.android.youtube: 18.16.37, 18.19.35, 18.20.39, 18.23.35, 18.29.38, 18.32.39

[LisoUseInAIKyrios]

@cyberboh will be fixed in next dev release. Use -f flag to force patching for now.