fix(Change package name): Prevent applying the patch to known incompatible apps

[LisoUseInAIKyrios]

Until ReVanced patcher adds more general support, this PR adds a very simple exclusion list for apps that are confirmed as incompatible with Change package name.
 

Before this change, when patching Twitter with Change package name the patching will succeed and the app installs, but the app hangs and crashes on launch.

With this change, the user is informed during patching and the package name is not changed:

SEVERE: "Change package name" failed:
app.revanced.patcher.patch.PatchException: The patch "Change package name" raised an exception: app.revanced.patcher.patch.PatchException: 'com.twitter.android' does not work correctly with "Change package name"
...
Caused by: app.revanced.patcher.patch.PatchException: 'com.twitter.android' does not work correctly with "Change package name"

 

The partial list of incompatible apps are:

• Duolingo
• Reddit
• Tumblr
• Twitch
• Twitter / X

[oSumAtrIX]

There's three problems I have with this PR.

1. The change package name patch, previously universal and agnostic to apps, now loses its agnostic attribute as it hardcodes package names. This isn't really an elegant solution
2. The patch may raise an error, but it won't stop the app from failing to compile. Users will still raise an issue, ignoring the log statement. The issue intended to be mitigated with this PR will hardly be mitigated
3. The patch isn't the cause of the issue. It is resource patches as a whole, but yet this PR only makes changes to one patch and not all resource patches. Furthermore it weakens the motivation to solve the actual problem, as it provides a short-term hack around the actual issue. The real issue originates in androlib failing to decode/build resources, but this may have already been fixed since we rely on a fork that is based on an older commit. Perhaps bumping it fixes the issue

[LisoUseInAIKyrios]

1. It's still agnostic, but gives a little help to reduce users spamming "my app is broken when I open the settings". Right now it completely prevents applying the patch, but instead it could print an error and make the change anyway. But if the package name is changed even though it's 100% confirmed it will not work, the user can ignore or not notice the stream of patch log statements then complain when the app is still half broken (and then the situation is back to where it was before this PR).

2. Many apps will patch "successfully" without any compile errors (such as Reddit) and even initially launch and appear to be ok, but then the app malfunctions when the app tries to load resources that were not also renamed. Errors like this are specific to the change package name app because all other resource patches work without issue in cases like this.

3. This patch is the cause of the issue for some specific apps like Reddit, and this PR will fix situations like that. All other resource patches seem to work just fine, it's just the renaming of the package that cause the most issues.

[LisoUseInAIKyrios]

To anyone using Change package name only to prevent App store updates

Instead use Change version code, as it also prevents app store updates and has way less compatibility problems compared to Change package name.

[oSumAtrIX]

1. Since the patch references packages now, it is not agnostic to any app anymore. The correct agnostic way to handle this situation for the patch is for the patch to identify if it will fail based on the actual reason resource patches fail. For example, if the app references a weirdly decoded resource which is causing AAPT to fail. Instead, it hardcodes packages and loses its agnostic design, only considering known apps where the issue occurs. But what if the patch is used on other apps not hardcoded?
2. Most people will not even read the log, specifically those who ignore the warning when toggling changing the patches, include the patch and complain getting issues. So the attempt to log a warning specifically for those already is not really effective. Many apps also fail to compile, and those who don't, the user would simply wonder why the patch did not change the package name. If at all, it would be better to return a patch exception, because not changing the package name is an error state of the change package name patch. Other patches will still complete, but for example, when another patch depends on the change package name patch, it would also fail as supposed, because it intended the patch to change the package name

I still believe it is not a good idea to try to work around the actual issue like this by hardcoding packages and break agnostic design of the patch. Besides, if the actual issue is solved, we have to keep this patch in mind, yet another maintenance burden, to come back and remove the hardcoded packages.

[LisoUseInAIKyrios]

Then this can be changed to only exclude the apps that patch successfully but then fail on app launch or during usage. The apps that fail resource compilation already fail even if it's an error that makes no sense, so it at least stops them from "hey I can't login what wrong fix this"

Reddit is definitely the worst because the user will see it works but only when they login or use the settings it crashes, and by then they have long forgotten about that "may cause issues" description warning they ignored during patching.