ReVanced
feat: Show warning dialog if any patch fails
Feature description
When users patch the wrong version of an app, or they configure a patch option wrong, or something else goes wrong during patching, then Manager should show a dialog warning that patching failed and the app may not install or work correctly.
I'm not sure how Manager can detect a patching failure, but I would speculate that patcher would need to return a value indicating if all patches completed successfully or if any failed.
Motivation
Users do not always understand what a patch exception stack trace is or why that means a failure, and it leads to troubleshooting hassles for others. Issues such as GmsCore support failing to patch, then installation fails because the package name was not changed and the install is trying to update the stock YouTube app.
Situations like this (GmsCore support failed to patch and the user did not notice):
Acknowledgements
- [x] I have checked all open and closed feature requests and this is not a duplicate.
- [x] I have chosen an appropriate title.
- [x] The feature request is only related to ReVanced Manager.
There are two types of exceptions. Exceptions raised by patches or exceptions raised from elsewhere, such as installing, OOM, etc. Patcher yields a patch result for every executed patch, so the Manager can check for that and display a warning that mentions if any patch has failed. Pairing it with information such as wether a suggested version was patched and other meta info would be useful
the Manager can check for that and display a warning that mentions if any patch has failed. Pairing it with information such as wether a suggested version was patched and other meta info would be useful
Perhaps the 'Copy log' button can be on the warning popup as well.
Also, if possible, the warning popup should specify which patches failed.
The main issue here is now solved with Manager Compose.
If patching fails it now shows an error, and does not allow saving or installing the broken APK.
A related but different issue exists, where the stack trace is massive and full of unrelated meaningless info. It would be better if Patcher trimmed the stack trace to start at the patch itself and exclude all the junk method calls. But that's outside the main issue here.
Off topic, but patching is now so much faster than before (probably because it has more memory and it's not wasting so much time garbage collecting in the old limited resource environment).
Full error message
@LisoUseInAIKyrios, I'd say post that issue about the large traces as another issue.
