feat: Patch from existing installed app as apk source

[kartikbillimoria]

Feature description

As the title says, URV Manager has the ability to use installed app as the source which it can merge as well if it's a split apk which makes it super handy instead of going through downloading the apk.

Motivation

Makes the whole patching process faster with that option.

Acknowledgements

• I have checked all open and closed feature requests and this is not a duplicate.
• I have chosen an appropriate title.
• The feature request is only related to Morphe (Manager).

[Loukious]

This is 100% needed. Having to manually download the apk (which may happen to be a split apk making the headache x2) is a deal breaker.

[MarcaDian]

Usually the version installed on the user's device is not compatible with patches. Very few users understand what they are doing. Therefore, to avoid meaningless errors like: I selected an apk from the installed ones but it causes a patching error, we did not implement this.

The manager during first patching already saves the original apk for the next patching. Since the apk version changes rarely, this works. Therefore, it makes no sense to download the apk again every time.

The only working case is root mounting, since the user must first install the same version of the base APK that will be patched.

[LisoUseInAIKyrios]

Non root users must also uninstall the existing app, so they lose their app data.

Most patches require a specific app release, which is almost never going to be what a user can install from the app store.

The only use case that makes any sense for this is for root, because they can keep their app data and the install source of the play store is kept which can be useful for some apps with checks such as X.

[mirh]

I don't know why the use case should be this fancy.
I'm trying to patch 3rd party reddit clients, and I'd like to provide my own installed (and still directly acquirable from play store) apks.
And you are guaranteed to have the right version because the last one ever made was the one that patches target (but even if this wasn't the case, it doesn't take much to just have a check for a specific version or hash).

[xob0t]

Im thinking:

• off by default
• only exposed in advanced/expert mode
• extracts the installed APK/splits into Morphe cache
• uses the existing patch flow from there
• warns that this is best-effort and patch failures should be reproduced with a clean APK

I just patched a bunch of apps with my universal patches, and had to use App Manager to extract them first. Apks for some apps are just nowhere to find.

[MarcaDian]

But when selecting an installed application, the patched application will have a different signature (for the average user), what to do in this case?

[mirh]

.. nothing, as it's their business to figure whether they just want to do a brief test run, or want to commit and uninstall the original?

Anyway, I for one would like to raise the bid, as Morphe patches already ship with a compatiblePackages/Compatibility field.
On patch selection, the patcher checks if there's already an existing package with that name.
If yes and its build number matches too, an option to use it is automatically offered in the "help me find an APK" screen.
And that's on by default.

The one option that should be very experimental and hidden behind many scary warnings, is the possibility (whether the apk is already installed or not) to use a different version.

[MarcaDian]

I can try to implement it in testing mode in separate PR. And then we can decide whether to add it or not. I myself am interested in this, but we have a lot of inexperienced users, who then make it look bad with their complaints as if there are bugs everywhere)) although they are stubborn experimenters and try to break something every time

[Loukious]

But when selecting an installed application, the patched application will have a different signature (for the average user), what to do in this case?

No need to over-complicated things. Revanced has the feature and no complaining and no confusion is happening because of it. Just copy their solution. This is a fork after all.

[MarcaDian]

Just copy their solution. This is a fork after all.

The only difference is that I didn't take a single line of code from other repositories, on principle. Even if I need to implement something similar, I will do it myself, even if it's carelessly.

[Loukious]

The only difference is that I didn't take a single line of code from other repositories, on principle. Even if I need to implement something similar, I will do it myself, even if it's carelessly.

That's what I meant with copy the solution. Didn't mean copy the actual code.

[MarcaDian]

To be honest, when we were developing this project we didn't think that we would have so many third-party bundles there. This already means that we are on the right way and developers choose us because we are better in terms of support and development. This is the reason why we are now trying to make changes to support third-party developers and all these changes.
This is all offtopic, just as an explanation why the choice of apk of the installed application was not there from the very beginning. We discussed this at the concept stage.

[MarcaDian]

There is a question about implementation. Aren't there too many buttons? This is the maximum case in this situation. Another solution is a drop-down list, but this is +1 action. I'm fine with that.

Screenshots

[LisoUseInAIKyrios]

Assuming the user has 2026.19.0 installed, I think it looks great.