Consider making ChangeVersionCodePatch universal

[FibreTTP]

Official Morphe transformed their universal Change Version Code patch to one that simply sets the max version code to disallow updates in the Play Store, could you consider making this repo's change version code patch applicable to all APKs?

[imPratyoosh]

Why, if morphe has already implemented this?
I don't see any benefits

[FibreTTP]

The point is that Morphe hasn't implemented this.

Their patch forces the APK's version code to the max integer (specifically so that the Play Store doesn't want to update the app), this repo's patch allows you to set any version code you like, but it's locked to only Twitter and Instagram.

See rationale in MorpheApp/morphe-patches#1155.

[imPratyoosh]

The point is that Morphe hasn't implemented this.

Their patch forces the APK's version code to the max integer (specifically so that the Play Store doesn't want to update the app), this repo's patch allows you to set any version code you like, but it's locked to only Twitter and Instagram.

See rationale in MorpheApp/morphe-patches#1155.

I see, btw you can check out anddea patches, it has what you want

[FibreTTP]

Oh thanks, that's exactly what I was looking for.

[LisoUseInAIKyrios]

The patch is originally from ReVanced, and a few Morphe repos have updated versions.

Hoo-dles was the first to port it to Morphe:
https://github.com/hoo-dles/morphe-patches/blob/main/patches/src/main/kotlin/hoodles/morphe/patches/all/manifest/packagename/ChangePackageNamePatch.kt

Edit: I overlooked this was for version code.

The same patch is still from ReVanced and made it way to everything else later.

[FibreTTP]

That's ChangePackageName? hoo-dles' repo doesn't seem to have ChangeVersionCodePatch.

Or did I misunderstand what you were saying?

[kitadai31]

Their patch forces the APK's version code to the max integer (specifically so that the Play Store doesn't want to update the app)

What are the advantages of setting the version code to something other than the maximum value?
Unless this can be explained, there is no motivation for it.

For example, if it's useful to spoof the version code of a particular app, then it should be implemented as a patch specific to that app.
Like "Restore XXX" / "Restores XXX functionality by changing version code to XXX" or something similar.
Furthermore, if you only need to change the version code of any app, it's faster and more efficient to use Apktool M, which allows you to edit AndroidManifest.xml at the binary level without decompiling it.

[FibreTTP]

What are the advantages of setting the version code to something other than the maximum value?

Did you read MorpheApp/morphe-patches#1155?

Basically, the only way fdroidserver determines Android app versions is through their version code. I selfhost an fdroidserver for myself and family that has patched apps on it, but since patching an app on the same version doesn't change its version code, fdroidserver will not pick up the difference and it won't be updatable within their client apps.

Being able to override the version code (and manually set it to original_vercode * 1000 + patch_index or something) would allow fdroidserver to properly determine the latest version of the app, and serve it to users.

The value has to increase. Using the max value will fall back to fdroidserver's method of just picking the first .apk in the repo directory to use as latest.

then it should be implemented as a patch specific to that app.
it's faster and more efficient to use Apktool M,

Given the above, being able to set the version code at the same time as patching (since I would be using patches anyway) would save having to use another application to simply change the version code afterwards.

[kitadai31]

I'm sorry, I didn't read the link.

That makes sense.

However, I still oppose making piko's version code patch universal.
This is because it will appear as a universal patch within the Manager, potentially alienating users from selecting it.

I'm glad you found out that anddea solves the problem from the comment above.