0

(It's optional to read)

Let's say I have an app called X, this is the older version of the apk that I got from google. I have important data in the app, thus, if I uninstall it, I'll lose them. However, I want to update it, since google play store doesn't provide the app anymore (only available on the official website of the app), I need to download it manually. So, somehow (I watch a tutorial from YT) I need to sign the latest version of the app. Silly of me, I made a mistake that I unsigned the new app and then signed the app afterwards without knowledge of which appropriate sign type I need to apply.

Problem:

So I have unsigned (Removing signature verification) an app using NP Manager (the property says the app has signature status of V2, thus I killed the signature verification v2) , and then I signed the app and do the same i.e. signing the app using the signature scheme V2 (NP Manager has 3 options: v1+v2, v1 and v2 [Android 7.0+]).

At first, it worked successfully, i.e I could install it perfectly, some features worked and nothing seemed to be wrong, alas, there was one (Idk what it's called) bar/menu/section when I opened it, the app stopped immediately (forced close). I had tried to do trial-and-error by investigating what's wrong and the problem seems to come from the unisigning and signing.

My question:

Is it either unsigning or signing the app can harm the app itself which causes some features don't work though the app might be able to be installed successfully? If that's so, how to prevent this problem? Is it because the original signature and rhe new signature I give differs and crash somehow?

P.S. I'm only interested to know as to why the unsigning and signing makes the app error and how to solve it. I hope you would explain the error that happens in my app and why signature matters.

Thanks in advance!

Improve this question

1 Answer 1

Reset to default
1

Android OS checks the signature only at installation time. The verification information is saved and can be retrieved by the app at run-time (but the number of apps that do so is very low).

In general apps work no matter how and using what key/certificate they are signed. Only a few apps implement measure against app repackaging/resigning so they check their app signature at runtime and if it does not match the quit or show an error message or something like that.

That an app starts working an then suddenly crashes sound more like a bug of the app. Most likely the app has been developed for an older Android version or a different phone model (there are sometimes slight differences between different models).

Also it does not make any difference if you first remove a signature for an APK and later sign it. By default a new signature totally replaces the old signature.

Improve this answer
3
  • "By default a new signature totally replaces the old signature." Are you sure of that? So if one wants to double-sign (like it's done with reproducible builds at F-Droid, carrying the original dev's signature as well as F-Droid's, while at F-Droid's signing the private key of the dev is not present), one must explicitly say so?
    – Izzy ♦
    Feb 5, 2022 at 13:09
  • @Izzy When I execute apksigner sign then the new signature totally replaces the old (tested with build-tools v29 and 31 and an APK that had a v2 only sig). But I have not seen any option to change the apksigner behavior between replacing and adding a signature.
    – Robert
    Feb 5, 2022 at 14:35
  • 1
    There's the --next-signer option. But in all examples I've seen so far, it only goes after the first signing key. I just tried it, result looks the same as without (signatures seem indeed to be replaced). Guess I'll have to ask my team mates at F-Droid…
    – Izzy ♦
    Feb 6, 2022 at 0:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .